From nobody Mon Jun 2 12:40:07 2014 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 BB6D91A0369; Mon, 2 Jun 2014 12:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUyHbWThO7m8; Mon, 2 Jun 2014 12:40:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F15021A0404; Mon, 2 Jun 2014 12:40:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140602194000.11262.35332.idtracker@ietfa.amsl.com> Date: Mon, 02 Jun 2014 12:40:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/JNyIroZQMkYus5B4875O4QRme8Y Cc: idr mailing list , idr chair , RFC Editor Subject: [Idr] Protocol Action: 'Reservation of Last Autonomous System (AS) Numbers' to Best Current Practice (draft-ietf-idr-last-as-reservation-07.txt) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 19:40:04 -0000 The IESG has approved the following document: - 'Reservation of Last Autonomous System (AS) Numbers' (draft-ietf-idr-last-as-reservation-07.txt) as Best Current Practice This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation/ Technical Summary This document reserves two Autonomous System numbers (ASNs) at the end of the 16 bit and 32 bit ranges, described in this document as "Last ASNs" and provides guidance to implementers and operators on their use. Working Group Summary WG's only discussion was on whether this was BCP or Proposed standard. The result was "What-ever works" as it has both suggestions to implementors and operators. Document Quality Implementations at Microsoft, Cisco and Juniper adapted this range. No implementation report exists. Early reviews for IANA, OPS-DIR, Routing AD, and Routing Directorate were requested and done. Personnel Shepherd: Susan Hares AD: Alia Atlas From nobody Tue Jun 3 09:07:00 2014 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 B07ED1A02C8; Tue, 3 Jun 2014 09:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL-5m58mv_zu; Tue, 3 Jun 2014 09:06:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F411A02E6; Tue, 3 Jun 2014 09:06:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140603160649.23301.49105.idtracker@ietfa.amsl.com> Date: Tue, 03 Jun 2014 09:06:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/2xz01NblnhBxGzMXXRHyIOL_8Bo Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-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: Tue, 03 Jun 2014 16:06:58 -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 : Revised Error Handling for BGP UPDATE Messages Authors : Enke Chen John G. Scudder Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-11.txt Pages : 15 Date : 2014-06-03 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760 and 5701. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-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 Tue Jun 3 09:17:32 2014 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 8B39F1A020E for ; Tue, 3 Jun 2014 09:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 VLTHoQ6S2mTJ for ; Tue, 3 Jun 2014 09:17:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C2D1A0309 for ; Tue, 3 Jun 2014 09:17:16 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB117.namprd05.prod.outlook.com (10.255.214.11) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 16:17:10 +0000 Received: from [172.29.32.187] (66.129.241.10) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 16:17:10 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <20140603160649.23301.49105.idtracker@ietfa.amsl.com> Date: Tue, 3 Jun 2014 12:16:37 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140603160649.23301.49105.idtracker@ietfa.amsl.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BLUPR08CA013.namprd08.prod.outlook.com (10.141.30.33) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02318D10FB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6049001)(6009001)(428001)(377424004)(189002)(24454002)(377454003)(164054003)(199002)(51704005)(19580405001)(50986999)(33656002)(36756003)(20776003)(23746002)(87286001)(87976001)(89996001)(64706001)(92726001)(42186004)(92566001)(77982001)(66066001)(102836001)(80022001)(47776003)(76176999)(83716003)(76482001)(85852003)(83322001)(46102001)(19580395003)(74502001)(4396001)(82746002)(15975445006)(31966008)(74662001)(50226001)(88136002)(15202345003)(77156001)(104166001)(101416001)(99396002)(86362001)(57306001)(79102001)(21056001)(83072002)(81542001)(50466002)(62966002)(81342001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:[172.29.32.187]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/oGW2SwFTp6Sl_Pee5EnDBNSnpKk Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:17:24 -0000 This version includes only the =93MUST NOT=94 -> =93must not=94 change I = mentioned last Friday. Since I believe this version takes into account all the feedback that = has been offered to date, and since the discussion seems to have wound = down, I=92d like to request a new WGLC since the document has had some = substantial updates. Here=92s a URL for an rfcdiff between -07 (what we = started the WGLC with) and the current -11: = http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Ddraft-ietf-idr-err= or-handling-07&url2=3Ddraft-ietf-idr-error-handling-11 Thanks, =97John On Jun 3, 2014, at 12:06 PM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Revised Error Handling for BGP UPDATE = Messages > Authors : Enke Chen > John G. Scudder > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-11.txt > Pages : 15 > Date : 2014-06-03 >=20 > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not = only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for a number of existing attributes. >=20 > This document updates error handling for RFCs 1997, 4271, 4360, = 4456, > 4760 and 5701. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-11 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 3 09:39:48 2014 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 BF5EC1A031F for ; Tue, 3 Jun 2014 09:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 irHdNg7due5m for ; Tue, 3 Jun 2014 09:39:40 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id 56E1B1A02EF for ; Tue, 3 Jun 2014 09:39:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id BA12664218D; Tue, 3 Jun 2014 18:39:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCQZRSq7k27v; Tue, 3 Jun 2014 18:39:26 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id 23EE8642180 for ; Tue, 3 Jun 2014 18:39:26 +0200 (CEST) Message-ID: <538DFA3D.9030305@benocs.com> Date: Tue, 03 Jun 2014 18:39:25 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: idr@ietf.org References: <20140603160649.23301.49105.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/z-ni4HccQaqcJepTaEqCu-91aXs Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:39:42 -0000 Am 03.06.2014 18:16, schrieb John G. Scudder: > Since I believe this version takes into account all the feedback that has been offered to date, and since the discussion seems to have wound down, I’d like to request a new WGLC since the document has had some substantial updates. Here’s a URL for an rfcdiff between -07 (what we started the WGLC with) and the current -11: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-idr-error-handling-07&url2=draft-ietf-idr-error-handling-11 Don't want to sound impolite, by I guess, you might have overlooked my feedback/questions to draft-ietf-idr-error-handling-10.txt. But maybe that was just too much nit-picking? Deniz From nobody Tue Jun 3 09:50:49 2014 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 E865E1A032D for ; Tue, 3 Jun 2014 09:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 I2IerFVs2FtS for ; Tue, 3 Jun 2014 09:50:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C621A0319 for ; Tue, 3 Jun 2014 09:50:32 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB419.namprd05.prod.outlook.com (10.141.27.19) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 16:50:25 +0000 Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 16:50:23 +0000 Received: from BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) by BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) with mapi id 15.00.0949.001; Tue, 3 Jun 2014 16:50:23 +0000 From: John Scudder To: "" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-11.txt Thread-Index: AQHPf0qLABCgXuMyakWT9Nibuw5CzZtfmT3T Date: Tue, 3 Jun 2014 16:50:22 +0000 Message-ID: <6BAC6EE0-6FAF-432A-A31C-BA3E4E616825@juniper.net> References: <20140603160649.23301.49105.idtracker@ietfa.amsl.com> , <538DFA3D.9030305@benocs.com> In-Reply-To: <538DFA3D.9030305@benocs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [204.38.191.149] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02318D10FB x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(24454002)(377454003)(199002)(41574002)(19580405001)(50986999)(33656002)(36756003)(54356999)(20776003)(64706001)(87936001)(2656002)(92726001)(92566001)(77982001)(66066001)(80022001)(76176999)(83716003)(76482001)(85852003)(83322001)(46102001)(19580395003)(74502001)(4396001)(82746002)(99286001)(31966008)(74662001)(101416001)(77096999)(99396002)(86362001)(21056001)(79102001)(83072002)(81542001)(81342001)(104396001)(42262001)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:BLUPR05MB722.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/5_1_EVK44rZmmIiSoMsnvIFixfE Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:50:40 -0000 On Jun 3, 2014, at 12:40 PM, "Deniz Bahadir" wrote: > Don't want to sound impolite, by I guess, you might have overlooked my fe= edback/questions to draft-ietf-idr-error-handling-10.txt. > But maybe that was just too much nit-picking? It's entirely possible I missed it; I'll go review your comments a little l= ater today.=20 Thanks! --John From nobody Tue Jun 3 10:25:19 2014 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 EF8181A023D for ; Tue, 3 Jun 2014 10:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lElsqVcbloH8 for ; Tue, 3 Jun 2014 10:25:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F6E1A0249 for ; Tue, 3 Jun 2014 10:25:15 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB247.namprd05.prod.outlook.com (10.255.191.23) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 17:25:08 +0000 Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 17:25:06 +0000 Received: from BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) by BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) with mapi id 15.00.0949.001; Tue, 3 Jun 2014 17:25:06 +0000 From: John Scudder To: John Scudder Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-11.txt Thread-Index: AQHPf0qLABCgXuMyakWT9Nibuw5CzZtfmT3TgAAJsQA= Date: Tue, 3 Jun 2014 17:25:05 +0000 Message-ID: <3022AAA5-2911-44CE-9983-0F8D3EE569D8@juniper.net> References: <20140603160649.23301.49105.idtracker@ietfa.amsl.com> <538DFA3D.9030305@benocs.com> <6BAC6EE0-6FAF-432A-A31C-BA3E4E616825@juniper.net> In-Reply-To: <6BAC6EE0-6FAF-432A-A31C-BA3E4E616825@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [204.38.191.149] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02318D10FB x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(189002)(199002)(377454003)(24454002)(558084003)(74662001)(31966008)(74502001)(99286001)(4396001)(82746002)(81342001)(83072002)(81542001)(99396002)(77096999)(101416001)(79102001)(21056001)(86362001)(64706001)(2656002)(92726001)(33656002)(36756003)(19580405001)(50986999)(20776003)(54356999)(83716003)(76176999)(83322001)(46102001)(19580395003)(87936001)(76482001)(85852003)(77982001)(92566001)(80022001)(66066001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:BLUPR05MB722.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: <9E7D74628C09D84B8E30E34F8371F471@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/wddakhn76aUEk3AVXiz4TYCh4xY Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 17:25:18 -0000 On Jun 3, 2014, at 12:50 PM, John Scudder wrote: >=20 > It's entirely possible I missed it; I'll go review your comments a little= later today. I did indeed miss your note from Friday. I'll review and possibly produce a= -12. (So let's hold off on the WGLC.) --John= From nobody Tue Jun 3 12:56:17 2014 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 15CEB1A032B; Tue, 3 Jun 2014 12:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrE9grmRn7jg; Tue, 3 Jun 2014 12:56:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBFB1A0032; Tue, 3 Jun 2014 12:56:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140603195614.16496.88334.idtracker@ietfa.amsl.com> Date: Tue, 03 Jun 2014 12:56:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/GqD8qLFdkgNCLg-3wmBUTMVfklw Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:56:15 -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 : Notification Message support for BGP Graceful Restart Authors : Keyur Patel Rex Fernando John Scudder Jeff Haas Filename : draft-ietf-idr-bgp-gr-notification-03.txt Pages : 7 Date : 2014-06-03 Abstract: The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-gr-notification-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 3 12:56:23 2014 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 BDE661A0351 for ; Tue, 3 Jun 2014 12:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xcTgmv4gPdpa for ; Tue, 3 Jun 2014 12:56:17 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98FA31A032B for ; Tue, 3 Jun 2014 12:56:17 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB008.namprd05.prod.outlook.com (10.255.210.155) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 19:56:10 +0000 Received: from [172.29.32.187] (66.129.241.10) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 19:56:09 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <53889E84.7040305@benocs.com> Date: Tue, 3 Jun 2014 15:55:54 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140529234924.20688.23855.idtracker@ietfa.amsl.com> <53889E84.7040305@benocs.com> To: X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: DM2PR08CA009.namprd08.prod.outlook.com (10.141.52.167) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02318D10FB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(189002)(199002)(377454003)(24454002)(50226001)(77156001)(88136002)(74662001)(31966008)(74502001)(82746002)(93916002)(4396001)(50466002)(81342001)(62966002)(83072002)(81542001)(104166001)(101416001)(79102001)(99396002)(86362001)(64706001)(57306001)(21056001)(42186004)(87976001)(89996001)(92726001)(33656002)(19580405001)(50986999)(20776003)(87286001)(23746002)(36756003)(83716003)(76176999)(85852003)(76482001)(46102001)(83322001)(19580395003)(92566001)(66066001)(80022001)(77982001)(102836001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:[172.29.32.187]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/p_yhwNZuPGTVnY90sveD4ZryxXQ Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:56:21 -0000 On May 30, 2014, at 11:06 AM, Deniz Bahadir wrote: > I appreciate the ambiguity about attribute flags being addressed. Just = one question: Shouldn't a well-known attribute also be considered to = have conflicting flags if the partial bit is set? The point makes sense. On the other hand, given that the motivation for = this document was to reduce operational pain caused by picky BGP = implementations, it is not at all obvious that it makes sense to = introduce a new error condition. Existing implementations I=92m aware of = always treated the =93must be consistent=94 rule from RFC 4271 as = meaning =93optional and transitive must be set the way they were = specced=94 so we just imported that standard practice into the = error-handling draft without trying to expand the scope. I=92ll address your other points separately. =97John= From nobody Tue Jun 3 13:41:29 2014 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 027A71A0271 for ; Tue, 3 Jun 2014 13:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NxHOmSmmWMCS for ; Tue, 3 Jun 2014 13:41:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FD21A0370 for ; Tue, 3 Jun 2014 13:41:24 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB723.namprd05.prod.outlook.com (10.141.207.153) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 20:41:16 +0000 Received: from BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) by BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) with mapi id 15.00.0949.001; Tue, 3 Jun 2014 20:41:16 +0000 From: John Scudder To: "idr@ietf. org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-03.txt Thread-Index: AQHPf2wpxUuXaE2QL0StmcKJqkJkoQ== Date: Tue, 3 Jun 2014 20:41:15 +0000 Message-ID: <066BD668-1F30-4F31-A49A-206D8556A594@juniper.net> References: <20140603195614.16496.88334.idtracker@ietfa.amsl.com> In-Reply-To: <20140603195614.16496.88334.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [208.75.18.14] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02318D10FB x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(377424004)(164054003)(51704005)(377454003)(24454002)(2656002)(92726001)(19580405001)(92566001)(101416001)(15975445006)(77982001)(15202345003)(86362001)(85852003)(82746002)(87936001)(81542001)(83716003)(46102001)(4396001)(99286001)(76482001)(81342001)(19580395003)(76176999)(54356999)(83322001)(31966008)(21056001)(33656002)(77096999)(20776003)(36756003)(66066001)(79102001)(83072002)(80022001)(74502001)(74662001)(99396002)(50986999)(64706001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB723; H:BLUPR05MB722.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: <59C756557048EE4FB7C05EAD4F2F67D8@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/13CByoGOIhgXeKg2SyB-q8FEKAw Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:41:27 -0000 This version incorporates Chris Hall's suggestion from the WGLC: > Why not treat the Hard Reset Code=3D6 Subcode=3D9 as a two octet prefix o= n > the complete original NOTIFICATION message ? Thanks, --John > On Jun 3, 2014, at 3:56 PM, wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Inter-Domain Routing Working Group of th= e IETF. >=20 > Title : Notification Message support for BGP Graceful Re= start > Authors : Keyur Patel > Rex Fernando > John Scudder > Jeff Haas > Filename : draft-ietf-idr-bgp-gr-notification-03.txt > Pages : 7 > Date : 2014-06-03 >=20 > Abstract: > The current BGP Graceful Restart mechanism limits the usage of BGP > Graceful Restart to BGP protocol messages other than a BGP > NOTIFICATION message. This document defines an extension to the BGP > Graceful Restart that permits the Graceful Restart procedures to be > performed when the BGP speaker receives a BGP NOTIFICATION Message. > This document also defines a new BGP NOTIFICATION Cease Error subcode > to prevent BGP speakers supporting the extension defined in this > document from performing a Graceful Restart. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-gr-notification-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jun 4 13:40:26 2014 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 197C61A02F0 for ; Wed, 4 Jun 2014 13:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 DKbVOd1qAL5N for ; Wed, 4 Jun 2014 13:40:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BB7561A0024 for ; Wed, 4 Jun 2014 13:40:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A736FC2A4; Wed, 4 Jun 2014 16:40:17 -0400 (EDT) Date: Wed, 4 Jun 2014 16:40:17 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140604204017.GB13606@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521163621.GF9789@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/EOU-GKidIfWNhlAG_UFaIzBzFUY Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target 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, 04 Jun 2014 20:40:25 -0000 On Wed, May 21, 2014 at 06:46:03PM +0200, Robert Raszuk wrote: > Assume I do have a valid SR application to filter tiny subset of > Internet table. For this I can mark such tiny subset of routes with > RTs, enable RTC and activate RT filtering on IPv4 session. After letting this thought get some of my background thinking time during a very nice vacation, I think you've identified a key argument. When the expectation is you want to apply RT-C to an AF that isn't normally VPN-like (and we've identified we may want to generally do this), the routes may not be normally tagged with RTs. This suggests the behavior we want may be: - Permit a per-peer, per-AFI/SAFI knob to enable/disable RT-C processing. JUNOS, e.g., filters VPN families by default. - Provide for exceptions to the rule and document them. That second point covers the MDT scenario. It also suggests that IDR should probably make sure the other WGs using BGP as a transport for their VPNs or otherwise using RTs should be reminded that RT-C exists and their extensions had best document their interaction with it if they inconsistently RT tag their routes. -- Jeff From nobody Wed Jun 4 13:52:02 2014 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 5BC401A032D for ; Wed, 4 Jun 2014 13:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DvRVmmWCEdq for ; Wed, 4 Jun 2014 13:51:56 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758711A0309 for ; Wed, 4 Jun 2014 13:51:56 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id rp18so55609iec.14 for ; Wed, 04 Jun 2014 13:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+5A55ZJFJvijml8GN2OpxpntyWVFlsQ2rjfxpJlS8Hc=; b=pTEJV3YfrBJiPqwG8sHQ/xL+lfMts/4LW/vK75N3y3z/YfS/c/nJDNTuiMXRbL820h o9LTpHFN9IMeIKqW8ogkAdQYw5wny3+XeMtaen+96zoOJG6s7B5wnmBveNukZwCJcZEJ TlmG+q7gUtFH/Xm+delGyYSM8hF3uIY2yhFaYSFv+Fn+PG6ft4JB7PIiSQ2F6fghE4AH BSAwr8WeRoFPpH1tB8hObUWdcp+lCXFXhZxNErJ6J2VIerWhpbVqrORB1zkwtxCa7K37 9pqSjm+w3280pcmL+WcNhJWUUWBZS6TKxJV2Vk2b87ljEd2qxPHB+hUbbMlUeQhPxdJl 0lRw== MIME-Version: 1.0 X-Received: by 10.50.36.106 with SMTP id p10mr11471781igj.9.1401915110142; Wed, 04 Jun 2014 13:51:50 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 4 Jun 2014 13:51:50 -0700 (PDT) In-Reply-To: <20140604204017.GB13606@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521163621.GF9789@pfrc> <20140604204017.GB13606@pfrc> Date: Wed, 4 Jun 2014 22:51:50 +0200 X-Google-Sender-Auth: gnTIlGOVvViWXQluI00Yk0_scKM Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_Dpvjb63zaGvLckABQCDSPxJN8M Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target 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, 04 Jun 2014 20:51:58 -0000 Hi Jeff, Naturally I fully agree with your conclusion ;-) > - Permit a per-peer, per-AFI/SAFI knob to enable/disable RT-C processing. > - Provide for exceptions to the rule and document them. I think all implementations of RTC I looked at do both of those already (modulo your definition of "RT-C processing"). You are nowhere mentioning the need for NULL-RT encoding which sort of leads me to guess that you want this to be a static config on both ends per peer/per safi. Is this what the hidden context is ? If so I would be actually fine with that too. Just let's spell it out for clarity. After all you provision SAFI once for all so extra setup twick for MDT safi as example should be peanut. Best, R. On Wed, Jun 4, 2014 at 10:40 PM, Jeffrey Haas wrote: > On Wed, May 21, 2014 at 06:46:03PM +0200, Robert Raszuk wrote: >> Assume I do have a valid SR application to filter tiny subset of >> Internet table. For this I can mark such tiny subset of routes with >> RTs, enable RTC and activate RT filtering on IPv4 session. > > After letting this thought get some of my background thinking time during a > very nice vacation, I think you've identified a key argument. When the > expectation is you want to apply RT-C to an AF that isn't normally VPN-like > (and we've identified we may want to generally do this), the routes may not > be normally tagged with RTs. > > This suggests the behavior we want may be: > - Permit a per-peer, per-AFI/SAFI knob to enable/disable RT-C processing. > JUNOS, e.g., filters VPN families by default. > - Provide for exceptions to the rule and document them. > > That second point covers the MDT scenario. It also suggests that IDR should > probably make sure the other WGs using BGP as a transport for their VPNs or > otherwise using RTs should be reminded that RT-C exists and their extensions > had best document their interaction with it if they inconsistently RT tag > their routes. > > -- Jeff From nobody Wed Jun 4 14:02:45 2014 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 DA49D1A03D7 for ; Wed, 4 Jun 2014 14:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 TGezdD5FkCzK for ; Wed, 4 Jun 2014 14:02:33 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0321A0345 for ; Wed, 4 Jun 2014 14:02:30 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3840CC3F7; Wed, 4 Jun 2014 17:02:24 -0400 (EDT) Date: Wed, 4 Jun 2014 17:02:24 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140604210224.GC13606@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521163621.GF9789@pfrc> <20140604204017.GB13606@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/XpIhuuTXobdbKETaUnd7IhuvgJM Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target 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, 04 Jun 2014 21:02:38 -0000 Robert, On Wed, Jun 04, 2014 at 10:51:50PM +0200, Robert Raszuk wrote: > > - Permit a per-peer, per-AFI/SAFI knob to enable/disable RT-C processing. > > - Provide for exceptions to the rule and document them. > > I think all implementations of RTC I looked at do both of those > already (modulo your definition of "RT-C processing"). That second point, for MDT, is what prompted the whole conversation in the first place. JUNOS and another vendor weren't interoperating when RT-C was enabled. If we read the RT-C spec as "no RT, then route is filtered out", the other vendor is non-conformant. The fact that the MDT spec said that RTs are optional is mostly the fact that the feature wasn't reconciled against RT-C's filtering behavior. > You are nowhere mentioning the need for NULL-RT encoding which sort of > leads me to guess that you want this to be a static config on both > ends per peer/per safi. Is this what the hidden context is ? > > If so I would be actually fine with that too. Just let's spell it out > for clarity. That's what I'm suggesting. The idea of a NULL-RT-C isn't something I'm a fan of. If the above gains consensus, I'm not sure there's anything to be put in an I-D. If there is, it's "RT-C procedures may be disabled on an AFI/SAFI that is provisioned to use it on a per-route basis when that route does not contain a RT. This is currently recommended for ..." Personally, I'm at my quota for small janitorial RFCs for the moment. Maybe once one of my current ones hit RFC I'll volunteer. :-) -- Jeff From nobody Thu Jun 5 04:40:32 2014 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 6CB851A004E for ; Thu, 5 Jun 2014 04:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=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 qhHaA-faDCTa for ; Thu, 5 Jun 2014 04:40:28 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987C91A0049 for ; Thu, 5 Jun 2014 04:40:28 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so9454217wib.1 for ; Thu, 05 Jun 2014 04:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=RS6SgJIHcX/UC1c4Xe2ZzMSSAx+fc9CycIWWogf5SLM=; b=t1jAn9tZjGJeQKb60ymcxQB1M2rR/1uk7PAtDOv1IaNymriiOKDhV0i10+5fahhXE5 9edDE8b+XTbiynKTONfWOiKTTTRLfoSON8tATW3CddbQYrnziE7MMXOGlixkWTtHFd78 Frz14tR7MYW7JUNeZuK5tRzFC6s05Zp0nj2jMScvQnPbFQzMvNrTO5MimfEzhFbGtPbl bRF7osoLTGynpgHWfvPjVzKkVOtYOTJFRxNpXzoPe4dx16ocPb6Z6OVMBPUZGbhl8wC5 A0b9PMbbJaUc5oZqcX1680plf1uTUObxmrJ4M2ncKpcSwFzQZneqs1koSq2aQ5Ortuz7 AlPQ== X-Received: by 10.180.78.225 with SMTP id e1mr15087075wix.17.1401968421320; Thu, 05 Jun 2014 04:40:21 -0700 (PDT) Received: from [127.0.0.1] (ARennes-652-1-78-168.w2-11.abo.wanadoo.fr. [2.11.181.168]) by mx.google.com with ESMTPSA id s9sm53712777wix.13.2014.06.05.04.40.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 04:40:20 -0700 (PDT) Sender: Thomas Morin Message-ID: <53905723.2090803@orange.com> Date: Thu, 05 Jun 2014 13:40:19 +0200 From: Thomas Morin Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: idr@ietf.org References: <5390565A.50407@orange.com> In-Reply-To: <5390565A.50407@orange.com> X-Forwarded-Message-Id: <5390565A.50407@orange.com> Content-Type: multipart/mixed; boundary="------------050300070105030008010607" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/lW2bwMe4moQZUgwMSvoBCVbzQG4 Subject: [Idr] Fwd: WG Last Call for draft-ietf-l3vpn-acceptown-community 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, 05 Jun 2014 11:40:30 -0000 This is a multi-part message in MIME format. --------------050300070105030008010607 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI. -Thomas --------------050300070105030008010607 Content-Type: message/rfc822; name="WG Last Call for draft-ietf-l3vpn-acceptown-community" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="WG Last Call for draft-ietf-l3vpn-acceptown-community" Message-ID: <5390565A.50407@orange.com> Date: Thu, 05 Jun 2014 13:36:58 +0200 From: Thomas Morin Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: L3VPN Subject: WG Last Call for draft-ietf-l3vpn-acceptown-community Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello working group, This email starts a Working Group Last Call on draft-ietf-l3vpn-acceptown-community, which is considered mature and ready for a last call working group review. Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than **June 20th**. Thank you, -Thomas & Martin [ http://tools.ietf.org/html/draft-ietf-l3vpn-acceptown-community ] --------------050300070105030008010607-- From nobody Thu Jun 5 10:53:39 2014 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 A5EFD1A028D for ; Thu, 5 Jun 2014 10:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KiWPEE1iucIz for ; Thu, 5 Jun 2014 10:53:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F851A0285 for ; Thu, 5 Jun 2014 10:53:34 -0700 (PDT) Received: from [172.29.32.187] (66.129.241.10) by DM2PR05MB735.namprd05.prod.outlook.com (10.141.178.24) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 5 Jun 2014 17:53:27 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <53889E84.7040305@benocs.com> Date: Thu, 5 Jun 2014 13:53:13 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3505FEBE-296E-4BBF-B2B6-AD6D41486295@juniper.net> References: <20140529234924.20688.23855.idtracker@ietfa.amsl.com> <53889E84.7040305@benocs.com> To: X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BLUPR02CA004.namprd02.prod.outlook.com (10.255.223.152) To DM2PR05MB735.namprd05.prod.outlook.com (10.141.178.24) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(24454002)(377424004)(377454003)(199002)(189002)(93916002)(85852003)(92726001)(86362001)(66066001)(99396002)(80022001)(76176999)(50986999)(101416001)(81342001)(62966002)(74502001)(50226001)(81542001)(36756003)(4396001)(74662001)(102836001)(21056001)(15975445006)(104166001)(20776003)(79102001)(47776003)(64706001)(50466002)(76482001)(15202345003)(83322001)(42186004)(77156001)(83716003)(57306001)(82746002)(19580395003)(33656002)(87286001)(87976001)(46102001)(89996001)(19580405001)(77982001)(88136002)(83072002)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB735; H:[172.29.32.187]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/tiu5BFN7EXa6-NaNyCnF3IyapNc Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:53:37 -0000 On May 30, 2014, at 11:06 AM, Deniz Bahadir wrote: > 1. > It occurs to me that the title of section 7 ("Error Handling = Procedures for Existing Attributes") implies to address *all* existing = attributes. The first sentence, however, seems to mitigate that by = saying the following subsections "elaborate on the conditions for = error-checking *various* path attributes". > Nevertheless, for sake of completeness, I would recommend to mention = all (non-deprecated) path attributes (as can be found = here:http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml) = in the following subsections. Fair point. We originally didn=92t set out to do this for every possible = attribute, but given we=92re most of the way there it may be that we = should try to finish the job. That said, by my reading (see below for = details) only a few need to be covered: - 24 Traffic Engineering - 25 IPv6 Address Specific Extended Community - 28 BGP Entropy Label Capability Attribute - 128 ATTR_SET Barring objections, I will look at adding them to the next version of = the draft. The rest look OK to me. I guess to remove any doubt in the mind of the = reader we could put in a section that says =93for attributes 17, 18, 22, = 23, 26, 27 and 29, error handling is defined in the relevant = specification. Attributes 11, 12, 13, 19, 20 and 21 are deprecated.=94 = Then again, that=92s just the equivalent of =93this page intentionally = left blank=94. I guess I=92ll add something like that unless there are = objections. =97John My take on all the non-deprecated attributes below. This is based on a = pretty quick skim; further comments are welcome. 17 AS4_PATH [RFC6793] 18 AS4_AGGREGATOR [RFC6793] RFC 6793 already has an error handling section that=92s =97 by design =97 = consistent with what=92s required by error-handling. 22 PMSI_TUNNEL [RFC6514] Same for this one =97 section 5 looks good. 23 Tunnel Encapsulation Attribute [RFC5512] The =93error handling=94 section is a bit ambiguous but essentially = follows the same model as =93treat-as-withdraw". I=92d be OK with = leaving it alone. 24 Traffic Engineering [RFC5543] This does need work. 25 IPv6 Address Specific Extended Community [RFC5701] Ditto. 26 AIGP [RFC-ietf-idr-aigp-18] Like RFC 6793, the AIGP spec has reasonable error handling section = already and explicitly references error-handling. 27 PE Distinguisher Labels [RFC6514] This also has a section (S. 5) that follows the draft already. 28 BGP Entropy Label Capability Attribute [RFC6790] Looks like this needs some work.=20 29 BGP-LS Attribute (TEMPORARY - expires 2015-03-11) = [draft-ietf-idr-ls-distribution] This is still in draft; I think the draft should be updated to cover the = necessary. I=92ll make sure the authors know to do so. 128 ATTR_SET [RFC6368] The error handling section here references the old = draft-ietf-idr-optional-transitive, and should be updated to say that = the error handling should be treat-as-withdraw always and not only if = the partial bit is set. From nobody Fri Jun 6 00:42:11 2014 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 270711A0376 for ; Fri, 6 Jun 2014 00:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 18fv9URX05O8 for ; Fri, 6 Jun 2014 00:42:07 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id E171F1A017A for ; Fri, 6 Jun 2014 00:42:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id 90B2A6421B4; Fri, 6 Jun 2014 09:41:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDSnFR4ySocn; Fri, 6 Jun 2014 09:41:57 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id 893F2642175; Fri, 6 Jun 2014 09:41:57 +0200 (CEST) Message-ID: <539170C4.8040101@benocs.com> Date: Fri, 06 Jun 2014 09:41:56 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "John G. Scudder" References: <20140529234924.20688.23855.idtracker@ietfa.amsl.com> <53889E84.7040305@benocs.com> <3505FEBE-296E-4BBF-B2B6-AD6D41486295@juniper.net> In-Reply-To: <3505FEBE-296E-4BBF-B2B6-AD6D41486295@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/4K5_sdUeELvRo4h3IRlaF1rIE4Q Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 07:42:09 -0000 Am 05.06.2014 19:53, schrieb John G. Scudder: > - 24 Traffic Engineering > - 25 IPv6 Address Specific Extended Community > - 28 BGP Entropy Label Capability Attribute > - 128 ATTR_SET > > Barring objections, I will look at adding them to the next version of the draft. That is fine with me. > The rest look OK to me. I guess to remove any doubt in the mind of the reader we could put in a section that says “for attributes 17, 18, 22, 23, 26, 27 and 29, error handling is defined in the relevant specification. Attributes 11, 12, 13, 19, 20 and 21 are deprecated.” Then again, that’s just the equivalent of “this page intentionally left blank”. I guess I’ll add something like that unless there are objections. I would pretty much appreciate such an additional sentence, to let the reader know that this document did not leave out any (currently existing) attribute by accident. > 17 AS4_PATH [RFC6793] > 18 AS4_AGGREGATOR [RFC6793] > > RFC 6793 already has an error handling section that’s — by design — consistent with what’s required by error-handling. OK, with the additional sentence from the former comment I would retract my original comment 2 and am fine with not giving AS4_PATH and AS4_AGGREGATOR a subsection for their own. :-) Likewise for the other attributes mentioned in that sentence. Deniz From nobody Fri Jun 6 12:38:21 2014 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 CB6801A0228; Fri, 6 Jun 2014 12:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUIi3dhPTsJe; Fri, 6 Jun 2014 12:38:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBA81A016F; Fri, 6 Jun 2014 12:38:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606193814.32058.51946.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 12:38:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/I8q1aGJXq-iunmOUgT9eWrIjOII Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-enhanced-route-refresh-07.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, 06 Jun 2014 19:38:16 -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 : Enhanced Route Refresh Capability for BGP-4 Authors : Keyur Patel Enke Chen Balaji Venkatachalapathy Filename : draft-ietf-idr-bgp-enhanced-route-refresh-07.txt Pages : 7 Date : 2014-06-05 Abstract: In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP RIB inconsistencies in a non-disruptive manner. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-enhanced-route-refresh-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 6 13:04:05 2014 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 914F21A0086; Fri, 6 Jun 2014 13:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWJRvqgJsGsE; Fri, 6 Jun 2014 13:04:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F02271A018F; Fri, 6 Jun 2014 13:03:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606200359.32058.88453.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 13:03:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/OI5esLFnZURGk7MHsVMj3MyLaPc Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-enhanced-route-refresh-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 20:04:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Enhanced Route Refresh Capability for BGP-4 Authors : Keyur Patel Enke Chen Balaji Venkatachalapathy Filename : draft-ietf-idr-bgp-enhanced-route-refresh-08.txt Pages : 7 Date : 2014-06-06 Abstract: In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP RIB inconsistencies in a non-disruptive manner. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-enhanced-route-refresh-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 9 08:29:44 2014 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 61CD61A020B; Mon, 9 Jun 2014 08:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Wx7mrnm1EfK; Mon, 9 Jun 2014 08:29:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2827D1A01C5; Mon, 9 Jun 2014 08:29:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140609152939.16672.24234.idtracker@ietfa.amsl.com> Date: Mon, 09 Jun 2014 08:29:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jmfu6FFiGWiW8smyIAtUfsAWs6c Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ix-bgp-route-server-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:29: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 : Internet Exchange Route Server Authors : Elisa Jasinska Nick Hilliard Robert Raszuk Niels Bakker Filename : draft-ietf-idr-ix-bgp-route-server-05.txt Pages : 11 Date : 2014-06-09 Abstract: This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more exterior BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ix-bgp-route-server-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ix-bgp-route-server-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 9 10:08:35 2014 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 553711A0291; Mon, 9 Jun 2014 10:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PKsyAq0R8s0; Mon, 9 Jun 2014 10:08:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1044F1A0278; Mon, 9 Jun 2014 10:08:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140609170829.29175.95559.idtracker@ietfa.amsl.com> Date: Mon, 09 Jun 2014 10:08:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/8z5hWmqPQ44DBPn6o-4QGGnerkY Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-enhanced-route-refresh-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:08:30 -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 : Enhanced Route Refresh Capability for BGP-4 Authors : Keyur Patel Enke Chen Balaji Venkatachalapathy Filename : draft-ietf-idr-bgp-enhanced-route-refresh-09.txt Pages : 7 Date : 2014-06-09 Abstract: In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP RIB inconsistencies in a non-disruptive manner. This document updates RFC 2918. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-enhanced-route-refresh-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 10 04:36:57 2014 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 CD2911A0047; Tue, 10 Jun 2014 04:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TUsLIim3F_u; Tue, 10 Jun 2014 04:36:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9A01B27BA; Tue, 10 Jun 2014 04:36:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140610113650.8178.14749.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 04:36:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/qQQ2QPOV6PqoaX_AxpSp2aG_tpo Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ipv6-rt-constrain-05.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, 10 Jun 2014 11:36:52 -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 : IPv6 Extensions for Route Target Distribution Authors : Keyur Patel Robert Raszuk Martin Djernaes Jie Dong Mach(Guoyi) Chen Filename : draft-ietf-idr-bgp-ipv6-rt-constrain-05.txt Pages : 5 Date : 2014-06-10 Abstract: The current route target distribution specification described in RFC4684 defines Route Target NLRIs of maximum length of 12 bytes. The IPv6 specific Route Target extended community is defined in [RFC5701] as length of 20 bytes. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when an operator wants to use this application in a pure IPv6 environment. This document defines an extension that allows BGP to exchange longer length IPv6 Route Target prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrain/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-ipv6-rt-constrain-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ipv6-rt-constrain-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 10 06:37:21 2014 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 204FA1A0113; Tue, 10 Jun 2014 06:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kBqHljU4ngy; Tue, 10 Jun 2014 06:37:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F7D1A010C; Tue, 10 Jun 2014 06:37:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140610133713.4696.68668.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 06:37:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/-9u8UHvwsE9evBaRs8ENEmXfnwI Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-reserved-extended-communities-07.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, 10 Jun 2014 13:37:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Assigned BGP extended communities Authors : Bruno Decraene Pierre Francois Filename : draft-ietf-idr-reserved-extended-communities-07.txt Pages : 6 Date : 2014-06-10 Abstract: This document defines an IANA registry in order to assign non- transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide a control over inter-AS community advertisement as, per RFC RFC 4360, they are not transitive across Autonomous System boundaries. For that purpose, this document defines the use of the reserved Autonomous System number 0.65535 in the non-transitive generic four- octet AS specific extended community type. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-reserved-extended-communities/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-reserved-extended-communities-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-reserved-extended-communities-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 10 07:34:13 2014 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 1703C1B27B8 for ; Tue, 10 Jun 2014 07:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2y3AOxHpSr9 for ; Tue, 10 Jun 2014 07:34:08 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4923C1A0193 for ; Tue, 10 Jun 2014 07:34:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Tue, 10 Jun 2014 10:31:38 -0400 Message-ID: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01CF8497.29E4EAB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+EuHw5L41l4bFiTXG0bCzBOIK+Xg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/TTUPkgVtoWwH90O1Lt6NrWv1Vcw Cc: "Murphy, Sandra" , "'John G. Scudder'" Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 10 Jun 2014 14:34:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002B_01CF8497.29E4EAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR: The SIDR WG has asked for cross review of the draft-ietf-sidr-origin-validation-signaling-04. This draft changes the RFC 4271 decision process in the following manner: If a BGP router supports prefix origin validation and is configured for the extensions defined in this document, the validation step SHOULD be performed prior to any of the steps defined in the decision process of [RFC4271 ]. The validation step is stated as follows: When comparing a pair of routes for a BGP destination, the route with the lowest "validation state" value is preferred. In all other respects, the decision process remains unchanged. The draft is at: http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 John and I would like to hear your comments regarding the RFC 4271 revision. Please send comments that include "support" or "no support". Sue and John ------=_NextPart_000_002B_01CF8497.29E4EAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR:

 

The SIDR WG has asked for cross = review of the draft-ietf-sidr-origin-validation-signaling-04.  This = draft changes the RFC 4271 decision process in the following manner: =

 

 
If a BGP =
router supports prefix origin validation and is configured for the =
extensions defined in this document, the validation step SHOULD be =
performed prior to any of the steps defined in the decision process of =
[RFC4271].  The validation =
step is stated as follows:
 
      When comparing a =
pair of routes for a BGP destination, the =
route
      with the lowest =
"validation state" value is =
preferred.
 
In all =
other respects, the decision process remains =
unchanged.

 

The draft is at: =

 

http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-si= gnaling-04

 

John and I would = like to hear your comments regarding the RFC 4271 revision.  Please = send comments that include “support”  or “no = support”.

 

Sue and John =

------=_NextPart_000_002B_01CF8497.29E4EAB0-- From nobody Tue Jun 10 08:40:13 2014 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 223561A01CB for ; Tue, 10 Jun 2014 08:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 V_XYtk8P3zze for ; Tue, 10 Jun 2014 08:40:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91731A01A7 for ; Tue, 10 Jun 2014 08:40:08 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 280B91E80D7; Tue, 10 Jun 2014 17:40:07 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 06A9E4C05D; Tue, 10 Jun 2014 17:40:07 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 17:40:06 +0200 From: To: Susan Hares , idr wg Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: Ac+EuHw5L41l4bFiTXG0bCzBOIK+XgABjfiQ Date: Tue, 10 Jun 2014 15:40:05 +0000 Message-ID: <29140_1402414807_539726D7_29140_10276_1_53C29892C857584299CBF5D05346208A0716175D@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> In-Reply-To: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0716175DPEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.10.133619 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/5BHX0D-LlUVDf7xDu38S_mEt874 Cc: "'John G. Scudder'" , "Murphy, Sandra" Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 10 Jun 2014 15:40:12 -0000 --_000_53C29892C857584299CBF5D05346208A0716175DPEXCVZYM11corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the cross WG review. Please find below some proposed comments. 1) For people not following SIDR, could you please elaborate on why ht= tp://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been use= d? (via the registration of a new Point of Insertion specific to origin val= idation) (as I though draft-ietf-idr-custom-decision was intended to be the= last time BGP decision process would be modified) 2) Could the document specify the action to be taken when multiple "Or= igin validation state extended" community are present with different valida= tion state? And how are handled validation state value > 2. (from current t= ext, it would not be considered an error, just lower priority. But I would = prefer an explicit statement to avoid surprising error handling behavior) 3) Rfc 6811 is referenced twice in important sections. What about movi= ng it to "normative reference"? 4) Following discussion triggered by http://tools.ietf.org/html/draft-= decraene-idr-rfc4360-clarification-00 I understood that the IDR conclusion = was that a non-transitive community may be attached on the outbound policy = of an eBGP session; hence may received over an eBGP session. Given this, IM= O the security consideration needs more text. (assuming that the ability fo= r a neighboring AS to influence/force the origin validation state is consid= ered acceptable, which would probably need to be discussed in SIDR) Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, June 10, 2014 4:32 PM To: idr wg Cc: Murphy, Sandra; 'John G. Scudder' Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signa= ling-04 - RFC4271 changes IDR: The SIDR WG has asked for cross review of the draft-ietf-sidr-origin-valida= tion-signaling-04. This draft changes the RFC 4271 decision process in the= following manner: If a BGP router supports prefix origin validation and is configured for the= extensions defined in this document, the validation step SHOULD be perform= ed prior to any of the steps defined in the decision process of [RFC4271]. The validation step is stated as follo= ws: When comparing a pair of routes for a BGP destination, the route with the lowest "validation state" value is preferred. In all other respects, the decision process remains unchanged. The draft is at: http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 John and I would like to hear your comments regarding the RFC 4271 revision= . Please send comments that include "support" or "no support". Sue and John ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0716175DPEXCVZYM11corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

Thanks = for the cross WG review. Please find below some proposed comments.

&n= bsp;

= 1)      For people not following SIDR, could you please elaborate on why ht= tp://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been= used? (via the registration of a new Point of Insertion specific to origin= validation) (as I though draft-ietf-idr-custom-decision was intended to be the last time BGP decision process would be modified)

&n= bsp;

= 2)      Could the document specify the action to be taken when multiple “Ori= gin validation state extended” community are present with different v= alidation state? And how are handled validation state value > 2. (from current text, it would not be considered an erro= r, just lower priority. But I would prefer an explicit statement to avoid s= urprising error handling behavior)

=  

= 3)      Rfc 6811 is referenced twice in important sections. What about moving it t= o “normative reference”?

=  

= 4)      Following discussion triggered by http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 = I understood that the IDR conclusion was that a non-transitive community ma= y be attached on the outbound policy of an eBGP session; hence may received= over an eBGP session. Given this, IMO the security consideration needs more text. (assuming that the ability= for a neighboring AS to influence/force the origin validation state is con= sidered acceptable, which would probably need to be discussed in SIDR)=

=  

Thanks,=

Regards= ,

Bruno

&n= bsp;

&n= bsp;

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, June 10, 2014 4:32 PM
To: idr wg
Cc: Murphy, Sandra; 'John G. Scudder'
Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validatio= n-signaling-04 - RFC4271 changes

 

IDR:

 

The SIDR WG has asked for cross review of the draft-ietf-sid= r-origin-validation-signaling-04.  This draft changes the RFC 4271 dec= ision process in the following manner:

 

 
If a BGP router supports prefix origin validation and is configured=
 for the extensions defined in this document, the validation step SHOULD be=
 performed prior to any of the steps defined in the decision process of [RFC4271].  The validation step is stat=
ed as follows:
 
      When comparing a pair of routes for =
a BGP destination, the route
      with the lowest "validation sta=
te" value is preferred.
 
In all other respects, the decision process remains unchanged.=

 

The draft is at:

 

http://tools.ietf.org/html/draft= -ietf-sidr-origin-validation-signaling-04

 

John and I would like to hear your comments= regarding the RFC 4271 revision.  Please send comments that include &= #8220;support”  or “no support”.

 

Sue and John 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0716175DPEXCVZYM11corpo_-- From nobody Tue Jun 10 08:49:16 2014 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 756F81A01C0 for ; Tue, 10 Jun 2014 08:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 sYi_ujVC6VZe for ; Tue, 10 Jun 2014 08:49:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727001A01BF for ; Tue, 10 Jun 2014 08:49:08 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 8A7F032455C; Tue, 10 Jun 2014 17:49:06 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 67CD7238067; Tue, 10 Jun 2014 17:49:06 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 17:49:06 +0200 From: To: Susan Hares , idr wg Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: Ac+EuHw5B/uGL+YYM0KA0B8arly+1wABjfiQAAEKeLA= Date: Tue, 10 Jun 2014 15:49:05 +0000 Message-ID: <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A07161787PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.10.90921 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hREVieI5gOXdu3RAE_NfoB8XM7k Cc: "'John G. Scudder'" , "Murphy, Sandra" Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 10 Jun 2014 15:49:12 -0000 --_000_53C29892C857584299CBF5D05346208A07161787PEXCVZYM11corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 5) The text in < deployment consideration > seems a bit weak. I would say that: "In deployment scenarios where not all the speakers in an= autonomous system are upgraded to support the extensions defined in this document,= in order to avoid routing loops, it is REQUIRED to define policies" ... 6) For the same purpose, IMO: OLD: The default SHOULD be for the validation step to be disabled. NEW: The default MUST be for the validation step to be disabled. Thanks, Regards, Bruno From: DECRAENE Bruno IMT/OLN Sent: Tuesday, June 10, 2014 5:40 PM To: 'Susan Hares'; idr wg Cc: Murphy, Sandra; 'John G. Scudder' Subject: RE: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-s= ignaling-04 - RFC4271 changes Hi, Thanks for the cross WG review. Please find below some proposed comments. 1) For people not following SIDR, could you please elaborate on why ht= tp://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been use= d? (via the registration of a new Point of Insertion specific to origin val= idation) (as I though draft-ietf-idr-custom-decision was intended to be the= last time BGP decision process would be modified) 2) Could the document specify the action to be taken when multiple "Or= igin validation state extended" community are present with different valida= tion state? And how are handled validation state value > 2. (from current t= ext, it would not be considered an error, just lower priority. But I would = prefer an explicit statement to avoid surprising error handling behavior) 3) Rfc 6811 is referenced twice in important sections. What about movi= ng it to "normative reference"? 4) Following discussion triggered by http://tools.ietf.org/html/draft-= decraene-idr-rfc4360-clarification-00 I understood that the IDR conclusion = was that a non-transitive community may be attached on the outbound policy = of an eBGP session; hence may received over an eBGP session. Given this, IM= O the security consideration needs more text. (assuming that the ability fo= r a neighboring AS to influence/force the origin validation state is consid= ered acceptable, which would probably need to be discussed in SIDR) Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, June 10, 2014 4:32 PM To: idr wg Cc: Murphy, Sandra; 'John G. Scudder' Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signa= ling-04 - RFC4271 changes IDR: The SIDR WG has asked for cross review of the draft-ietf-sidr-origin-valida= tion-signaling-04. This draft changes the RFC 4271 decision process in the= following manner: If a BGP router supports prefix origin validation and is configured for the= extensions defined in this document, the validation step SHOULD be perform= ed prior to any of the steps defined in the decision process of [RFC4271]. The validation step is stated as follo= ws: When comparing a pair of routes for a BGP destination, the route with the lowest "validation state" value is preferred. In all other respects, the decision process remains unchanged. The draft is at: http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 John and I would like to hear your comments regarding the RFC 4271 revision= . Please send comments that include "support" or "no support". Sue and John ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A07161787PEXCVZYM11corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

5) The = text in « deployment consideration » seems a bit weak= .

I would= say that: “In deployment scenarios where not all the speakers in an = autonomous

 &= nbsp; system are upgraded to support the extensions defined in this  d= ocument, in order to avoid routing loops, it is REQUIRED to define policies= ” …

&n= bsp;

6) For = the same purpose, IMO:

OLD: Th= e default SHOULD be for the validation step to be disabled.

NEW: Th= e default MUST be for the validation step to be disabled.=

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

&n= bsp;

From: DECRAENE= Bruno IMT/OLN
Sent: Tuesday, June 10, 2014 5:40 PM
To: 'Susan Hares'; idr wg
Cc: Murphy, Sandra; 'John G. Scudder'
Subject: RE: [Idr] 1 WG call for Review draft-ietf-sidr-origin-valid= ation-signaling-04 - RFC4271 changes

 

Hi,

&n= bsp;

Thanks = for the cross WG review. Please find below some proposed comments.

&n= bsp;

= 1)      For people not following SIDR, could you please elaborate on why ht= tp://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been= used? (via the registration of a new Point of Insertion specific to origin= validation) (as I though draft-ietf-idr-custom-decision was intended to be the last time BGP decision process would be modified)

&n= bsp;

= 2)      Could the document specify the action to be taken when multiple “Ori= gin validation state extended” community are present with different v= alidation state? And how are handled validation state value > 2. (from current text, it would not be considered an erro= r, just lower priority. But I would prefer an explicit statement to avoid s= urprising error handling behavior)

=  

= 3)      Rfc 6811 is referenced twice in important sections. What about moving it t= o “normative reference”?

=  

= 4)      Following discussion triggered by http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 = I understood that the IDR conclusion was that a non-transitive community ma= y be attached on the outbound policy of an eBGP session; hence may received= over an eBGP session. Given this, IMO the security consideration needs more text. (assuming that the ability= for a neighboring AS to influence/force the origin validation state is con= sidered acceptable, which would probably need to be discussed in SIDR)=

=  

Thanks,=

Regards= ,

Bruno

&n= bsp;

&n= bsp;

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, June 10, 2014 4:32 PM
To: idr wg
Cc: Murphy, Sandra; 'John G. Scudder'
Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validatio= n-signaling-04 - RFC4271 changes

 

IDR:

 

The SIDR WG has asked for cross review of the draft-ietf-sid= r-origin-validation-signaling-04.  This draft changes the RFC 4271 dec= ision process in the following manner:

 

 
If a BGP router supports prefix origin validation and is configured=
 for the extensions defined in this document, the validation step SHOULD be=
 performed prior to any of the steps defined in the decision process of [RFC4271].  The validation step is stat=
ed as follows:
 
      When comparing a pair of routes for =
a BGP destination, the route
      with the lowest "validation sta=
te" value is preferred.
 
In all other respects, the decision process remains unchanged.=

 

The draft is at:

 

http://tools.ietf.org/html/draft= -ietf-sidr-origin-validation-signaling-04

 

John and I would like to hear your comments= regarding the RFC 4271 revision.  Please send comments that include &= #8220;support”  or “no support”.

 

Sue and John 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A07161787PEXCVZYM11corpo_-- From nobody Tue Jun 10 09:44:15 2014 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 20DB51A024D; Tue, 10 Jun 2014 09:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEEKDT-C217l; Tue, 10 Jun 2014 09:44:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C29961A0201; Tue, 10 Jun 2014 09:44:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140610164408.6493.1373.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 09:44:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ntF5V8CPHa_M7r1-vQh74AaOQhw Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-enhanced-route-refresh-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:44:12 -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 : Enhanced Route Refresh Capability for BGP-4 Authors : Keyur Patel Enke Chen Balaji Venkatachalapathy Filename : draft-ietf-idr-bgp-enhanced-route-refresh-10.txt Pages : 7 Date : 2014-06-10 Abstract: In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP RIB inconsistencies in a non-disruptive manner. This document updates RFC 2918. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-enhanced-route-refresh-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 10 10:52:30 2014 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 8D81C1A024D; Tue, 10 Jun 2014 10:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 NT1CXSBf23WR; Tue, 10 Jun 2014 10:51:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF191A026D; Tue, 10 Jun 2014 10:51:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WuQCz-0002qe-06; Tue, 10 Jun 2014 17:51:41 +0000 Date: Tue, 10 Jun 2014 10:51:40 -0700 Message-ID: From: Randy Bush To: RFC Errata System In-Reply-To: <20140610174737.27D4F18000E@rfc-editor.org> References: <20140610174737.27D4F18000E@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: http://mailarchive.ietf.org/arch/msg/idr/jGWuLb45O7YBHMSZozk0uAHJm7M Cc: idr@ietf.org, keyupate@cisco.com, akatlas@juniper.net, bclaise@cisco.com, o@maennel.net, iesg@ietf.org Subject: Re: [Idr] [Errata Verified] RFC7196 (4011) 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, 10 Jun 2014 17:51:58 -0000 > The following errata report has been verified for RFC7196, > "Making Route Flap Damping Usable". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7196&eid=4011 > > -------------------------------------- > Status: Verified > Type: Technical > > Reported by: Benoit Claise > Date Reported: 2014-06-10 > Verified by: Alia Atlas (IESG) > > Section: Section > > Original Text > ------------- > Default RFD Paramaters of Juniper and Cisco > > > > Corrected Text > -------------- > The default RFD parameters for Cisco and Juniper > provided for the information of the reader. > > > Notes > ----- > The RFC editor note (resulting from Barry and Benoit's DISCUSS) documented at https://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/edit/ballotwriteupnotes/ has been forgotten. > > -------------------------------------- > RFC7196 (draft-ietf-idr-rfd-usable-04) > -------------------------------------- > Title : Making Route Flap Damping Usable > Publication Date : May 2014 > Author(s) : C. Pelsser, R. Bush, K. Patel, P. Mohapatra, O. Maennel > Category : PROPOSED STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG is there a way to credit vendors for cya? :) From nobody Wed Jun 11 06:39:27 2014 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 CF81B1A01DF; Tue, 10 Jun 2014 08:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 kvhtVa2LWt6n; Tue, 10 Jun 2014 08:55:07 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 66FBC1A01A6; Tue, 10 Jun 2014 08:55:07 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0D67E28B0041; Tue, 10 Jun 2014 11:55:07 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 042361F8032; Tue, 10 Jun 2014 11:55:07 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Tue, 10 Jun 2014 11:55:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8DE674B8-45B5-4102-B974-B9312106E2A8@parsons.com> References: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/pOyavbbZTtq7CIjrhWLpDztzsRo X-Mailman-Approved-At: Wed, 11 Jun 2014 06:39:25 -0700 Cc: "John G. Scudder" , idr wg , Susan Hares , "sidr@ietf.org list" Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 10 Jun 2014 15:55:09 -0000 It would be useful to include sidr on this discussion. I've added the = wg to the cc list. --Sandy On Jun 10, 2014, at 11:49 AM, wrote: > 5) The text in =AB deployment consideration =BB seems a bit weak. > I would say that: =93In deployment scenarios where not all the = speakers in an autonomous > system are upgraded to support the extensions defined in this = document, in order to avoid routing loops, it is REQUIRED to define = policies=94 =85 > =20 > 6) For the same purpose, IMO: > OLD: The default SHOULD be for the validation step to be disabled. > NEW: The default MUST be for the validation step to be disabled. > =20 > Thanks, > Regards, > Bruno > =20 > =20 > From: DECRAENE Bruno IMT/OLN=20 > Sent: Tuesday, June 10, 2014 5:40 PM > To: 'Susan Hares'; idr wg > Cc: Murphy, Sandra; 'John G. Scudder' > Subject: RE: [Idr] 1 WG call for Review = draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes > =20 > Hi, > =20 > Thanks for the cross WG review. Please find below some proposed = comments. > =20 > 1) For people not following SIDR, could you please elaborate on = why http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not = been used? (via the registration of a new Point of Insertion specific to = origin validation) (as I though draft-ietf-idr-custom-decision was = intended to be the last time BGP decision process would be modified) > =20 > 2) Could the document specify the action to be taken when = multiple =93Origin validation state extended=94 community are present = with different validation state? And how are handled validation state = value > 2. (from current text, it would not be considered an error, just = lower priority. But I would prefer an explicit statement to avoid = surprising error handling behavior) > =20 > 3) Rfc 6811 is referenced twice in important sections. What about = moving it to =93normative reference=94? > =20 > 4) Following discussion triggered by = http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 I = understood that the IDR conclusion was that a non-transitive community = may be attached on the outbound policy of an eBGP session; hence may = received over an eBGP session. Given this, IMO the security = consideration needs more text. (assuming that the ability for a = neighboring AS to influence/force the origin validation state is = considered acceptable, which would probably need to be discussed in = SIDR) > =20 > Thanks, > Regards, > Bruno > =20 > =20 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Tuesday, June 10, 2014 4:32 PM > To: idr wg > Cc: Murphy, Sandra; 'John G. Scudder' > Subject: [Idr] 1 WG call for Review = draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes > =20 > IDR: > =20 > The SIDR WG has asked for cross review of the = draft-ietf-sidr-origin-validation-signaling-04. This draft changes the = RFC 4271 decision process in the following manner: > =20 > =20 > If a BGP router supports prefix origin validation and is configured = for the extensions defined in this document, the validation step SHOULD = be performed prior to any of the steps defined in the decision process = of [RFC4271]. The validation step is stated as follows: > =20 > When comparing a pair of routes for a BGP destination, the route > with the lowest "validation state" value is preferred. > =20 > In all other respects, the decision process remains unchanged. > =20 > The draft is at: > =20 > = http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 > =20 > John and I would like to hear your comments regarding the RFC 4271 = revision. Please send comments that include =93support=94 or =93no = support=94. > =20 > Sue and John > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jun 11 06:39:28 2014 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 6587E1A01ED for ; Tue, 10 Jun 2014 08:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC3xs8OVyMXw for ; Tue, 10 Jun 2014 08:58:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 806021A01DF for ; Tue, 10 Jun 2014 08:58:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3136518000E; Tue, 10 Jun 2014 08:57:51 -0700 (PDT) To: cristel@iij.ad.jp, randy@psg.com, keyupate@cisco.com, mpradosh@yahoo.com, o@maennel.net, akatlas@gmail.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140610155751.3136518000E@rfc-editor.org> Date: Tue, 10 Jun 2014 08:57:51 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Qf8rDG5sWGjWNydJWLuNNTbPXWo X-Mailman-Approved-At: Wed, 11 Jun 2014 06:39:25 -0700 Cc: bclaise@cisco.com, idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Technical Errata Reported] RFC7196 (4011) 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, 10 Jun 2014 15:58:43 -0000 The following errata report has been submitted for RFC7196, "Making Route Flap Damping Usable". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7196&eid=4011 -------------------------------------- Type: Technical Reported by: Benoit Claise Section: Section Original Text ------------- Default RFD Paramaters of Juniper and Cisco Corrected Text -------------- The default RFD parameters for Cisco and Juniper provided for the information of the reader. Notes ----- The RFC editor note (resulting from Barry and Benoit's DISCUSS) documented at https://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/edit/ballotwriteupnotes/ has been forgotten. Instructions: ------------- This errata 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. -------------------------------------- RFC7196 (draft-ietf-idr-rfd-usable-04) -------------------------------------- Title : Making Route Flap Damping Usable Publication Date : May 2014 Author(s) : C. Pelsser, R. Bush, K. Patel, P. Mohapatra, O. Maennel Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed Jun 11 06:39:29 2014 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 E007F1A0240; Tue, 10 Jun 2014 10:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjjm_wiEhSS8; Tue, 10 Jun 2014 10:48:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id A73E01A0180; Tue, 10 Jun 2014 10:48:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 27D4F18000E; Tue, 10 Jun 2014 10:47:37 -0700 (PDT) To: bclaise@cisco.com, cristel@iij.ad.jp, randy@psg.com, keyupate@cisco.com, mpradosh@yahoo.com, o@maennel.net X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140610174737.27D4F18000E@rfc-editor.org> Date: Tue, 10 Jun 2014 10:47:37 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/mUz9BSGkUeL4-ih0Ep2umo0b5FI X-Mailman-Approved-At: Wed, 11 Jun 2014 06:39:25 -0700 Cc: idr@ietf.org, akatlas@juniper.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Errata Verified] RFC7196 (4011) 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, 10 Jun 2014 17:48:29 -0000 The following errata report has been verified for RFC7196, "Making Route Flap Damping Usable". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7196&eid=4011 -------------------------------------- Status: Verified Type: Technical Reported by: Benoit Claise Date Reported: 2014-06-10 Verified by: Alia Atlas (IESG) Section: Section Original Text ------------- Default RFD Paramaters of Juniper and Cisco Corrected Text -------------- The default RFD parameters for Cisco and Juniper provided for the information of the reader. Notes ----- The RFC editor note (resulting from Barry and Benoit's DISCUSS) documented at https://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/edit/ballotwriteupnotes/ has been forgotten. -------------------------------------- RFC7196 (draft-ietf-idr-rfd-usable-04) -------------------------------------- Title : Making Route Flap Damping Usable Publication Date : May 2014 Author(s) : C. Pelsser, R. Bush, K. Patel, P. Mohapatra, O. Maennel Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed Jun 11 06:39:30 2014 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 029CE1A020F; Tue, 10 Jun 2014 11:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hm9ShzhNUdg; Tue, 10 Jun 2014 11:09:14 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0087D1A0177; Tue, 10 Jun 2014 11:09:13 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 19so2574315ykq.27 for ; Tue, 10 Jun 2014 11:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0VuaygoDZheDj4od0kw5WX3piHrRQ+A2QV13DOeTzmI=; b=tEX3cqM4Tf98lQF6Vx6w9TzsuY0yt8rF3GjUNuxwQcy3e6xe5Jf+gHtT1GIZUtmFum EZutQ5waqdy95ja7SoSt3ppcYcm9dFQ7h4lz4tmfbTyJ4rdKyBY8g3BGqj8rRdlf6VIC +dnjD4W8zwV10wvkAKlR62x5tGaspdoT7vTmmwVYZSVMZf5WlAA6wVHst75aD7lg8jFF 1IFPVsyIKhk4jGPus7y+UD0LVlIqJSoc3pkvjXJNFNzBfdvX542IcvVGaCIQQyZeGYoj oz5IZth7OZjN5v2mc0m2TemSP/nGDm7EBqmldFY/Ju3MRMzcjhMmua1mobCqEzDB67d1 HDcQ== MIME-Version: 1.0 X-Received: by 10.236.54.166 with SMTP id i26mr5352871yhc.109.1402423753151; Tue, 10 Jun 2014 11:09:13 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Tue, 10 Jun 2014 11:09:13 -0700 (PDT) In-Reply-To: References: <20140610174737.27D4F18000E@rfc-editor.org> Date: Tue, 10 Jun 2014 14:09:13 -0400 Message-ID: From: Alia Atlas To: Randy Bush Content-Type: multipart/alternative; boundary=bcaec50b5112a19c7504fb7f39cb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/FqBzVN0iystDnIKGGtluGpSKAUQ X-Mailman-Approved-At: Wed, 11 Jun 2014 06:39:25 -0700 Cc: "idr@ietf. org" , "Keyur Patel \(keyupate\)" , Benoit Claise , "iesg@ietf.org" , "akatlas@juniper.net" , o@maennel.net, RFC Errata System Subject: Re: [Idr] [Errata Verified] RFC7196 (4011) 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, 10 Jun 2014 18:09:20 -0000 --bcaec50b5112a19c7504fb7f39cb Content-Type: text/plain; charset=UTF-8 This is correcting an honest mistake made in processing - not cya. Alia On Tue, Jun 10, 2014 at 1:51 PM, Randy Bush wrote: > > The following errata report has been verified for RFC7196, > > "Making Route Flap Damping Usable". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=7196&eid=4011 > > > > -------------------------------------- > > Status: Verified > > Type: Technical > > > > Reported by: Benoit Claise > > Date Reported: 2014-06-10 > > Verified by: Alia Atlas (IESG) > > > > Section: Section > > > > Original Text > > ------------- > > Default RFD Paramaters of Juniper and Cisco > > > > > > > > Corrected Text > > -------------- > > The default RFD parameters for Cisco and Juniper > > provided for the information of the reader. > > > > > > Notes > > ----- > > The RFC editor note (resulting from Barry and Benoit's DISCUSS) > documented at > https://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/edit/ballotwriteupnotes/ > has been forgotten. > > > > -------------------------------------- > > RFC7196 (draft-ietf-idr-rfd-usable-04) > > -------------------------------------- > > Title : Making Route Flap Damping Usable > > Publication Date : May 2014 > > Author(s) : C. Pelsser, R. Bush, K. Patel, P. Mohapatra, O. > Maennel > > Category : PROPOSED STANDARD > > Source : Inter-Domain Routing > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > is there a way to credit vendors for cya? :) > --bcaec50b5112a19c7504fb7f39cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is correcting an honest mistake made in processing - = not cya.

Alia


On Tue, Jun 10, 2014 at 1:51 PM, Randy Bush <randy@psg.= com> wrote:
>= The following errata report has been verified for RFC7196,
> "Making Route Flap Damping Usable".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?r= fc=3D7196&eid=3D4011
>
> --------------------------------------
> Status: Verified
> Type: Technical
>
> Reported by: Benoit Claise <bc= laise@cisco.com>
> Date Reported: 2014-06-10
> Verified by: Alia Atlas (IESG)
>
> Section: Section
>
> Original Text
> -------------
> =C2=A0 =C2=A0 Default RFD Paramaters of Juniper and Cisco
>
>
>
> Corrected Text
> --------------
> =C2=A0 =C2=A0 The default RFD parameters for Cisco and Juniper
> =C2=A0 =C2=A0 provided for the information of the reader.
>
>
> Notes
> -----
> The RFC editor note (resulting from Barry and Benoit's DISCUSS) do= cumented at https://datatracker.ietf= .org/doc/draft-ietf-idr-rfd-usable/edit/ballotwriteupnotes/ has been fo= rgotten.
>
> --------------------------------------
> RFC7196 (draft-ietf-idr-rfd-usable-04)
> --------------------------------------
> Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Making Route = Flap Damping Usable
> Publication Date =C2=A0 =C2=A0: May 2014
> Author(s) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : C. Pelsser, R. Bush, K.= Patel, P. Mohapatra, O. Maennel
> Category =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: PROPOSED STANDARD<= br> > Source =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Inter-Domain = Routing
> Area =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Routing<= br> > Stream =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IETF
> Verifying Party =C2=A0 =C2=A0 : IESG

is there a way to credit vendors for cya? =C2=A0:)
--bcaec50b5112a19c7504fb7f39cb-- From nobody Wed Jun 11 06:39:32 2014 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 E29DE1A020F; Tue, 10 Jun 2014 11:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 ahXW8wJhSu9d; Tue, 10 Jun 2014 11:10:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F029C1A0177; Tue, 10 Jun 2014 11:10:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WuQUs-0002vy-1Q; Tue, 10 Jun 2014 18:10:10 +0000 Date: Tue, 10 Jun 2014 11:10:09 -0700 Message-ID: From: Randy Bush To: Alia Atlas In-Reply-To: References: <20140610174737.27D4F18000E@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: http://mailarchive.ietf.org/arch/msg/idr/4pjSOGRnIZYWjLWgE3hLa_yhc64 X-Mailman-Approved-At: Wed, 11 Jun 2014 06:39:25 -0700 Cc: "idr@ietf. org" , "Keyur Patel \(keyupate\)" , Benoit Claise , "iesg@ietf.org" , "akatlas@juniper.net" , o@maennel.net, RFC Errata System Subject: Re: [Idr] [Errata Verified] RFC7196 (4011) 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, 10 Jun 2014 18:10:21 -0000 > This is correcting an honest mistake made in processing - not cya. >> is there a way to credit vendors for cya? :) see smiley? randy From nobody Wed Jun 11 13:25:39 2014 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 21D961A0279; Wed, 11 Jun 2014 13:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCjuyW0boiaa; Wed, 11 Jun 2014 13:25:33 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB201A0081; Wed, 11 Jun 2014 13:25:32 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id r2so4932617igi.0 for ; Wed, 11 Jun 2014 13:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+LCnqSXW56Outvtlmf2l9lDkeBxm+EVOlqQKbIHKS7Q=; b=qp0hI5UupEJOSOB+txAyx/ggIRXBTrLvELnsUnicvW2nXFCDfLkrDehNThFMA9FrHF olX22OSZ+14MJWuJ8GnWlDXvrCNd6RR4BBbtDgfTtEyJfKxdMZ1U/j+6TiIo3oN+XH7o 59Lxp4sDuzDz7qw3N+XOK+VrUd5/TLVTRU+MtsoRofbAouye6dj4a3UI9anQ7Sqv8ItH ttfyqxgHt64pUttsCGMNx2IFVU7CS84/T0p9O6kjtCcvwPZsuneno0uvvHdsOOClsSZI fWwPZFKAhJLT9qE45zKQjBdAeXtj/0UiuAciM7Yp35ixeM2lwVDvJyfUS0efM4ypRr+1 in1A== MIME-Version: 1.0 X-Received: by 10.50.62.40 with SMTP id v8mr232505igr.21.1402518332203; Wed, 11 Jun 2014 13:25:32 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 11 Jun 2014 13:25:31 -0700 (PDT) In-Reply-To: <8DE674B8-45B5-4102-B974-B9312106E2A8@parsons.com> References: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> <8DE674B8-45B5-4102-B974-B9312106E2A8@parsons.com> Date: Wed, 11 Jun 2014 22:25:31 +0200 X-Google-Sender-Auth: 7JkRniBXSIPdimBrkb0VY15vWBo Message-ID: From: Robert Raszuk To: Sandra Murphy , Bruno Decraene Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/TNFQj7qZMKS1aG2YICNu9pZrsEI Cc: idr wg , "sidr@ietf.org list" Subject: Re: [Idr] [sidr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 11 Jun 2014 20:25:34 -0000 Hi Bruno & all, Just focusing on Q1: > 1) For people not following SIDR, could you please elaborate > on why http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 > has not been used? (via the registration of a new Point of > Insertion specific to origin validation) (as I though draft-ietf-idr- > custom-decision was intended to be the last time BGP decision > process would be modified) Few observations: A. draft-ietf-sidr-origin-validation-signaling does not really modify a BGP best path selection .. it adds a check before BGP best path selection algorithm kicks in. B. Adding new POI is not needed as we already have a POI = 128 which is to be executed before any step in BGP best path selection hence at exactly the same point as this draft recommends. therefor one obvious question comes in: C. Based on A & B there is clear conflict not addresses in the draft. Assume both custom decision with POI = 128 "ABSOLUTE_VALUE" as well as origin validation are enabled. Moreover assume they result in opposite decisions. So the question of the day is: "Which of those two is the one to win the pre best path check ?" Effectively - which of those two is more important ? The answer to this question should be included in the draft. And I do suspect authors of both drafts will answer: mine ! Thx, R. From nobody Wed Jun 11 16:07:08 2014 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 4B1211B28CC for ; Wed, 11 Jun 2014 16:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 V-FOT7YWVeE7 for ; Wed, 11 Jun 2014 16:07:02 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BEC1B28CB for ; Wed, 11 Jun 2014 16:07:02 -0700 (PDT) Received: from [172.29.6.121] (66.129.239.13) by DM2PR05MB736.namprd05.prod.outlook.com (10.141.178.25) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 11 Jun 2014 23:07:00 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John G.Scudder In-Reply-To: <53889E84.7040305@benocs.com> Date: Wed, 11 Jun 2014 19:06:53 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140529234924.20688.23855.idtracker@ietfa.amsl.com> <53889E84.7040305@benocs.com> To: X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.239.13] X-ClientProxiedBy: CO2PR05CA041.namprd05.prod.outlook.com (10.141.241.169) To DM2PR05MB736.namprd05.prod.outlook.com (10.141.178.25) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0239D46DB6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6049001)(6009001)(428001)(199002)(24454002)(189002)(51704005)(164054003)(69224002)(377424004)(377454003)(87286001)(15975445006)(83072002)(104166001)(62966002)(99396002)(77982001)(66066001)(74502001)(85852003)(74662001)(21056001)(47776003)(87976001)(64706001)(83716003)(50986999)(20776003)(92726001)(4396001)(77156001)(89996001)(50466002)(36756003)(79102001)(88136002)(50226001)(33656002)(82746002)(46102001)(76176999)(83322001)(80022001)(81542001)(92566001)(15202345003)(31966008)(42186004)(76482001)(57306001)(102836001)(19580395003)(101416001)(93916002)(81342001)(19580405001)(23746002)(86362001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB736; H:[172.29.6.121]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/OH0ZUjnGdnUMN-69HeI-NFBPaUU Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 23:07:06 -0000 On May 30, 2014, at 11:06 AM, Deniz Bahadir wrote: > Hi guys, >=20 > I have some more (minor) comments (or one might call it nit-picking) = concerning the current draft: >=20 > 1. > It occurs to me that the title of section 7 ("Error Handling = Procedures for Existing Attributes") implies to address *all* existing = attributes. The first sentence, however, seems to mitigate that by = saying the following subsections "elaborate on the conditions for = error-checking *various* path attributes". > Nevertheless, for sake of completeness, I would recommend to mention = all (non-deprecated) path attributes (as can be found here: = http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml) in = the following subsections. Covered in an earlier message. > 2. > To be honest, I do not know all these path-attributes myself. However, = I know AS4_PATH and AS4_AGGREGATOR, and would at least recommend to add = them to the subsections of section 7. Especially, as the information = given in the subsections for AS_PATH and AS_AGGREGATOR pretty much = resembles the information for AS4_PATH and AS4_AGGREGATOR in section 6 = of RFC 6793 (except maybe for the action taken). I covered this in my reply to #1 =97 IMO RFC 6793 is sufficient.=20 > 3. > I would also recommend to repeat (and explain) the definition of = "syntactical incorrectness" for NEXT_HOP in subsection 7.3. (This seems = to be the only subsection which just refers to another RFC and does not = repeat the important part.) >=20 > Some more nit-picking: >=20 > 4. > Likewise, I was always wondering, what exactly is meant by saying, = "Syntactic correctness means that the NEXT_HOP attribute represents a = valid IP host address." [RFC 4271, page 32]? > * Does it mean, the NEXT_HOP value must be a machine that should be up = and running as well as reachable (and one must explicitly check for = that)? -- Probably not. > * Does it mean, the NEXT_HOP must be a unicast address (neither = 0.0.0.0 nor greater than 223.255.255.255)? -- Maybe. > * Does it mean, the NEXT_HOP value must be a unicast address but not = 127.0.0.1 or some other special IP? -- Possibly. > * =85 >=20 > 5. > Similar, I briefly looked through RFC 4760 but could not find a = section telling me, if and when the value of the Next Hop field of = MP_REACH_NLRI is considered (syntactically) incorrect. (At least for = AFI/SAFI of IPv4/Unicast I would have expected it.) > Is suppose, the current draft should address this question. > (Or it shouls at least mention that MP_REACH_NLRI's Next Hop value = need not be checked for (syntactical) correctness... although this does = not sound right.) See -12 for an attempt at addressing the three foregoing points.=20 > 6. > I appreciate the ambiguity about attribute flags being addressed. Just = one question: Shouldn't a well-known attribute also be considered to = have conflicting flags if the partial bit is set? Covered in an earlier message. =97John >=20 >=20 > Thanks, > Deniz >=20 >=20 > Am 30.05.2014 15:03, schrieb John G. Scudder: >> As reading the rfcdiff will tell you :-) this version: >>=20 >> - Calls out AFI/SAFI disable distinctly. >> - Corrects the ambiguity about attribute flags that conflict. >> - Removes some redundancy in 3(j). >> - Reworks the =93Parsing of NLRI=94 section quite a bit, including: >> - Extract the attribute length stuff to its own section, it didn=92t = make sense where it was. >> - Puts back the =93MP_ must go first=94 rule. >> - Adds a subsection on =93Missing NLRI=94. >>=20 >> Thanks for all the discussion. >>=20 >> Regards, >>=20 >> =97John >>=20 >> On May 29, 2014, at 7:49 PM, = wrote: >>=20 >>>=20 >>> 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. >>>=20 >>> Title : Revised Error Handling for BGP UPDATE = Messages >>> Authors : Enke Chen >>> John G. Scudder >>> Pradosh Mohapatra >>> Keyur Patel >>> Filename : draft-ietf-idr-error-handling-10.txt >>> Pages : 15 >>> Date : 2014-05-29 >>>=20 >>> Abstract: >>> According to the base BGP specification, a BGP speaker that = receives >>> an UPDATE message containing a malformed attribute is required to >>> reset the session over which the offending attribute was received. >>> This behavior is undesirable as a session reset would impact not = only >>> routes with the offending attribute, but also other valid routes >>> exchanged over the session. This document partially revises the >>> error handling for UPDATE messages, and provides guidelines for = the >>> authors of documents defining new attributes. Finally, it revises >>> the error handling procedures for a number of existing attributes. >>>=20 >>> This document updates error handling for RFCs 1997, 4271, 4360, = 4456, >>> 4760 and 5701. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-idr-error-handling-10 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-10 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >>=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jun 11 16:07:16 2014 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 2E49E1B28CC; Wed, 11 Jun 2014 16:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnFxwLXSTe6n; Wed, 11 Jun 2014 16:07:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DABDB1B28CE; Wed, 11 Jun 2014 16:07:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611230707.9414.75243.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 16:07:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/J1rNIArwipaiiqX-NiWzJq3ecsU Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 23:07:10 -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 : Revised Error Handling for BGP UPDATE Messages Authors : Enke Chen John G. Scudder Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-12.txt Pages : 18 Date : 2014-06-11 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760 and 5701. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 11 16:15:01 2014 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 70ED21B28B5 for ; Wed, 11 Jun 2014 16:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XdhJ6ETKt30v for ; Wed, 11 Jun 2014 16:14:58 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C161B28D2 for ; Wed, 11 Jun 2014 16:14:58 -0700 (PDT) Received: from [172.29.6.121] (66.129.239.13) by DM2PR05MB736.namprd05.prod.outlook.com (10.141.178.25) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 11 Jun 2014 23:14:55 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <20140611230707.9414.75243.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 19:14:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <94367EEF-5673-4FAC-B85A-D799A46763F0@juniper.net> References: <20140611230707.9414.75243.idtracker@ietfa.amsl.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.239.13] X-ClientProxiedBy: BY2PR06CA046.namprd06.prod.outlook.com (10.141.250.164) To DM2PR05MB736.namprd05.prod.outlook.com (10.141.178.25) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0239D46DB6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6049001)(6009001)(428001)(199002)(24454002)(189002)(51704005)(164054003)(377424004)(377454003)(87286001)(15975445006)(83072002)(104166001)(62966002)(99396002)(77982001)(66066001)(74502001)(85852003)(74662001)(21056001)(47776003)(87976001)(64706001)(83716003)(50986999)(20776003)(92726001)(4396001)(77156001)(89996001)(50466002)(36756003)(79102001)(88136002)(50226001)(33656002)(82746002)(46102001)(76176999)(83322001)(80022001)(81542001)(92566001)(15202345003)(31966008)(42186004)(76482001)(57306001)(102836001)(19580395003)(101416001)(93916002)(81342001)(19580405001)(23746002)(86362001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB736; H:[172.29.6.121]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/yKiqqgYn0v0XuNzj9j3FA6c-fAQ Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 23:15:00 -0000 Folks, Changes for -12: - Expanded NEXT_HOP and MP_REACH_NLRI to talk about what it means to be = a =93valid IP host address=94 - Disclaimed a lot of attributes that are either OK or deprecated - Added subsections for TE attribute, Entropy Label, ATTR_SET=20 - Rearranged Section 7 to be in type code order (sorry for the extra = diff) Still to do: - Traffic Engineering path attribute is stubbed out. I=92ve pinged the = authors of RFC 5543 to ask if they=92d be willing to contribute text. Given that there=92s a =93TBD=94 section, -12 is obviously not ready for = publication, however I hope it addresses all comments other than the = TBD. Thanks, =97John On Jun 11, 2014, at 7:07 PM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Revised Error Handling for BGP UPDATE = Messages > Authors : Enke Chen > John G. Scudder > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-12.txt > Pages : 18 > Date : 2014-06-11 >=20 > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not = only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for a number of existing attributes. >=20 > This document updates error handling for RFCs 1997, 4271, 4360, = 4456, > 4760 and 5701. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-12 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-12 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 12 00:45:48 2014 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 D5AED1A02AF; Thu, 12 Jun 2014 00:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJV5QTmpcU62; Thu, 12 Jun 2014 00:45:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804CA1A02DF; Thu, 12 Jun 2014 00:45:41 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id B5CCC3B4572; Thu, 12 Jun 2014 09:45:39 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 984CA35C04E; Thu, 12 Jun 2014 09:45:39 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 09:45:39 +0200 From: To: Robert Raszuk , Sandra Murphy Thread-Topic: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPhbNM1WOEZypNVEOpxmOi+68BQ5ttFKhw Date: Thu, 12 Jun 2014 07:45:38 +0000 Message-ID: <3364_1402559139_53995AA3_3364_2738_1_53C29892C857584299CBF5D05346208A07162318@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> <8DE674B8-45B5-4102-B974-B9312106E2A8@parsons.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.12.55119 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/T4jSU0azjfarFFJ7_5rrQDJOXuo Cc: idr wg , "sidr@ietf.org list" Subject: Re: [Idr] [sidr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 12 Jun 2014 07:45:44 -0000 SGkgUm9iZXJ0LCBhbGwNCg0KPiBGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6 dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0ICBSYXN6dWsgPiBTZW50OiBXZWRuZXNk YXksIEp1bmUgMTEsIDIwMTQgMTA6MjYgUE0NCj4gDQo+IEhpIEJydW5vICYgYWxsLA0KPiANCj4g SnVzdCBmb2N1c2luZyBvbiBRMToNCj4gDQo+ID4gMSkgIEZvciBwZW9wbGUgbm90IGZvbGxvd2lu ZyBTSURSLCBjb3VsZCB5b3UgcGxlYXNlIGVsYWJvcmF0ZSBvbiB3aHkNCj4gPiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1jdXN0b20tZGVjaXNpb24tMDQNCj4gPiBo YXMgbm90IGJlZW4gdXNlZD8gKHZpYSB0aGUgcmVnaXN0cmF0aW9uIG9mIGEgbmV3IFBvaW50IG9m IEluc2VydGlvbg0KPiA+IHNwZWNpZmljIHRvIG9yaWdpbiB2YWxpZGF0aW9uKSAoYXMgSSB0aG91 Z2ggZHJhZnQtaWV0Zi1pZHItDQo+ID4gY3VzdG9tLWRlY2lzaW9uIHdhcyBpbnRlbmRlZCB0byBi ZSB0aGUgbGFzdCB0aW1lIEJHUCBkZWNpc2lvbiBwcm9jZXNzDQo+ID4gd291bGQgYmUgbW9kaWZp ZWQpDQo+IA0KPiBGZXcgb2JzZXJ2YXRpb25zOg0KPiANCj4gQS4gZHJhZnQtaWV0Zi1zaWRyLW9y aWdpbi12YWxpZGF0aW9uLXNpZ25hbGluZyBkb2VzIG5vdCByZWFsbHkgbW9kaWZ5IGEgQkdQIGJl c3QNCj4gcGF0aCBzZWxlY3Rpb24gLi4gaXQgYWRkcyBhIGNoZWNrIGJlZm9yZSBCR1AgYmVzdCBw YXRoIHNlbGVjdGlvbiBhbGdvcml0aG0NCj4ga2lja3MgaW4uDQoNCg0KIjMuIENoYW5nZXMgdG8g dGhlIEJHUCBEZWNpc2lvbiBQcm9jZXNzIg0KWy4uLl0NCiJXaGVuIGNvbXBhcmluZyBhIHBhaXIg b2Ygcm91dGVzIGZvciBhIEJHUCBkZXN0aW5hdGlvbiwgdGhlIHJvdXRlIHdpdGggdGhlIGxvd2Vz dCAidmFsaWRhdGlvbiBzdGF0ZSIgdmFsdWUgaXMgcHJlZmVycmVkLiINCg0KTXkgcmVhZGluZyBp cyB0aGF0IGl0IGRvZXMgY2hhbmdlIHRoZSBCR1AgZGVjaXNpb24gcHJvY2VzcyBhbmQgdGhlIHJl bGF0aXZlIHByaW9yaXR5IG9mIHRoZSByb3V0ZXMuDQoNCj4gQi4gQWRkaW5nIG5ldyBQT0kgaXMg bm90IG5lZWRlZCBhcyB3ZSBhbHJlYWR5IGhhdmUgYSBQT0kgPSAxMjggd2hpY2ggaXMgdG8NCj4g YmUgZXhlY3V0ZWQgYmVmb3JlIGFueSBzdGVwIGluIEJHUCBiZXN0IHBhdGggc2VsZWN0aW9uIGhl bmNlIGF0IGV4YWN0bHkgdGhlDQo+IHNhbWUgcG9pbnQgYXMgdGhpcyBkcmFmdCByZWNvbW1lbmRz Lg0KDQpVc2luZyBQT0k9MTI4IGlzIGluZGVlZCBhbiBvcHRpb24uIEhvd2V2ZXIgaW4gdGhlb3J5 IHRoZXJlIGNvdWxkIGFscmVhZHkgYmUgZXhpc3RpbmcgdXNhZ2Ugb2YgUE9JPTEyOCwgaGVuY2Ug cG9zc2libGUgY29uZmxpY3QuIEluIHN1Y2ggY2FzZSwgdGhlIHN1Yi1maWVsZCAiQ29tbXVuaXR5 LUlEIiBkZWZpbmUgdGhlIHByaW9yaXR5LiBJdCdzIGEgcHJpb3JpIG5vdCBwb3NzaWJsZSB0byBk ZWZpbmUgd2hldGhlciBvcmlnaW4tdmFsaWRhdGlvbiBzaG91ZCBoYXZlIGEgbG93IG9yIGhpZ2gg dmFsdWUgY29tcGFyZWQgdG8gYW5vdGhlciBwb3NzaWJsZSBleGlzdGluZyB1c2FnZS4NCg0KIA0K PiB0aGVyZWZvciBvbmUgb2J2aW91cyBxdWVzdGlvbiBjb21lcyBpbjoNCj4gDQo+IEMuIEJhc2Vk IG9uIEEgJiBCIHRoZXJlIGlzIGNsZWFyIGNvbmZsaWN0IG5vdCBhZGRyZXNzZXMgaW4gdGhlIGRy YWZ0Lg0KPiBBc3N1bWUgYm90aCBjdXN0b20gZGVjaXNpb24gd2l0aCBQT0kgPSAxMjggIkFCU09M VVRFX1ZBTFVFIiBhcyB3ZWxsIGFzDQo+IG9yaWdpbiB2YWxpZGF0aW9uIGFyZSBlbmFibGVkLiBN b3Jlb3ZlciBhc3N1bWUgdGhleSByZXN1bHQgaW4gb3Bwb3NpdGUNCj4gZGVjaXNpb25zLiBTbyB0 aGUgcXVlc3Rpb24gb2YgdGhlIGRheSBpczogIldoaWNoIG9mIHRob3NlIHR3byBpcyB0aGUgb25l IHRvDQo+IHdpbiB0aGUgcHJlIGJlc3QgcGF0aCBjaGVjayA/IiBFZmZlY3RpdmVseSAtIHdoaWNo IG9mIHRob3NlIHR3byBpcyBtb3JlDQo+IGltcG9ydGFudCA/DQoNCllvdSBhcmUgcmVhZGluZyBt eSBtaW5kIDotKS4NCkkgYXNzdW1lZCB0aGF0IHRoZSBmaXJzdCBkb2N1bWVudCBiZWNvbWluZyBS RkMgZnJlZWx5IGRlZmluZSBpdHMgYmVoYXZpb3IgYW5kIHRoZW4gdGhlIHNlY29uZCB3aWxsIG5l ZWQgdG8gYWRhcHQgKGkuZS4gcG9zaXRpb24gaXRzZWxmIHdpdGggcmVnYXJkIHRvIHRoZSBmaXJz dCBvbmUpLiBIb3dldmVyLCBnaXZlbiB0aGF0IGJvdGggZG9jdW1lbnRzIGFyZSB3b3JrZWQgaW4g ZGlmZmVyZW50IFdHLCB0aGVyZSBpcyBhIHJpc2sgdGhhdCB0aGlzIGlzIG1pc3NlZC4NCiANCj4g VGhlIGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgZHJh ZnQuIEFuZCBJIGRvIHN1c3BlY3QNCj4gYXV0aG9ycyBvZiBib3RoIGRyYWZ0cyB3aWxsIGFuc3dl cjogbWluZSAhDQoNCjotKQ0KSW5kZWVkIGl0J3MgdXAgdG8gdGhlIGF1dGhvcnMvV0csIGJ1dCB0 byBtZSAiQWJzb2x1dGUiIHNlZW1zIGFib3ZlIGFueSBvdGhlciBjcml0ZXJpYS4NCg0KVGhhbmtz LA0KQnJ1bm8NCg0KPiBUaHgsDQo+IFIuDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Thu Jun 12 01:06:21 2014 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 8A7E41A0641; Thu, 12 Jun 2014 01:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g45JNtVPTh0k; Thu, 12 Jun 2014 01:06:16 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BEA81A02B3; Thu, 12 Jun 2014 01:06:15 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so1737517igd.8 for ; Thu, 12 Jun 2014 01:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Rm2zSQvEUQjLx+RDE2e8pEM1irmMiyDXTzryhc9Pfug=; b=gj5Vtq7PJIRXEa4qQCf+L5sZ1/+JmvyujvR8H7RegBYINWNdiilGC23MiWjnf4QdK8 NPitx/MytY6+73YBGdovLVL8Jiv5ksAFBItQVR4mKfdnLaA0Dd8Ko0aB3s38EUVuPK5j YYYRt7+OQYULrQ6o12VxuWxXzYjnqmfABPcYpWv242lZ5S9f5HmoTMWyFavpGW2GloTC o5iJqIcIa4BJYoyhEIHQ+WsiX9/gEo++2wX7sdjav+nn2MW0DuWB2nOXsPl5smCzTRfP htgLMsvmAnGJXWY1rPholLMDkPyn+sUkm2m+M031Q5jxElfKPMrDrgnV1yAZfOT4r5WH bAQQ== MIME-Version: 1.0 X-Received: by 10.43.87.200 with SMTP id ax8mr8190171icc.97.1402560375267; Thu, 12 Jun 2014 01:06:15 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Thu, 12 Jun 2014 01:06:14 -0700 (PDT) In-Reply-To: <3364_1402559139_53995AA3_3364_2738_1_53C29892C857584299CBF5D05346208A07162318@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <002a01cf84b8$b0f55230$12dff690$@ndzh.com> <11159_1402415346_539728F2_11159_3728_16_53C29892C857584299CBF5D05346208A07161787@PEXCVZYM11.corporate.adroot.infra.ftgroup> <8DE674B8-45B5-4102-B974-B9312106E2A8@parsons.com> <3364_1402559139_53995AA3_3364_2738_1_53C29892C857584299CBF5D05346208A07162318@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Thu, 12 Jun 2014 10:06:14 +0200 X-Google-Sender-Auth: TaRGTt9HcJdoOlVux6_r5Y5bNRw Message-ID: From: Robert Raszuk To: Bruno Decraene Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jpMejOXKmMMuE8hdbsdQjC6vfeU Cc: idr wg , "sidr@ietf.org list" Subject: Re: [Idr] [sidr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 12 Jun 2014 08:06:17 -0000 Hi Bruno, Glad we are in sync ;-) > It's a priori not possible to define whether origin-validation shoud have > a low or high value compared to another possible existing usage. Well I do not think it can be left as such. The entire point of adding the new extended community for propagation of origin validation result (valid, nf, invalid) is to accomplish consistency in IBGP. If you leave it open (ie not specified a priori) there is risk of different selections of best path in your domain for a given net (possibly with different exit points) . Frankly since this ext community is non transitive one could also depref the routes via local pref .. yes yes I can hear already voices .. don't touch it - my local pref is for customers ! Except what this draft defines will easily ignore all those customer local preferences anyway ... IMO it is all about wisely choosing local pref values. Cheers, R. > On Thu, Jun 12, 2014 at 9:45 AM, wrote: > > Hi Robert, all > >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk > Sent: Wednesday, June 11, 2014 10:26 PM >> >> Hi Bruno & all, >> >> Just focusing on Q1: >> >> > 1) For people not following SIDR, could you please elaborate on why >> > http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 >> > has not been used? (via the registration of a new Point of Insertion >> > specific to origin validation) (as I though draft-ietf-idr- >> > custom-decision was intended to be the last time BGP decision process >> > would be modified) >> >> Few observations: >> >> A. draft-ietf-sidr-origin-validation-signaling does not really modify a = BGP best >> path selection .. it adds a check before BGP best path selection algorit= hm >> kicks in. > > > "3. Changes to the BGP Decision Process" > [...] > "When comparing a pair of routes for a BGP destination, the route with th= e lowest "validation state" value is preferred." > > My reading is that it does change the BGP decision process and the relati= ve priority of the routes. > >> B. Adding new POI is not needed as we already have a POI =3D 128 which i= s to >> be executed before any step in BGP best path selection hence at exactly = the >> same point as this draft recommends. > > Using POI=3D128 is indeed an option. However in theory there could alread= y be existing usage of POI=3D128, hence possible conflict. In such case, th= e sub-field "Community-ID" define the priority. It's a priori not possible = to define whether origin-validation shoud have a low or high value compared= to another possible existing usage. > > >> therefor one obvious question comes in: >> >> C. Based on A & B there is clear conflict not addresses in the draft. >> Assume both custom decision with POI =3D 128 "ABSOLUTE_VALUE" as well as >> origin validation are enabled. Moreover assume they result in opposite >> decisions. So the question of the day is: "Which of those two is the one= to >> win the pre best path check ?" Effectively - which of those two is more >> important ? > > You are reading my mind :-). > I assumed that the first document becoming RFC freely define its behavior= and then the second will need to adapt (i.e. position itself with regard t= o the first one). However, given that both documents are worked in differen= t WG, there is a risk that this is missed. > >> The answer to this question should be included in the draft. And I do su= spect >> authors of both drafts will answer: mine ! > > :-) > Indeed it's up to the authors/WG, but to me "Absolute" seems above any ot= her criteria. > > Thanks, > Bruno > >> Thx, >> R. > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Jun 12 01:50:31 2014 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 147901A039B; Thu, 12 Jun 2014 01:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL2Y_hQ6L2Oa; Thu, 12 Jun 2014 01:50:24 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0601A0415; Thu, 12 Jun 2014 01:50:23 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-12.txt Thread-Index: AQHPhcnvoMzt/74/c0GfWX0ZHNp4NJttIQJw Date: Thu, 12 Jun 2014 08:50:17 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011F0F90@EX01.swan.local> References: <20140611230707.9414.75243.idtracker@ietfa.amsl.com> In-Reply-To: <20140611230707.9414.75243.idtracker@ietfa.amsl.com> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.40.93] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/3lMQUXQNCl4n6x7Zx8RGo-O_aTo Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:50:27 -0000 Hello Just a nit picking. > 7.3. NEXT_HOP > An implementation MAY provide a means to modify > the list of invalid host addresses by configuration I believe SHOULD would be more appropriate here (and in 7.11. MP_REACH_NLRI= as well).=20 If an implementer decides not to implement this knob and assumes all addres= ses in the "IANA IPv4 Special-Purpose Address Registry" are false then the = implementation will be unusable (actually only a small portion of the list = is flat out unusable for next hop).=20 Besides every decent implementation should allow on operator to choose what= is considered as valid next hop.=20 adam From nobody Thu Jun 12 06:42:24 2014 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 3C0E41B2A30; Thu, 12 Jun 2014 06:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 u0N0hNZLQcjE; Thu, 12 Jun 2014 06:42:18 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1CA31B2A2A; Thu, 12 Jun 2014 06:42:17 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5CDgDuC012423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 08:42:14 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5CDg9ap028150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 15:42:12 +0200 Received: from [172.27.221.50] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 12 Jun 2014 15:42:09 +0200 Message-ID: <5399AE30.3020703@alcatel-lucent.com> Date: Thu, 12 Jun 2014 15:42:08 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: , , Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.40] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jcJtVHnehBuJooWGxqoAri80SJo Cc: l3vpn-chairs@tools.ietf.org, mpls-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org Subject: [Idr] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:42:19 -0000 Working Groups, This is to start a 2-week Working Group Last Call in three Working Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. The draft has been made a WG Document by WG Chairs decision. In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs), an optional transitive BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is specified. This BGP attribute uses an octet field to specify the PMSI tunnel type. RFC 6514 allocates the values 0-7. There now is need to make further code point allocations from this name space. In particular, draft-ietf-mpls-seamless-mcast needs to make such an allocation. That draft is currently in WG Last Call in the MPLS Working Group. draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for these code points. The registry is created in the "Border Gateway Protocol (BGP) Parameters" registry. Please send comments to the l3vpn mailing list (l3vpn@ietf.org). The WG LC will end on Friday the 27th of June. Martin, on behalf of the WGs co-chairs From nobody Thu Jun 12 07:55:00 2014 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 809151B2A46; Thu, 12 Jun 2014 07:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 WSvt83IYVzwN; Thu, 12 Jun 2014 07:54:54 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8056C1B2A76; Thu, 12 Jun 2014 07:54:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.9.96; From: "Susan Hares" To: "'Martin Vigoureux'" , , , References: <5399AE30.3020703@alcatel-lucent.com> In-Reply-To: <5399AE30.3020703@alcatel-lucent.com> Date: Thu, 12 Jun 2014 10:54:47 -0400 Message-ID: <009b01cf864e$41ddcde0$c59969a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIS5sn81JJr+QPqDf2XZ37ngvLYSJrmzmAQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/l9rHKl8gZhisFAYYnmGLEFjyeUk Cc: l3vpn-chairs@tools.ietf.org, mpls-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:54:55 -0000 Support publication. It tells IANA what to do appropriately. Idr chair + L3VPN participant. -----Original Message----- From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] Sent: Thursday, June 12, 2014 9:42 AM To: l3vpn@ietf.org; mpls@ietf.org; idr@ietf.org Cc: rtg-ads@tools.ietf.org; l3vpn-chairs@tools.ietf.org; mpls-chairs@tools.ietf.org; idr-chairs@tools.ietf.org Subject: WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 Working Groups, This is to start a 2-week Working Group Last Call in three Working Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. The draft has been made a WG Document by WG Chairs decision. In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs), an optional transitive BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is specified. This BGP attribute uses an octet field to specify the PMSI tunnel type. RFC 6514 allocates the values 0-7. There now is need to make further code point allocations from this name space. In particular, draft-ietf-mpls-seamless-mcast needs to make such an allocation. That draft is currently in WG Last Call in the MPLS Working Group. draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for these code points. The registry is created in the "Border Gateway Protocol (BGP) Parameters" registry. Please send comments to the l3vpn mailing list (l3vpn@ietf.org). The WG LC will end on Friday the 27th of June. Martin, on behalf of the WGs co-chairs From nobody Thu Jun 12 09:31:01 2014 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 873A61A01AA for ; Thu, 12 Jun 2014 09:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 GwrcnZga_7vo for ; Thu, 12 Jun 2014 09:30:54 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id A71E51A0150 for ; Thu, 12 Jun 2014 09:30:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id 97B6D642230; Thu, 12 Jun 2014 18:30:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHbaL86zpS+W; Thu, 12 Jun 2014 18:30:40 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id 8AE2164222F for ; Thu, 12 Jun 2014 18:30:40 +0200 (CEST) Message-ID: <5399D5AF.40702@benocs.com> Date: Thu, 12 Jun 2014 18:30:39 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: idr@ietf.org References: <20140611230707.9414.75243.idtracker@ietfa.amsl.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011F0F90@EX01.swan.local> In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011F0F90@EX01.swan.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/47Fl3XelOdz_d6Dxx4KqPS_v_-I Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:30:59 -0000 > Just a nit picking. And another bit of nit picking. The last sentence of the abstract should reference all RFCs which will be updated by this document and should therefore be changed to: "This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, 6368 and 6790." Deniz > >> 7.3. NEXT_HOP >> An implementation MAY provide a means to modify >> the list of invalid host addresses by configuration > > I believe SHOULD would be more appropriate here (and in 7.11. MP_REACH_NLRI as well). > If an implementer decides not to implement this knob and assumes all addresses in the "IANA IPv4 Special-Purpose Address Registry" are false then the implementation will be unusable (actually only a small portion of the list is flat out unusable for next hop). > Besides every decent implementation should allow on operator to choose what is considered as valid next hop. > > adam > From nobody Thu Jun 12 09:52:14 2014 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 5FC791A01BF for ; Thu, 12 Jun 2014 09:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 qmFUegP44dFg for ; Thu, 12 Jun 2014 09:52:05 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798A21A01AA for ; Thu, 12 Jun 2014 09:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25482; q=dns/txt; s=iport; t=1402591926; x=1403801526; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=CBkquTKI8hLo+i5iqKpXXNMiL8fPEPDWcOJHKzRn1xw=; b=ZHiEjbp+0hA6xTtJaZMt/B5J5H/oYYTIf4Y2IysctO8eAbJVMKlyeoJ/ 8ChOJAjSEw/SfPrpZ9gWhu04v0gs8muEMinFTsU0XxcK2lqZlSBQqCE+A SYuSuIPH1QME9XhvqgyU4kt4OD08M6h57OWYLaIpVJrX7eVpJP4luZcoe k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkGAEnamVOtJA2I/2dsb2JhbABagkZHUlmpTgEBAQEBB5AQgVIBhzsBgQoWdYQDAQEBBAEBARoQQQsSAQgRAwEBASEHLgsUCQgCBAENBRSILg3SKxeFXIVhgjwRASUHEwwBBAYBAgSEOwSaMoFDkg+BfIFAgW8HFwYc X-IronPort-AV: E=Sophos; i="5.01,466,1400025600"; d="scan'208,217"; a="52571282" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP; 12 Jun 2014 16:52:04 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5CGq4Se002127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 16:52:04 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.72]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 12 Jun 2014 11:52:03 -0500 From: "Keyur Patel (keyupate)" To: "bruno.decraene@orange.com" , Susan Hares , idr wg Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPhl6ioQM6V/KMVE6ciYitCsRUAA== Date: Thu, 12 Jun 2014 16:52:03 +0000 Message-ID: In-Reply-To: <29140_1402414807_539726D7_29140_10276_1_53C29892C857584299CBF5D05346208A0716175D@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.81.86] Content-Type: multipart/alternative; boundary="_000_CFBF295676128keyupateciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/j4yMDNmsE3GbgE9eeKXUsyHd-LY Cc: "'John G. Scudder'" Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 12 Jun 2014 16:52:08 -0000 --_000_CFBF295676128keyupateciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno, Thanks for the draft review. Comments inlined #Keyur From: > Date: Tue, 10 Jun 2014 15:40:05 +0000 To: Susan Hares >, idr wg > Cc: "'John G. Scudder'" >, "Murphy, Sandra" <= Sandra.Murphy@parsons.com> Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-s= ignaling-04 - RFC4271 changes Hi, Thanks for the cross WG review. Please find below some proposed comments. 1) For people not following SIDR, could you please elaborate on why ht= tp://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been use= d? (via the registration of a new Point of Insertion specific to origin val= idation) (as I though draft-ietf-idr-custom-decision was intended to be the= last time BGP decision process would be modified) #Keyur: The draft don't suggest modifications to the BGP best path algorith= m. Infact the next rev of the draft should fix and remove section 3 as well= . The extended community used in draft is use to signal BGP best path vali= dation state within an IBGP network. 2) Could the document specify the action to be taken when multiple =93= Origin validation state extended=94 community are present with different va= lidation state? And how are handled validation state value > 2. (from curre= nt text, it would not be considered an error, just lower priority. But I wo= uld prefer an explicit statement to avoid surprising error handling behavio= r) #Keyur: There SHOULD not be multiple such extended communities for a given = BGP path. We can add the necessary text. 3) Rfc 6811 is referenced twice in important sections. What about movi= ng it to =93normative reference=94? #Keyur: Sure. 4) Following discussion triggered by http://tools.ietf.org/html/draft-= decraene-idr-rfc4360-clarification-00 I understood that the IDR conclusion = was that a non-transitive community may be attached on the outbound policy = of an eBGP session; hence may received over an eBGP session. Given this, IM= O the security consideration needs more text. (assuming that the ability fo= r a neighboring AS to influence/force the origin validation state is consid= ered acceptable, which would probably need to be discussed in SIDR) #Keyur: Ideally, the usage of this community should NOT be encouraged acro= ss inter-as boundaries. We can add necessary text to reflect that part. Regards, Keyur Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, June 10, 2014 4:32 PM To: idr wg Cc: Murphy, Sandra; 'John G. Scudder' Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signa= ling-04 - RFC4271 changes IDR: The SIDR WG has asked for cross review of the draft-ietf-sidr-origin-valida= tion-signaling-04. This draft changes the RFC 4271 decision process in the= following manner: If a BGP router supports prefix origin validation and is configured for the= extensions defined in this document, the validation step SHOULD be perform= ed prior to any of the steps defined in the decision process of [RFC4271]. The validation step is stated as follo= ws: When comparing a pair of routes for a BGP destination, the route with the lowest "validation state" value is preferred. In all other respects, the decision process remains unchanged. The draft is at: http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 John and I would like to hear your comments regarding the RFC 4271 revision= . Please send comments that include =93support=94 or =93no support=94. Sue and John ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.o= rg https://www.ietf.org/mailman/listinfo/idr --_000_CFBF295676128keyupateciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Bruno,

Thanks for the draft review. Comments inlined #Keyur

From: <bruno.decraene@orange.com>
Date: Tue, 10 Jun 2014 15:40:05 = 3;0000
To: Susan Hares <shares@ndzh.com>, idr wg <idr@ietf.org>
Cc: "'John G. Scudder'" &= lt;jgs@bgp.nu>, "Murphy, Sandra&q= uot; <Sandra.Murphy@parsons= .com>
Subject: Re: [Idr] 1 WG call for Re= view draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

Hi,

&n= bsp;

Thanks = for the cross WG review. Please find below some proposed comments.

&n= bsp;

1)      For people not following SIDR, could you please elaborate on why ht= tp://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been= used? (via the registration of a new Point of Insertion specific to origin= validation) (as I though draft-ietf-idr-custom-decision was intended to be the last time BGP decision process would be modified)

&n= bsp;
#Keyur: The draft don't suggest modifications to the BGP best path alg= orithm. Infact the next rev of the draft should fix and remove section 3 as= well.  The extended community used in draft is use to signal BGP best= path validation state within an IBGP network.

2)      Could the document specify the action to be taken when multiple =93Ori= gin validation state extended=94 community are present with different valid= ation state? And how are handled validation state value > 2. (from current text, it would not be considered an erro= r, just lower priority. But I would prefer an explicit statement to avoid s= urprising error handling behavior)

#Keyur: There SHOULD not be multiple such extended communities for a g= iven BGP path. We can add the necessary text.

=  

3)      Rfc 6811 is referenced twice in important sections. What about moving = it to =93normative reference=94?

=  
#Keyur: Sure.

4)      Following discussion triggered by http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 = I understood that the IDR conclusion was that a non-transitive community ma= y be attached on the outbound policy of an eBGP session; hence may received= over an eBGP session. Given this, IMO the security consideration needs more text. (assuming that the ability= for a neighboring AS to influence/force the origin validation state is con= sidered acceptable, which would probably need to be discussed in SIDR)=

#Keyur:  Ideally, the usage of this community should NOT be encou= raged across inter-as boundaries.  We can add necessary text to reflec= t that part. 

=  

Regards,
Keyur

Thanks,=

Regards= ,

Bruno

&n= bsp;

&n= bsp;

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, June 10, 2014 4:32 PM
To: idr wg
Cc: Murphy, Sandra; 'John G. Scudder'
Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validatio= n-signaling-04 - RFC4271 changes

 

IDR:

 

The SIDR WG has asked for cross review of the draft-ietf-sidr-origi= n-validation-signaling-04.  This draft changes the RFC 4271 decision p= rocess in the following manner:

 

 
If a BGP router supports prefix origin validation and is configured=
 for the extensions defined in this document, the validation step SHOULD be=
 performed prior to any of the steps defined in the decision process of [RFC4271].  The validation step is stat=
ed as follows:
 
      When comparing a pair of routes for =
a BGP destination, the route
      with the lowest "validation sta=
te" value is preferred.
 
In all other respects, the decision process remains unchanged.=

 

The draft is at:

 

http://tools.ietf.org/html/draft-ietf-s= idr-origin-validation-signaling-04

 

John and I would like to hear your comments regard= ing the RFC 4271 revision.  Please send comments that include =93suppo= rt=94  or =93no support=94.

 

Sue and John 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________ Idr mailing list Idr@ietf.org http= s://www.ietf.org/mailman/listinfo/idr --_000_CFBF295676128keyupateciscocom_-- From nobody Thu Jun 12 09:58:50 2014 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 BE50D1B27C6; Thu, 12 Jun 2014 09:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 ihW5eU170rle; Thu, 12 Jun 2014 09:58:45 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1131A0505; Thu, 12 Jun 2014 09:58:45 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id A60E428B003D; Thu, 12 Jun 2014 12:58:44 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 89EF11F8032; Thu, 12 Jun 2014 12:58:44 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EF07511B-8CA4-4C61-8C3B-113058338A72"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Thu, 12 Jun 2014 12:58:43 -0400 Message-Id: References: To: "Keyur Patel (keyupate)" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HVtwW60miaqTG0k-qVBVOpQTlZM Cc: bruno.decraene@orange.com, "sidr@ietf.org list" , John Scudder , Susan Hares , idr wg Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 12 Jun 2014 16:58:47 -0000 --Apple-Mail=_EF07511B-8CA4-4C61-8C3B-113058338A72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Forwarded to sidr to keep them in this discussion. --Sandy On Jun 12, 2014, at 12:52 PM, "Keyur Patel (keyupate)" = wrote: > Hi Bruno, >=20 > Thanks for the draft review. Comments inlined #Keyur >=20 > From: > Date: Tue, 10 Jun 2014 15:40:05 +0000 > To: Susan Hares , idr wg > Cc: "'John G. Scudder'" , "Murphy, Sandra" = > Subject: Re: [Idr] 1 WG call for Review = draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes >=20 > Hi, > =20 > Thanks for the cross WG review. Please find below some proposed = comments. > =20 > 1) For people not following SIDR, could you please elaborate on = why http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not = been used? (via the registration of a new Point of Insertion specific to = origin validation) (as I though draft-ietf-idr-custom-decision was = intended to be the last time BGP decision process would be modified) > =20 > #Keyur: The draft don't suggest modifications to the BGP best path = algorithm. Infact the next rev of the draft should fix and remove = section 3 as well. The extended community used in draft is use to = signal BGP best path validation state within an IBGP network. >=20 > 2) Could the document specify the action to be taken when = multiple =93Origin validation state extended=94 community are present = with different validation state? And how are handled validation state = value > 2. (from current text, it would not be considered an error, just = lower priority. But I would prefer an explicit statement to avoid = surprising error handling behavior) >=20 > #Keyur: There SHOULD not be multiple such extended communities for a = given BGP path. We can add the necessary text. > =20 > 3) Rfc 6811 is referenced twice in important sections. What about = moving it to =93normative reference=94? > =20 > #Keyur: Sure. >=20 > 4) Following discussion triggered by = http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 I = understood that the IDR conclusion was that a non-transitive community = may be attached on the outbound policy of an eBGP session; hence may = received over an eBGP session. Given this, IMO the security = consideration needs more text. (assuming that the ability for a = neighboring AS to influence/force the origin validation state is = considered acceptable, which would probably need to be discussed in = SIDR) > #Keyur: Ideally, the usage of this community should NOT be encouraged = across inter-as boundaries. We can add necessary text to reflect that = part.=20 > =20 >=20 > Regards, > Keyur >=20 > Thanks, > Regards, > Bruno > =20 > =20 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Tuesday, June 10, 2014 4:32 PM > To: idr wg > Cc: Murphy, Sandra; 'John G. Scudder' > Subject: [Idr] 1 WG call for Review = draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes > =20 > IDR: > =20 > The SIDR WG has asked for cross review of the = draft-ietf-sidr-origin-validation-signaling-04. This draft changes the = RFC 4271 decision process in the following manner: > =20 > =20 > If a BGP router supports prefix origin validation and is configured = for the extensions defined in this document, the validation step SHOULD = be performed prior to any of the steps defined in the decision process = of [RFC4271]. The validation step is stated as follows: > =20 > When comparing a pair of routes for a BGP destination, the route > with the lowest "validation state" value is preferred. > =20 > In all other respects, the decision process remains unchanged. > =20 > The draft is at: > =20 > = http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 > =20 > John and I would like to hear your comments regarding the RFC 4271 = revision. Please send comments that include =93support=94 or =93no = support=94. > =20 > Sue and John > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ Idr mailing list = Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_EF07511B-8CA4-4C61-8C3B-113058338A72 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTmdxEAAoJEHplpQeet0IZDVsQAI+ZEfTT9Kd5myhAUyMCCy0O f4avJ8K06dymviBIslFL3UJXulEdlSpW6R0ci4Rio71wSj87YEapADChq0P+aKxy mCPdYqXd1F8rGlnhDfhGVxHuZfObx5ZLDYzwq+wkQ/4OPfN0XVxjSL0Dp6cbDlrS 1Wg2HtCEAzaGCew3CFLzxgA7YQkifVfOPnNxI7kILI0HQ73aIlQ66z3YNJAYWQGR 9zvGeO4XLlBu0Sr1YYmNu6aY3Oy2TYVW2CAIDm3STs01OaiQ2WGVNj+yry5FU+0H T/NiVy8VEHCO94n36z2Kls6L/AB7BGxo1e52nMom2LsjGAQLtfdZCUkhcpqALU30 4/qbZryA9r3rw2JKctmcTSCdlrwEACygTGRs3DCprUu+EWn0RL8n2FRmMl7H1vvN iq4y8NdKSe+Uz3a5En1u9f4qZBOjS6tWXyrdBFlyaI4794Oq2z8SQMaZ5qQloM9W 5t3JfQvAoG+wrq3ey0u8NtEM2ZrosFxX4y/GhYVLSnG1iz5Q6zkpx5seCoURtnhW W4kDdhcPU0r7QHnnhTTsjS1x6Q8sZvwFgvosGMGR68Rr63rsRIvCUQ8GbRu6CRqU GiZ38KDb8RKxG1K1ZBim0MrrBZJquAvOqhq3jIN2yg3Hf5jzYx+ohXg+lMx5BxiS ZZ84t40tDCxDWLJxI+z/ =Ief7 -----END PGP SIGNATURE----- --Apple-Mail=_EF07511B-8CA4-4C61-8C3B-113058338A72-- From nobody Thu Jun 12 10:01:20 2014 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 211511B27C6; Thu, 12 Jun 2014 10:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0Fzwt5c2vaca; Thu, 12 Jun 2014 10:01:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58CB1B27ED; Thu, 12 Jun 2014 10:01:14 -0700 (PDT) Received: from [172.29.6.121] (66.129.239.13) by BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) with Microsoft SMTP Server (TLS) id 15.0.959.24; Thu, 12 Jun 2014 17:01:11 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <5399AE30.3020703@alcatel-lucent.com> Date: Thu, 12 Jun 2014 13:00:59 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5399AE30.3020703@alcatel-lucent.com> To: Martin Vigoureux X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.239.13] X-ClientProxiedBy: BY2PR04CA060.namprd04.prod.outlook.com (10.141.249.178) To BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02408926C4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(51704005)(199002)(189002)(24454002)(377454003)(62966002)(92726001)(74502001)(83072002)(93916002)(86362001)(85852003)(81542001)(19580395003)(4396001)(83322001)(42186004)(19580405001)(81342001)(74662001)(83716003)(66066001)(104166001)(57306001)(46102001)(76482001)(88136002)(79102001)(89996001)(82746002)(77982001)(50226001)(23746002)(80022001)(87286001)(64706001)(87976001)(20776003)(47776003)(99396002)(33656002)(36756003)(50466002)(76176999)(101416001)(50986999)(77156001)(102836001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB721; H:[172.29.6.121]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:3; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/9oeMcETbwsLS4cNjDMXz90OjtGY Cc: mpls@ietf.org, l3vpn@ietf.org, idr@ietf.org, idr-chairs@tools.ietf.org, l3vpn-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:01:18 -0000 I=92ve read and support publication. =97John On Jun 12, 2014, at 9:42 AM, Martin Vigoureux = wrote: > Working Groups, >=20 > This is to start a 2-week Working Group Last Call in three Working > Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. >=20 > The draft has been made a WG Document by WG Chairs decision. >=20 > In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP > VPNs), an optional transitive BGP attribute called the > "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is > specified. This BGP attribute uses an octet field to specify the > PMSI tunnel type. RFC 6514 allocates the values 0-7. >=20 > There now is need to make further code point allocations from this > name space. In particular, draft-ietf-mpls-seamless-mcast > needs to make such an allocation. That draft is currently in WG Last > Call in the MPLS Working Group. >=20 > draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called = "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for = these code points. > The registry is created in the "Border Gateway Protocol (BGP) > Parameters" registry. >=20 > Please send comments to the l3vpn mailing list (l3vpn@ietf.org). >=20 > The WG LC will end on Friday the 27th of June. >=20 >=20 > Martin, on behalf of the WGs co-chairs From nobody Thu Jun 12 12:51:36 2014 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 BA5AD1B27FB for ; Thu, 12 Jun 2014 12:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 A1ccSZGdfy0h for ; Thu, 12 Jun 2014 12:51:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B401A0249 for ; Thu, 12 Jun 2014 12:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1702; q=dns/txt; s=iport; t=1402602693; x=1403812293; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=PgQ9v+Uqy9qdPUAu6kbR59DEe0XjP65AA5460naTJbo=; b=Ow2588BFEmHLBrnndoiOI5Ps2z0zXyWqTbf6x1NQ6FTS4qmI/vHXv1VC JYraTwlTXI/90LmzF0AolJKTI98cdfKeuqkSMfDtDhqieC95GaXTEfDOZ IHqcVax9aAgoWBvpUR6+431QVr6csv/xtVtD657RbLd0Mcs5z+NXqfWSk U=; X-IronPort-AV: E=Sophos;i="5.01,467,1400025600"; d="scan'208";a="332717401" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP; 12 Jun 2014 19:51:32 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5CJpWBg019577; Thu, 12 Jun 2014 19:51:32 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id C41C876C; Thu, 12 Jun 2014 15:51:31 -0400 (EDT) From: Eric Rosen To: "John G. Scudder" In-reply-to: Your message of Wed, 11 Jun 2014 19:14:47 -0400. <94367EEF-5673-4FAC-B85A-D799A46763F0@juniper.net> Date: Thu, 12 Jun 2014 15:51:31 -0400 Message-ID: <14305.1402602691@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vn7Vta3vYKLbWiN01V8xJ2CmpZg Cc: "idr@ietf. org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 19:51:34 -0000 > Expanded NEXT_HOP and MP_REACH_NLRI to talk about what it means to be a > "valid IP host address" With regard to: If the Next Hop field is an IPv6 address, it SHOULD be considered invalid if it appears in the "IANA IPv6 Special-Purpose Address Registry" [IANA-IPV6] and either the "destination" or the "forwardable" boolean in that registry is given as "false". This seems to rule out the use of IPv4-mapped IPv6 addresses in the Next Hop field. If so, it is incompatible with RFC 4798 ("6PE"), as RFC 4798 explicitly mandates the use of IPv4-mapped IPv6 addresses under certain circumstances. For certain AFI/SAFIs, the Next Hop is in the form of a VPN-IPv4 or VPN-IPv6 address, where the first eight octets are supposed to be zero and the remaining octets are supposed to be a "syntactically valid" IPv4 or IPv6 address (and in the case of "6vPE" (RFC 4659), the IPv6 part could be an IPv4-mapped IPv6 address). Probably there should be some mention of this. Section 5.4 begins "Certain address families, for example MVPN [RFC7117] and EVPN [I-D.ietf-l2vpn-evpn] have NLRI that are typed." I believe the first reference is supposed to be either "MCAST-VPN [RFC6514]" or "MCAST-VPLS [RFC7117]", or perhaps both. > Still to do: > - Traffic Engineering path attribute is stubbed out. I've pinged the > - authors of RFC 5543 to ask if they'd be willing to contribute text. > Given that there's a 'TBD' section, -12 is obviously not ready for > publication, If information about the TE path attribute is blocking the progress of the error handling draft, please consider advancing the draft without that information. From nobody Thu Jun 12 13:13:18 2014 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 6981C1A01D6 for ; Thu, 12 Jun 2014 13:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dghjFRBSs-8i for ; Thu, 12 Jun 2014 13:12:58 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87321A0275 for ; Thu, 12 Jun 2014 13:12:57 -0700 (PDT) Received: from [172.29.6.121] (66.129.239.13) by BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) with Microsoft SMTP Server (TLS) id 15.0.959.24; Thu, 12 Jun 2014 20:12:55 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <14305.1402602691@erosen-lnx> Date: Thu, 12 Jun 2014 16:12:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <98112CB7-3F9F-4713-9D43-F16BFB63C7C0@juniper.net> References: <14305.1402602691@erosen-lnx> To: X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.239.13] X-ClientProxiedBy: BY2PR03CA044.namprd03.prod.outlook.com (10.141.249.17) To BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02408926C4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6049001)(6009001)(428001)(24454002)(377454003)(51704005)(199002)(189002)(33656002)(23726002)(99396002)(76176999)(36756003)(50466002)(80022001)(87286001)(89996001)(77982001)(82746002)(50226001)(64706001)(20776003)(47776003)(87976001)(97756001)(50986999)(102836001)(77156001)(101416001)(85852003)(81542001)(21056001)(83322001)(42186004)(81342001)(19580405001)(19580395003)(4396001)(92726001)(86362001)(92566001)(74502001)(62966002)(88136002)(76482001)(79102001)(66066001)(46406003)(46102001)(74662001)(83716003)(104166001)(57306001)(31966008)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB721; H:[172.29.6.121]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/KGJIxEY0NWFYRgIXsisoMRNNmOA Cc: "idr@ietf. org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 20:13:07 -0000 Eric, Thanks for your comments. On Jun 12, 2014, at 3:51 PM, Eric Rosen wrote: >=20 >> Expanded NEXT_HOP and MP_REACH_NLRI to talk about what it means to be = a >> "valid IP host address" >=20 > With regard to: >=20 > If the Next Hop field is an IPv6 address, it SHOULD be considered > invalid if it appears in the "IANA IPv6 Special-Purpose Address > Registry" [IANA-IPV6] and either the "destination" or the > "forwardable" boolean in that registry is given as "false". >=20 > This seems to rule out the use of IPv4-mapped IPv6 addresses in the = Next Hop > field. If so, it is incompatible with RFC 4798 ("6PE"), as RFC 4798 > explicitly mandates the use of IPv4-mapped IPv6 addresses under = certain > circumstances. I see your point. Do you think it would be sufficient to carve out an = exception for this specific case? > For certain AFI/SAFIs, the Next Hop is in the form of a VPN-IPv4 or = VPN-IPv6 > address, where the first eight octets are supposed to be zero and the > remaining octets are supposed to be a "syntactically valid" IPv4 or = IPv6 > address (and in the case of "6vPE" (RFC 4659), the IPv6 part could be = an > IPv4-mapped IPv6 address). Probably there should be some mention of = this. Probably. I don't suppose you have text to suggest? It was painful = enough to find a way to specify what a "valid IP host address" is, = without having to now go spelunking for every case where we've already = bent this rule (or "rule").=20 Another alternative, if it gets too hairy to spec this, would be to back = the changes out. I don't know how the rest of the WG would feel about = that. > Section 5.4 begins >=20 > "Certain address families, for example MVPN [RFC7117] and EVPN > [I-D.ietf-l2vpn-evpn] have NLRI that are typed." >=20 > I believe the first reference is supposed to be either "MCAST-VPN = [RFC6514]" > or "MCAST-VPLS [RFC7117]", or perhaps both. OK, thanks. I'll address this in the next rev. >> Still to do: >=20 >> - Traffic Engineering path attribute is stubbed out. I've pinged the >> - authors of RFC 5543 to ask if they'd be willing to contribute text.=20= >=20 >> Given that there's a 'TBD' section, -12 is obviously not ready for >> publication, >=20 > If information about the TE path attribute is blocking the progress of = the > error handling draft, please consider advancing the draft without that > information. While I'd be overjoyed to RFC this thing and move on, off-hand I can't = think of a justification for singling the TE path attribute out as not = needing to be updated. I'd be pleased to be provided with one, though. --John= From nobody Thu Jun 12 18:13:26 2014 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 60B541A00DF; Thu, 12 Jun 2014 18:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 069X6-YAE_wF; Thu, 12 Jun 2014 18:13:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889A81B280D; Thu, 12 Jun 2014 18:13:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIJ17509; Fri, 13 Jun 2014 01:13:12 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Jun 2014 02:13:11 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.46]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 09:13:08 +0800 From: Mach Chen To: Martin Vigoureux , "l3vpn@ietf.org" , "mpls@ietf.org" , "idr@ietf.org" Thread-Topic: [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 Thread-Index: AQHPhkQs3nxgXepTRUq4bppM42Rv/JtuPDHQ Date: Fri, 13 Jun 2014 01:13:07 +0000 Message-ID: References: <5399AE30.3020703@alcatel-lucent.com> In-Reply-To: <5399AE30.3020703@alcatel-lucent.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/FdfxqqYqIosXgXivrYtHaIJ7SrQ Cc: "l3vpn-chairs@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "idr-chairs@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [Idr] [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 01:13:20 -0000 I have read the short, clean and useful draft, and I support to publish thi= s document. Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Martin Vigoureux > Sent: Thursday, June 12, 2014 9:42 PM > To: l3vpn@ietf.org; mpls@ietf.org; idr@ietf.org > Cc: l3vpn-chairs@tools.ietf.org; mpls-chairs@tools.ietf.org; > idr-chairs@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 >=20 > Working Groups, >=20 > This is to start a 2-week Working Group Last Call in three Working Groups= (idr, > l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. >=20 > The draft has been made a WG Document by WG Chairs decision. >=20 > In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP VP= Ns), > an optional transitive BGP attribute called the "P-Multicast Service Inte= rface > Tunnel (PMSI Tunnel) attribute" is specified. This BGP attribute uses an= octet > field to specify the PMSI tunnel type. RFC 6514 allocates the values 0-7= . >=20 > There now is need to make further code point allocations from this name s= pace. > In particular, draft-ietf-mpls-seamless-mcast needs to make such an alloc= ation. > That draft is currently in WG Last Call in the MPLS Working Group. >=20 > draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called "P-Mult= icast > Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for these code point= s. > The registry is created in the "Border Gateway Protocol (BGP) Parameters" > registry. >=20 > Please send comments to the l3vpn mailing list (l3vpn@ietf.org). >=20 > The WG LC will end on Friday the 27th of June. >=20 >=20 > Martin, on behalf of the WGs co-chairs >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jun 12 19:13:11 2014 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 4833B1B2893 for ; Thu, 12 Jun 2014 19:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 DLOy11sqdZG5 for ; Thu, 12 Jun 2014 19:13:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E519F1B288D for ; Thu, 12 Jun 2014 19:13:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WvGzD-00057t-4T; Fri, 13 Jun 2014 02:12:59 +0000 Date: Thu, 12 Jun 2014 19:12:57 -0700 Message-ID: From: Randy Bush To: "Keyur Patel (keyupate)" In-Reply-To: References: <29140_1402414807_539726D7_29140_10276_1_53C29892C857584299CBF5D05346208A0716175D@PEXCVZYM11.corporate.adroot.infra.ftgroup> 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: http://mailarchive.ietf.org/arch/msg/idr/LocKPzUMQk4wDD1VuCydcb2M9qA Cc: "bruno.decraene@orange.com" , "'John G. Scudder'" , Susan Hares , idr wg Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 13 Jun 2014 02:13:09 -0000 > #Keyur: Ideally, the usage of this community should NOT be encouraged > #across inter-as boundaries. We can add necessary text to reflect > #that part. from rfc 7115, end of sec 5 Validity state signaling SHOULD NOT be accepted from a neighbor AS. The validity state of a received announcement has only local scope due to issues such as scope of trust, RPKI synchrony, and management of local trust anchors [LTA-USE]. randy From nobody Thu Jun 12 21:59:15 2014 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 1D6F21B28C4; Thu, 12 Jun 2014 21:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsPCfgQHJpdz; Thu, 12 Jun 2014 21:58:39 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045111B28C3; Thu, 12 Jun 2014 21:58:38 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id v10so2805559qac.32 for ; Thu, 12 Jun 2014 21:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GlVnlc7vS4UaCPT5AJxqCaPoyf+CkdGlvTxSXZUx10w=; b=tr6QzFSX8rvCG+ncTK5lLw+yZwZouduqHqfdWtO8mO97wXi+BaQ2zL7BJsx8m5GqDc 0WEVW1O5lAysLJhVDJx5Enb7XFFiPKTCZ3gPbkzojdzUtns7dZSs2yOdvLmP6XD4Rv90 25Rgktk8OQaKuPOwB6rWhhEbiDaxcOk9RQph+dJHp60M/VKCPD9DoRjPSq4WWJ35SUBa rE3pmWSpR9huW4Q7KK+6DVmtuNZIz+aag/ySoKsKqnHRP+AyWtspGbincPQ1riK295kR cf0PEBoFGoTrljL5LuKZ78wcWoumHHDi6yCbPFry3wTHZUN43rEQ6TcTzyGeGXAWiIfe jWlA== X-Received: by 10.229.87.201 with SMTP id x9mr433914qcl.20.1402635518141; Thu, 12 Jun 2014 21:58:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.148 with HTTP; Thu, 12 Jun 2014 21:58:18 -0700 (PDT) In-Reply-To: <5399AE30.3020703@alcatel-lucent.com> References: <5399AE30.3020703@alcatel-lucent.com> From: "Andrew G. Malis" Date: Fri, 13 Jun 2014 00:58:18 -0400 Message-ID: To: Martin Vigoureux Content-Type: multipart/alternative; boundary=001a11337b7acf0d9704fbb08799 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/1DAXfSs7XQGuARGFnECA8SNevOA Cc: "mpls@ietf.org" , L3VPN list , idr@ietf.org, idr-chairs@tools.ietf.org, l3vpn-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject: Re: [Idr] [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 04:58:44 -0000 --001a11337b7acf0d9704fbb08799 Content-Type: text/plain; charset=UTF-8 This draft has one of this highest usefulness vs. length ratios I've ever seen. I very much support publication. My only comment is that there's an obvious typo in section 3, "secirity". Cheers, Andy On Thu, Jun 12, 2014 at 9:42 AM, Martin Vigoureux < martin.vigoureux@alcatel-lucent.com> wrote: > Working Groups, > > This is to start a 2-week Working Group Last Call in three Working > Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. > > The draft has been made a WG Document by WG Chairs decision. > > In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP > VPNs), an optional transitive BGP attribute called the > "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is > specified. This BGP attribute uses an octet field to specify the > PMSI tunnel type. RFC 6514 allocates the values 0-7. > > There now is need to make further code point allocations from this > name space. In particular, draft-ietf-mpls-seamless-mcast > needs to make such an allocation. That draft is currently in WG Last > Call in the MPLS Working Group. > > draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called > "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for these > code points. > The registry is created in the "Border Gateway Protocol (BGP) > Parameters" registry. > > Please send comments to the l3vpn mailing list (l3vpn@ietf.org). > > The WG LC will end on Friday the 27th of June. > > > Martin, on behalf of the WGs co-chairs > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a11337b7acf0d9704fbb08799 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This draft has one of this highest usefulness vs. length r= atios I've ever seen. I very much support publication. My only comment = is that there's an obvious typo in section 3, "secirity".

Cheers,
Andy


On Thu, Jun 12, 2014 at 9:42 AM, Martin = Vigoureux <martin.vigoureux@alcatel-lucent.com> wrote:
Working Groups,

This is to start a 2-week Working Group Last Call in three Working
Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02.
The draft has been made a WG Document by WG Chairs decision.

In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs), an optional transitive BGP attribute called the
"P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is=
specified. =C2=A0This BGP attribute uses an octet field to specify the
PMSI tunnel type. =C2=A0RFC 6514 allocates the values 0-7.

There now is need to make further code point allocations from this
name space. =C2=A0In particular, draft-ietf-mpls-seamless-mcast
needs to make such an allocation. That draft is currently in WG Last
Call in the MPLS Working Group.

draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called "P-M= ulticast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for thes= e code points.
The registry is created in the "Border Gateway Protocol (BGP)
Parameters" registry.

Please send comments to the l3vpn mailing list (l3vpn@ietf.org).

The WG LC will end on Friday the 27th of June.


Martin, on behalf of the WGs co-chairs

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--001a11337b7acf0d9704fbb08799-- From nobody Fri Jun 13 01:11:24 2014 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 D49EA1A0397 for ; Fri, 13 Jun 2014 01:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oC-TPxHu7TaF for ; Fri, 13 Jun 2014 01:11:10 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC1C1A01F9 for ; Fri, 13 Jun 2014 01:11:08 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id x19so2138427ier.16 for ; Fri, 13 Jun 2014 01:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rlf/EG9PS1Rc94qvOuzz/2Dx9F2ZXecaCGCXca2TzgE=; b=Xggp7Gp0QUNTjagH8iwc1mCFjQ308oGuZv9hNCMSd0yTlwPqjCYAAU/OVlSf2bMMU5 SJiY+uQ74+4FzUpEpnTKoB08IWHJvaUo6VNvEzTr7jGXOLoUYm2l9qtGEfS/zxFCTNbi HZgizaDwIXvtW2KpD079R3navqTaVLgpUtj8/cdVHqwUNe+WcnVgtoEqI+3Eqr3Um8yi idGN9OGvHRFl7UCpaPH1GOf7wD45+9RYYYcwC6QTv6dNM5UQuR4ZOYKQHXjkdQiQs7Gp +z/9A0qXt7GPVzv4p6lQMmbqYYELTIhYL9PnmV19i1I1KkkCew4OVFQIzGlGBmbYcXmV aXiA== MIME-Version: 1.0 X-Received: by 10.50.98.100 with SMTP id eh4mr2489733igb.9.1402647067483; Fri, 13 Jun 2014 01:11:07 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 13 Jun 2014 01:11:07 -0700 (PDT) In-Reply-To: References: <29140_1402414807_539726D7_29140_10276_1_53C29892C857584299CBF5D05346208A0716175D@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Fri, 13 Jun 2014 10:11:07 +0200 X-Google-Sender-Auth: ITBtgtz3z0ZToLa3q-9fcM7LFa8 Message-ID: From: Robert Raszuk To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/1Ga-lkdw7cbo_0_TaFmj_uMZujA Cc: "Keyur Patel \(keyupate\)" , "bruno.decraene@orange.com" , Susan Hares , "John G. Scudder" , idr wg Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 13 Jun 2014 08:11:13 -0000 > Validity state signaling SHOULD NOT be accepted from a neighbor AS. I would agree + also add that setting this extended community by manual EBGP policy should NOT be supported. The above along with the fact that this is already non-transitive in the AS scope should solve that worry completely. r. On Fri, Jun 13, 2014 at 4:12 AM, Randy Bush wrote: >> #Keyur: Ideally, the usage of this community should NOT be encouraged >> #across inter-as boundaries. We can add necessary text to reflect >> #that part. > > from rfc 7115, end of sec 5 > > Validity state signaling SHOULD NOT be accepted from a neighbor AS. > The validity state of a received announcement has only local scope > due to issues such as scope of trust, RPKI synchrony, and management > of local trust anchors [LTA-USE]. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jun 13 02:02:34 2014 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 6F0B11A035B for ; Fri, 13 Jun 2014 02:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3f_rdb25fcRg for ; Fri, 13 Jun 2014 02:02:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BF631A030E for ; Fri, 13 Jun 2014 02:02:31 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 95B3F2DC21C; Fri, 13 Jun 2014 11:02:29 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6A9D14C0CE; Fri, 13 Jun 2014 11:02:29 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 13 Jun 2014 11:02:28 +0200 From: To: Robert Raszuk , Randy Bush Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPht8GB/uGL+YYM0KA0B8arly+15tuvH4Q Date: Fri, 13 Jun 2014 09:02:28 +0000 Message-ID: <11288_1402650149_539ABE25_11288_1186_5_53C29892C857584299CBF5D05346208A07162986@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <29140_1402414807_539726D7_29140_10276_1_53C29892C857584299CBF5D05346208A0716175D@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.4.92121 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HEzBfq8C6LxZwqOO61UVhs9mSQM Cc: "Keyur Patel \(keyupate\)" , idr wg , Susan Hares , "John G. Scudder" Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 13 Jun 2014 09:02:33 -0000 PiA+IFZhbGlkaXR5IHN0YXRlIHNpZ25hbGluZyBTSE9VTEQgTk9UIGJlIGFjY2VwdGVkIGZyb20g YSBuZWlnaGJvciBBUy4NCj4gDQo+IEkgd291bGQgYWdyZWUNCg0KSSBhZ3JlZSBvbiB0aGUgZ29h bC4NCk5vdyB0aGUgcXVlc3Rpb24gaXMgaG93IGRvIHlvdSBwcm90ZWN0IGZyb20gdGhpcywgaWYg eW91J3JlIHVuc3RydXN0ZWQgbmVpZ2hib3IgQVMgc2VuZCB0aGlzIGNvbW11bml0eSBvdmVyIGVC R1Agc2Vzc2lvbi4NCg0KPiArIGFsc28gYWRkIHRoYXQgc2V0dGluZyB0aGlzIGV4dGVuZGVkIGNv bW11bml0eSBieSBtYW51YWwNCj4gRUJHUCBwb2xpY3kgc2hvdWxkIE5PVCBiZSBzdXBwb3J0ZWQu DQoNCklNTyBhZGRpbmcgdGhlIHRleHQgIlRoZSBzZW5kZXIgc2hvdWxkIG5vdCBkbyB0aGF0IiBp cyBub3QgYSB2ZXJ5IHN0cm9uZyBwcm90ZWN0aW9uLiBPdGhlcndpc2UsIHdlIHdvdWxkIG5vdCBu ZWVkIGFueSBjcnlwdG8gc2lnbmF0dXJlLiAoZS5nLiB5b3Ugc2hvdWxkIG5vdCBvcmlnaW5hdGUg YSBCR1Agcm91dGUgaWYgeW91IGFyZSBub3QgdGhlIHRydWUgb3JpZ2luYXRvcikuDQpZb3UgY2Fu IGFkZCB0aGUgY2hlY2sgb24gdGhlIHJlY2VpdmVyIHNpZGUsIGJ1dCB0aGlzIHdvdWxkIG5vdyBy ZXF1aXJlIHRoYXQgYWxsIEFTQlIgYmUgdXBncmFkZWQgdG8gc3VwcG9ydCB0aGlzIG5ldyBjb21t dW5pdHksIGJlZm9yZSBpdCBjb3VsZCBiZSB1c2VkLiBJZiB0aGlzIGlzIHRoZSBjaG9zZW4gcGF0 aCwgaXQgc2hvdWxkIGJlIHdyaXR0ZW4gaW4gdGhlIGRyYWZ0IGluIHRoZSBkZXBsb3ltZW50IGNv bnNpZGVyYXRpb24gc2VjdGlvbg0KIA0KPiBUaGUgYWJvdmUgYWxvbmcgd2l0aCB0aGUgZmFjdCB0 aGF0IHRoaXMgaXMgYWxyZWFkeSBub24tdHJhbnNpdGl2ZSBpbiB0aGUgQVMNCj4gc2NvcGUgc2hv dWxkIHNvbHZlIHRoYXQgd29ycnkgY29tcGxldGVseS4NCg0KTm90IHlldC4NCiANCj4gci4NCj4g DQo+IE9uIEZyaSwgSnVuIDEzLCAyMDE0IGF0IDQ6MTIgQU0sIFJhbmR5IEJ1c2ggPHJhbmR5QHBz Zy5jb20+IHdyb3RlOg0KPiA+PiAjS2V5dXI6IElkZWFsbHksIHRoZSB1c2FnZSBvZiB0aGlzIGNv bW11bml0eSBzaG91bGQgTk9UIGJlIGVuY291cmFnZWQNCj4gPj4gI2Fjcm9zcyBpbnRlci1hcyBi b3VuZGFyaWVzLiAgV2UgY2FuIGFkZCBuZWNlc3NhcnkgdGV4dCB0byByZWZsZWN0DQo+ID4+ICN0 aGF0IHBhcnQuDQo+ID4NCj4gPiBmcm9tIHJmYyA3MTE1LCBlbmQgb2Ygc2VjIDUNCj4gPg0KPiA+ ICAgIFZhbGlkaXR5IHN0YXRlIHNpZ25hbGluZyBTSE9VTEQgTk9UIGJlIGFjY2VwdGVkIGZyb20g YSBuZWlnaGJvciBBUy4NCj4gPiAgICBUaGUgdmFsaWRpdHkgc3RhdGUgb2YgYSByZWNlaXZlZCBh bm5vdW5jZW1lbnQgaGFzIG9ubHkgbG9jYWwgc2NvcGUNCj4gPiAgICBkdWUgdG8gaXNzdWVzIHN1 Y2ggYXMgc2NvcGUgb2YgdHJ1c3QsIFJQS0kgc3luY2hyb255LCBhbmQgbWFuYWdlbWVudA0KPiA+ ICAgIG9mIGxvY2FsIHRydXN0IGFuY2hvcnMgW0xUQS1VU0VdLg0KPiA+DQo+ID4gcmFuZHkNCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gSWRyIG1haWxpbmcgbGlzdA0KPiA+IElkckBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Fri Jun 13 02:07:24 2014 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 5E3951A030E; Fri, 13 Jun 2014 02:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 S2Fd7JkWBBaZ; Fri, 13 Jun 2014 02:07:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E601A03DB; Fri, 13 Jun 2014 02:07:17 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 97B1FC0D66; Fri, 13 Jun 2014 11:07:13 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 5D202C8058; Fri, 13 Jun 2014 11:07:13 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 13 Jun 2014 11:07:12 +0200 From: To: Randy Bush , "Keyur Patel (keyupate)" Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPhl6iB/uGL+YYM0KA0B8arly+15tuK7eAgACUJYA= Date: Fri, 13 Jun 2014 09:07:11 +0000 Message-ID: <17550_1402650433_539ABF41_17550_17892_1_53C29892C857584299CBF5D05346208A0716299F@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <29140_1402414807_539726D7_29140_10276_1_53C29892C857584299CBF5D05346208A0716175D@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.13.41819 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/LPOipiEkfIYBz7oLf_WmfkUQ8Uk Cc: idr wg , "'John G. Scudder'" , Susan Hares , "sidr@ietf.org list" Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 13 Jun 2014 09:07:22 -0000 > From: Randy Bush [mailto:randy@psg.com] > Sent: Friday, June 13, 2014 4:1= 3 AM >=20 > > #Keyur: Ideally, the usage of this community should NOT be encouraged > > #across inter-as boundaries. We can add necessary text to reflect > > #that part. >=20 > from rfc 7115, end of sec 5 >=20 > Validity state signaling SHOULD NOT be accepted from a neighbor AS. > The validity state of a received announcement has only local scope > due to issues such as scope of trust, RPKI synchrony, and management > of local trust anchors [LTA-USE]. Fine. If this is the choosen way, draft-ietf-sidr-origin-validation-signaling sho= uld also say that: - ASBR should remove such community from routes received over eBGP sessions= (possibly modulo confederation, 2 AS from the same organization/trusted...) - this community must not be used in the AS until all ASBR are upgraded to = support draft-ietf-sidr-origin-validation-signaling >=20 > randy ___________________________________________________________________________= ______________________________________________ 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 Fri Jun 13 02:18:31 2014 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 A64281A03DB; Fri, 13 Jun 2014 02:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 AeVbpG2n_vS5; Fri, 13 Jun 2014 02:18:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E231A030E; Fri, 13 Jun 2014 02:18:25 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id EA1A03B40EF; Fri, 13 Jun 2014 11:18:23 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id C273AC804B; Fri, 13 Jun 2014 11:18:23 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 13 Jun 2014 11:18:23 +0200 From: To: "Keyur Patel (keyupate)" , Susan Hares Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPhl6iB/uGL+YYM0KA0B8arly+15tuwSEA Date: Fri, 13 Jun 2014 09:18:22 +0000 Message-ID: <17550_1402651103_539AC1DF_17550_18651_1_53C29892C857584299CBF5D05346208A071629B9@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <29140_1402414807_539726D7_29140_10276_1_53C29892C857584299CBF5D05346208A0716175D@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A071629B9PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.13.41819 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/2miuYkofqYngUopvWg_GT9NTIC8 Cc: idr wg , "'John G. Scudder'" , "sidr@ietf.org list" Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 13 Jun 2014 09:18:29 -0000 --_000_53C29892C857584299CBF5D05346208A071629B9PEXCVZYM11corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Keyur, Many thanks for the answers. Comments inline #Bruno Adding sidr in copy From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Thursday, June 12, 2014 6:52 PM To: DECRAENE Bruno IMT/OLN; Susan Hares; idr wg Cc: 'John G. Scudder'; Murphy, Sandra Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-s= ignaling-04 - RFC4271 changes Hi Bruno, Thanks for the draft review. Comments inlined #Keyur From: > Date: Tue, 10 Jun 2014 15:40:05 +0000 To: Susan Hares >, idr wg > Cc: "'John G. Scudder'" >, "Murphy, Sandra" <= Sandra.Murphy@parsons.com> Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-s= ignaling-04 - RFC4271 changes Hi, Thanks for the cross WG review. Please find below some proposed comments. 1) For people not following SIDR, could you please elaborate on why ht= tp://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been use= d? (via the registration of a new Point of Insertion specific to origin val= idation) (as I though draft-ietf-idr-custom-decision was intended to be the= last time BGP decision process would be modified) #Keyur: The draft don't suggest modifications to the BGP best path algorith= m. Infact the next rev of the draft should fix and remove section 3 as well= . The extended community used in draft is use to signal BGP best path vali= dation state within an IBGP network. #Bruno: current version (04) of the draft do change the BGP decision proce= ss. cf section 3. If you remove section 3 in the next revision, this is indeed a different st= ory. 2) Could the document specify the action to be taken when multiple "Or= igin validation state extended" community are present with different valida= tion state? And how are handled validation state value > 2. (from current t= ext, it would not be considered an error, just lower priority. But I would = prefer an explicit statement to avoid surprising error handling behavior) #Keyur: There SHOULD not be multiple such extended communities for a given = BGP path. We can add the necessary text. #Bruno: I agree on the goal. The question is how do you handle the case/err= or when there is more than one. I guess that this is less important if you remove section 3 and this commun= ity is purely informative with no impact on BGP decision process. 3) Rfc 6811 is referenced twice in important sections. What about movi= ng it to "normative reference"? #Keyur: Sure. 4) Following discussion triggered by http://tools.ietf.org/html/draft-= decraene-idr-rfc4360-clarification-00 I understood that the IDR conclusion = was that a non-transitive community may be attached on the outbound policy = of an eBGP session; hence may received over an eBGP session. Given this, IM= O the security consideration needs more text. (assuming that the ability fo= r a neighboring AS to influence/force the origin validation state is consid= ered acceptable, which would probably need to be discussed in SIDR) #Keyur: Ideally, the usage of this community should NOT be encouraged acro= ss inter-as boundaries. We can add necessary text to reflect that part. #Bruno: I agree on the goal. The question is how do you handle the case (er= ror/attack) where your untrusted neighbor sends you this community over an = eBGP session. Regards, Keyur Thanks, Regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, June 10, 2014 4:32 PM To: idr wg Cc: Murphy, Sandra; 'John G. Scudder' Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signa= ling-04 - RFC4271 changes IDR: The SIDR WG has asked for cross review of the draft-ietf-sidr-origin-valida= tion-signaling-04. This draft changes the RFC 4271 decision process in the= following manner: If a BGP router supports prefix origin validation and is configured for the= extensions defined in this document, the validation step SHOULD be perform= ed prior to any of the steps defined in the decision process of [RFC4271]. The validation step is stated as follo= ws: When comparing a pair of routes for a BGP destination, the route with the lowest "validation state" value is preferred. In all other respects, the decision process remains unchanged. The draft is at: http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 John and I would like to hear your comments regarding the RFC 4271 revision= . Please send comments that include "support" or "no support". Sue and John ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.o= rg https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A071629B9PEXCVZYM11corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Keyur,

 

Many th= anks for the answers. Comments inline #Bruno

Adding = sidr in copy

&n= bsp;

From: Keyur Pa= tel (keyupate) [mailto:keyupate@cisco.com]
Sent: Thursday, June 12, 2014 6:52 PM
To: DECRAENE Bruno IMT/OLN; Susan Hares; idr wg
Cc: 'John G. Scudder'; Murphy, Sandra
Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-valid= ation-signaling-04 - RFC4271 changes

 

Hi Brun= o,

&n= bsp;

Thanks = for the draft review. Comments inlined #Keyur

&n= bsp;

From: <br= uno.decraene@orange.com>
Date: Tue, 10 Jun 2014 15:40:05 +0000
To: Susan Hares <shares@ndzh.c= om>, idr wg <idr@ietf.org>=
Cc: "'John G. Scudder'" <= jgs@bgp.nu>, "Murphy, Sandra" <Sandra.Murphy@parsons.com>
Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-valid= ation-signaling-04 - RFC4271 changes

&n= bsp;

Hi,

 <= /span>

Thanks = for the cross WG review. Please find below some proposed comments.

 <= /span>

1)&nb= sp;     For people not following SIDR, could you please elaborate on why ht= tp://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been= used? (via the registration of a new Point of Insertion specific to origin= validation) (as I though draft-ietf-idr-custom-decision was intended to be the last time BGP decision process would be modified)

 <= /span>

#Keyur:= The draft don't suggest modifications to the BGP best path algorithm. Infa= ct the next rev of the draft should fix and remove section 3 as well.  = ;The extended community used in draft is use to signal BGP best path validation state within an IBGP network.<= /o:p>

#Bruno:= current version (04) of the  draft do change the BGP decision process= . cf section 3.

If you = remove section 3 in the next revision, this is indeed a different story.

 

2)&nb= sp;     Could the document specify the action to be taken when multiple “Ori= gin validation state extended” community are present with different v= alidation state? And how are handled validation state value > 2. (from current text, it would not be considered an erro= r, just lower priority. But I would prefer an explicit statement to avoid s= urprising error handling behavior)<= /o:p>

&n= bsp;

#Keyur:= There SHOULD not be multiple such extended communities for a given BGP pat= h. We can add the necessary text.

#Bruno:= I agree on the goal. The question is how do you handle the case/error when= there is more than one.

I guess= that this is less important if you remove section 3 and this community is = purely informative with no impact on BGP decision process.

=  <= /p>

3)&nb= sp;     Rfc 6811 is referenced twice in important sections. What about moving it t= o “normative reference”?

=  

#Keyur:= Sure.

&n= bsp;

4)&nb= sp;     Following discussion triggered by http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 = I understood that the IDR conclusion was that a non-transitive community ma= y be attached on the outbound policy of an eBGP session; hence may received= over an eBGP session. Given this, IMO the security consideration needs more text. (assuming that the ability= for a neighboring AS to influence/force the origin validation state is con= sidered acceptable, which would probably need to be discussed in SIDR)

#Keyur:=  Ideally, the usage of this community should NOT be encouraged across= inter-as boundaries.  We can add necessary text to reflect that part.=  

#Bruno:= I agree on the goal. The question is how do you handle the case (error/att= ack) where your untrusted neighbor sends you this community over an eBGP se= ssion.

=  <= /p>

 

Regards= ,

Keyur

&n= bsp;

Thanks,=

Regards= ,

Bruno

 <= /span>

 <= /span>

From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, June 10, 2014 4:32 PM
To: idr wg
Cc: Murphy, Sandra; 'John G. Scudder'
Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validatio= n-signaling-04 - RFC4271 changes

 =

IDR:

 

The SIDR WG has asked for cross review of the dr= aft-ietf-sidr-origin-validation-signaling-04.  This draft changes the = RFC 4271 decision process in the following manner:

 

 
If a BGP router supports prefix origin validation and is configured=
 for the extensions defined in this document, the validation step SHOULD be=
 performed prior to any of the steps defined in the decision process of [RFC4271].  The validation step is stat=
ed as follows:
 
      When comparing a pair of routes for =
a BGP destination, the route<=
/span>
      with the lowest "validation sta=
te" value is preferred.<=
/span>
 
In all other respects, the decision process remains unchanged.

 

The draft is at:

 

http://tools.ietf.or= g/html/draft-ietf-sidr-origin-validation-signaling-04

 

John and I would like to hear y= our comments regarding the RFC 4271 revision.  Please send comments th= at include “support”  or “no support”.

 

Sue and John 

__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

Thank you.

_______= ________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A071629B9PEXCVZYM11corpo_-- From nobody Fri Jun 13 02:26:18 2014 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 E4D6F1A038C; Fri, 13 Jun 2014 02:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZxLY-ddMa_sm; Fri, 13 Jun 2014 02:26:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05FC1A030E; Fri, 13 Jun 2014 02:26:14 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3D9EE22C58B; Fri, 13 Jun 2014 11:26:13 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1CF5035C048; Fri, 13 Jun 2014 11:26:13 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 13 Jun 2014 11:26:12 +0200 From: To: Randy Bush , "Keyur Patel (keyupate)" Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPhl6iB/uGL+YYM0KA0B8arly+15tuK7eAgACUJYCAAASGsA== Date: Fri, 13 Jun 2014 09:26:12 +0000 Message-ID: <7461_1402651573_539AC3B5_7461_10885_1_53C29892C857584299CBF5D05346208A071629D1@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <29140_1402414807_539726D7_29140_10276_1_53C29892C857584299CBF5D05346208A0716175D@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.13.61820 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jJBp-Rjhsp9K1oMk33qQDjRa4PA Cc: idr wg , "'John G. Scudder'" , Susan Hares , "sidr@ietf.org list" Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 13 Jun 2014 09:26:16 -0000 Randy, > From: DECRAENE Bruno IMT/OLN > Sent: Friday, June 13, 2014 11:07 AM >=20 >=20 >=20 > > From: Randy Bush [mailto:randy@psg.com] > Sent: Friday, June 13, 2014 > > 4:13 AM > > > > > #Keyur: Ideally, the usage of this community should NOT be > > > encouraged #across inter-as boundaries. We can add necessary text > > > to reflect #that part. > > > > from rfc 7115, end of sec 5 > > > > Validity state signaling SHOULD NOT be accepted from a neighbor AS. > > The validity state of a received announcement has only local scope > > due to issues such as scope of trust, RPKI synchrony, and management > > of local trust anchors [LTA-USE]. >=20 > Fine. > If this is the choosen way, draft-ietf-sidr-origin-validation-signaling s= hould > also say that: > - ASBR should remove such community from routes received over eBGP > sessions (possibly modulo confederation, 2 AS from the same > organization/trusted...) > - this community must not be used in the AS until all ASBR are upgraded to > support draft-ietf-sidr-origin-validation-signaling Just to clarify, my goal was to clarify that "non-transitive" community are= accepted over eBGP and hence is not a guaranty that this information was o= riginated by the local AS hence assumed to be trusted. I don't feel this is self-obvious from the name, hence my comment for infor= mation. Regards, Bruno =20 >=20 > > > > randy ___________________________________________________________________________= ______________________________________________ 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 Fri Jun 13 06:00:41 2014 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 17CC61B2851; Fri, 13 Jun 2014 06:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 G3r-GQSQr299; Fri, 13 Jun 2014 06:00:38 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19761B2824; Fri, 13 Jun 2014 06:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=97; q=dns/txt; s=iport; t=1402664438; x=1403874038; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=k5NnVrvzabAvkf6lLkKlOb3GKHbYzHsems7sExM1gVo=; b=CeyjFmS/+1KZKULZIljfLMfhtQWr9vHw3ZCVsWbUZ6t8Nx5+tCFwkP6h F+89F0PHauu5UqFml799Z/PSZ6GcCIQu0SKeFFRa3FXhEmRGM1yV+NCA2 YjEc9JRIcNgvQ6tYBEHQqPBSPhGjIbediv9qgFZE6456KnoIX07tDbON/ 0=; X-IronPort-AV: E=Sophos;i="5.01,471,1400025600"; d="scan'208";a="332904166" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP; 13 Jun 2014 13:00:37 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5DD0bvj023603; Fri, 13 Jun 2014 13:00:37 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id BD3C048E; Fri, 13 Jun 2014 09:00:36 -0400 (EDT) From: Eric Rosen To: Martin Vigoureux In-reply-to: Your message of Thu, 12 Jun 2014 15:42:08 +0200. <5399AE30.3020703@alcatel-lucent.com> Date: Fri, 13 Jun 2014 09:00:36 -0400 Message-ID: <10585.1402664436@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/iJFoR3czlQ__FZCpK_ThjCP3zv4 Cc: mpls@ietf.org, l3vpn@ietf.org, idr@ietf.org, idr-chairs@tools.ietf.org, l3vpn-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [Idr] [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:00:39 -0000 I support this document; however, I think it should be categorized as an Update to RFC 6514. From nobody Fri Jun 13 06:49:52 2014 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 C5FA81B2917; Fri, 13 Jun 2014 06:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 xgh0mmrwQq5W; Fri, 13 Jun 2014 06:49:49 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC0C1B2919; Fri, 13 Jun 2014 06:49:48 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: , "'Martin Vigoureux'" References: Your message of Thu, 12 Jun 2014 15:42:08 +0200. <5399AE30.3020703@alcatel-lucent.com> <10585.1402664436@erosen-lnx> In-Reply-To: <10585.1402664436@erosen-lnx> Date: Fri, 13 Jun 2014 09:49:37 -0400 Message-ID: <009101cf870e$5200a6a0$f601f3e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDytTMtdGzXD/fNBDUUmShwPcvpCZ0osY0A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vrY5PYemgqjUfPRW8APBrDrVaFE Cc: mpls@ietf.org, l3vpn@ietf.org, idr@ietf.org, l3vpn-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [Idr] [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:49:51 -0000 Eric: It relates and it updates the IANA section in RFC6514. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric Rosen Sent: Friday, June 13, 2014 9:01 AM To: Martin Vigoureux Cc: mpls@ietf.org; l3vpn@ietf.org; idr@ietf.org; idr-chairs@tools.ietf.org; l3vpn-chairs@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [Idr] [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 I support this document; however, I think it should be categorized as an Update to RFC 6514. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jun 13 06:55:06 2014 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 358B61B2878; Fri, 13 Jun 2014 06:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 rM32bTFRKGfo; Fri, 13 Jun 2014 06:54:58 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00851A03ED; Fri, 13 Jun 2014 06:54:57 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s5DDssmV011366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jun 2014 08:54:55 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s5DDssF7022971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jun 2014 15:54:54 +0200 Received: from [172.27.205.128] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 13 Jun 2014 15:54:53 +0200 Message-ID: <539B02AD.4010309@alcatel-lucent.com> Date: Fri, 13 Jun 2014 15:54:53 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Susan Hares , References: Your message of Thu, 12 Jun 2014 15:42:08 +0200. <5399AE30.3020703@alcatel-lucent.com> <10585.1402664436@erosen-lnx> <009101cf870e$5200a6a0$f601f3e0$@ndzh.com> In-Reply-To: <009101cf870e$5200a6a0$f601f3e0$@ndzh.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.40] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/eBKBT2fNuQ0KW35Ix1xNxuc1IGE Cc: mpls@ietf.org, l3vpn@ietf.org, idr@ietf.org, l3vpn-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [Idr] [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:55:00 -0000 Sue, I guess what Eric says is that if it effectively does, then this should be indicated in the header and mentioned in the Abstract/intro. -m Le 13/06/2014 15:49, Susan Hares a écrit : > Eric: > > It relates and it updates the IANA section in RFC6514. > > Sue > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric Rosen > Sent: Friday, June 13, 2014 9:01 AM > To: Martin Vigoureux > Cc: mpls@ietf.org; l3vpn@ietf.org; idr@ietf.org; idr-chairs@tools.ietf.org; > l3vpn-chairs@tools.ietf.org; rtg-ads@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: Re: [Idr] [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 > > > I support this document; however, I think it should be categorized as an > Update to RFC 6514. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > From nobody Fri Jun 13 07:09:46 2014 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 AF0061A00FB; Fri, 13 Jun 2014 07:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 zdP07HPogsiQ; Fri, 13 Jun 2014 07:09:42 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8B30A1B2869; Fri, 13 Jun 2014 07:09:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: "'Martin Vigoureux'" , References: Your message of Thu, 12 Jun 2014 15:42:08 +0200. <5399AE30.3020703@alcatel-lucent.com> <10585.1402664436@erosen-lnx> <009101cf870e$5200a6a0$f601f3e0$@ndzh.com> <539B02AD.4010309@alcatel-lucent.com> In-Reply-To: <539B02AD.4010309@alcatel-lucent.com> Date: Fri, 13 Jun 2014 10:09:35 -0400 Message-ID: <009301cf8711$1bf97200$53ec5600$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIS5sn81JJr+QPqDf2XZ37ngvLYSADytTMtAlZsivcDFXmWNJq1X0YQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AF0Et-xsojAOZ5TqDdUZyTwVDxo Cc: mpls@ietf.org, l3vpn@ietf.org, idr@ietf.org, l3vpn-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [Idr] [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:09:43 -0000 Martin: Agreed. I was trying to do a +1 to Eric's suggestion without using it since +1 is now politically incorrect (PI).=20 Sue -----Original Message----- From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com]=20 Sent: Friday, June 13, 2014 9:55 AM To: Susan Hares; erosen@cisco.com Cc: mpls@ietf.org; l3vpn@ietf.org; idr@ietf.org; = idr-chairs@tools.ietf.org; l3vpn-chairs@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [Idr] [mpls] WG Last Call on = draft-ietf-l3vpn-pmsi-registry-02 Sue, I guess what Eric says is that if it effectively does, then this should = be indicated in the header and mentioned in the Abstract/intro. -m Le 13/06/2014 15:49, Susan Hares a =E9crit : > Eric: > > It relates and it updates the IANA section in RFC6514. > > Sue > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric Rosen > Sent: Friday, June 13, 2014 9:01 AM > To: Martin Vigoureux > Cc: mpls@ietf.org; l3vpn@ietf.org; idr@ietf.org;=20 > idr-chairs@tools.ietf.org; l3vpn-chairs@tools.ietf.org;=20 > rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [Idr] [mpls] WG Last Call on=20 > draft-ietf-l3vpn-pmsi-registry-02 > > > I support this document; however, I think it should be categorized as=20 > an Update to RFC 6514. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > From nobody Fri Jun 13 08:12:59 2014 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 1C3E41A0350; Fri, 13 Jun 2014 08:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7ggbaFkHDUr; Fri, 13 Jun 2014 08:12:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AC91B28ED; Fri, 13 Jun 2014 08:12:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613151239.9913.86399.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 08:12:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/isyY6jwI7TLHvpIOFS-am42Ass4 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-migration-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: Fri, 13 Jun 2014 15:12:55 -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 : Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute Authors : Wesley George Shane Amante Filename : draft-ietf-idr-as-migration-01.txt Pages : 17 Date : 2014-06-13 Abstract: This draft discusses common methods of managing an ASN migration using some BGP feaures that while commonly-used are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work such as BGPSec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as-migration-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-as-migration-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 13 08:19:59 2014 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 8C13C1B2952 for ; Fri, 13 Jun 2014 08:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJId7F0-uTbd for ; Fri, 13 Jun 2014 08:19:55 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8B21B1B2949 for ; Fri, 13 Jun 2014 08:19:55 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,471,1400040000"; d="scan'208";a="353361190" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Jun 2014 11:19:07 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 13 Jun 2014 11:19:41 -0400 From: "George, Wes" To: "idr@ietf.org" Date: Fri, 13 Jun 2014 11:19:41 -0400 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as-migration-01.txt Thread-Index: Ac+HGuXP4Ik2S9v+T3mM9nQGxGeRdA== Message-ID: References: <20140613151239.9913.86399.idtracker@ietfa.amsl.com> In-Reply-To: <20140613151239.9913.86399.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ecC6NP9Tx5GLvRCnZ4k_x5Cm_wo Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 15:19:57 -0000 Q2hhbmdlbG9nOg0KDQpBZGRzIFJGQzIxMTkgYm9pbGVycGxhdGUgYW5kIHR3byBpbXBsZW1lbnRh dGlvbiBzZWN0aW9ucyAoMy4yIGFuZCA0LjIpIHRvDQpwcm92aWRlIDIxMTkgbm9ybWF0aXZlIGxh bmd1YWdlIGRlc2NyaWJpbmcgaG93IHRvIGltcGxlbWVudCB0aGUgZmVhdHVyZXMNCmRlc2NyaWJl ZCBieSB0aGUgZG9jdW1lbnQgKGFmdGVyIG11bHRpcGxlIHJlY29tbWVuZGF0aW9ucyB0byBpbmNs dWRlIHRoaXMNCmluc3RlYWQgb2YgdGhlIHZlbmRvciBkb2N1bWVudGF0aW9uKS4NClVwZGF0ZXMg dmVuZG9yLXNwZWNpZmljIGRvY3VtZW50YXRpb24gcmVmZXJlbmNlcywgYW5kIG1vdmVzIHRoZSBw b2ludGVycw0KdG8gdGhvc2UgZG9jdW1lbnRzIHRvIGFuIGltcGxlbWVudGF0aW9uIHJlcG9ydCBh cHBlbmRpeA0KSW5jb3Jwb3JhdGVzIHJldmlldyBmZWVkYmFjayBmcm9tIHNldmVyYWwgb2ZmLWxp c3QgcmV2aWV3cyBmcm9tIENpc2NvIGFuZA0KSnVuaXBlciBmb2xrcy4NCg0KT3BlbiBxdWVzdGlv bjogRG9lcyB0aGlzIG5lZWQgdG8gZm9ybWFsbHkgdXBkYXRlIHRoZSBCR1AgU3BlYywgYW5kIGlz DQppbmZvcm1hdGlvbmFsIHN0aWxsIHRoZSBhcHByb3ByaWF0ZSBzdGF0dXMgZm9yIHRoZSBkb2Mg bm93IHRoYXQgaXTigJlzDQphY3R1YWxseSBkZWZpbmluZyB0aGUgYmVoYXZpb3IgaW4gbm9ybWF0 aXZlIGxhbmd1YWdlPw0KDQpJIHRoaW5rIHRoaXMgbWlnaHQgYmUgcmVhZHkgZm9yIFdHTEMgdW5s ZXNzIHRoZXJlIGlzIGEgYnVybmluZyBkZXNpcmUgdG8NCmRpc2N1c3MgaXQgaW4gcGVyc29uIGlu IFRvcm9udG8uDQoNClRoYW5rcywNCg0KV2VzIEdlb3JnZQ0KDQoNCg0KT24gNi8xMy8xNCwgMTE6 MTIgQU0sICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciDQo8aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPmRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJbnRlci1Eb21haW4gUm91dGluZyBXb3JraW5nIEdyb3Vw IG9mDQo+dGhlIElFVEYuDQo+DQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBBdXRvbm9tb3Vz IFN5c3RlbSAoQVMpIE1pZ3JhdGlvbiBGZWF0dXJlcyBhbmQNCj5UaGVpciBFZmZlY3RzIG9uIHRo ZSBCR1AgQVNfUEFUSCBBdHRyaWJ1dGUNCj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IFdlc2xl eSBHZW9yZ2UNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIFNoYW5lIEFtYW50ZQ0KPiAgICAg ICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWlkci1hcy1taWdyYXRpb24tMDEudHh0DQo+ ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDE3DQo+ICAgICAgIERhdGUgICAgICAgICAgICA6IDIw MTQtMDYtMTMNCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIGRyYWZ0IGRpc2N1c3NlcyBjb21tb24g bWV0aG9kcyBvZiBtYW5hZ2luZyBhbiBBU04gbWlncmF0aW9uDQo+ICAgdXNpbmcgc29tZSBCR1Ag ZmVhdXJlcyB0aGF0IHdoaWxlIGNvbW1vbmx5LXVzZWQgYXJlIG5vdCBmb3JtYWxseSBwYXJ0DQo+ ICAgb2YgdGhlIEJHUDQgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBhbmQgbWF5IGJlIHZlbmRvci1z cGVjaWZpYyBpbg0KPiAgIGV4YWN0IGltcGxlbWVudGF0aW9uLiAgSXQgaXMgbmVjZXNzYXJ5IHRv IGRvY3VtZW50IHRoZXNlIGRlIGZhY3RvDQo+ICAgc3RhbmRhcmRzIHRvIGVuc3VyZSB0aGF0IHRo ZXkgYXJlIHByb3Blcmx5IHN1cHBvcnRlZCBpbiBmdXR1cmUgQkdQDQo+ICAgcHJvdG9jb2wgd29y ayBzdWNoIGFzIEJHUFNlYy4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWlkci1hcy1taWdyYXRpb24vDQo+DQo+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQg dmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1pZHItYXMtbWlncmF0aW9uLTAxDQo+DQo+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtaWRyLWFzLW1pZ3JhdGlvbi0wMQ0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlz c2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvDQoNCkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBteSBjb21w YW554oCZcyBtYWlsIHNlcnZlciwgSQ0KaGF2ZSBubyBjb250cm9sIG92ZXIgaXQuDQotLS0tLS0t LS0tLQ0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBw cml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2lu ZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRy ZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1h aWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3Ry aWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250 ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJt YW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBh bmQgYW55IHByaW50b3V0Lg0K From nobody Fri Jun 13 08:25:16 2014 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 CB1C41A0350; Fri, 13 Jun 2014 08:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WUsBGTTQFYU; Fri, 13 Jun 2014 08:25:12 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 045411A0108; Fri, 13 Jun 2014 08:25:11 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,471,1400040000"; d="scan'208";a="353372938" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Jun 2014 11:24:36 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 13 Jun 2014 11:25:11 -0400 From: "George, Wes" To: "bruno.decraene@orange.com" , Randy Bush , "Keyur Patel (keyupate)" Date: Fri, 13 Jun 2014 11:25:10 -0400 Thread-Topic: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: Ac+HG6pDtvEjjq37RwqeY6hgqzpWPg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/CqlJN4ZNJIEV0JNvvhH8Jk0HWb8 Cc: idr wg , "sidr@ietf.org list" Subject: Re: [Idr] [sidr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 13 Jun 2014 15:25:13 -0000 DQpPbiA2LzEzLzE0LCA1OjA3IEFNLCAiYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSINCjxicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tPiB3cm90ZToNCg0KPklmIHRoaXMgaXMgdGhlIGNob29zZW4g d2F5LCBkcmFmdC1pZXRmLXNpZHItb3JpZ2luLXZhbGlkYXRpb24tc2lnbmFsaW5nDQo+c2hvdWxk IGFsc28gc2F5IHRoYXQ6DQo+LSBBU0JSIHNob3VsZCByZW1vdmUgc3VjaCBjb21tdW5pdHkgZnJv bSByb3V0ZXMgcmVjZWl2ZWQgb3ZlciBlQkdQDQo+c2Vzc2lvbnMgKHBvc3NpYmx5IG1vZHVsbyBj b25mZWRlcmF0aW9uLCAyIEFTIGZyb20gdGhlIHNhbWUNCj5vcmdhbml6YXRpb24vdHJ1c3RlZC4u LikNCj4tIHRoaXMgY29tbXVuaXR5IG11c3Qgbm90IGJlIHVzZWQgaW4gdGhlIEFTIHVudGlsIGFs bCBBU0JSIGFyZSB1cGdyYWRlZA0KPnRvIHN1cHBvcnQgZHJhZnQtaWV0Zi1zaWRyLW9yaWdpbi12 YWxpZGF0aW9uLXNpZ25hbGluZw0KDQpKdXN0IHdhbnRlZCB0byBub3RlIHRoYXQgYXMgYW4gb3Bl cmF0b3Igb2YgYSBuZXR3b3JrIHdoZXJlIG15IEF1dG9ub21vdXMNClN5c3RlbSAoaS5lLiBUaGUg c3BhbiBvZiB0aGUgbmV0d29yayB1bmRlciBjb21tb24gY29udHJvbCkgc3BhbnMgbXVsdGlwbGUN CkF1dG9ub21vdXMgU3lzdGVtIE5VTUJFUlMsIHRoZXNlIGNhcnZlLW91dHMgdG8gaGFuZGxlIGNv bmZlZHMgYW5kIG11bHRpcGxlDQpBU05zIGZyb20gc2FtZSBvcmcgYXJlIHByZXR0eSBpbXBvcnRh bnQgaWYgSSBhbSB0byBpbXBsZW1lbnQgT3JpZ2luDQpWYWxpZGF0aW9uLiBCZWluZyBhYmxlIHRv IHZhbGlkYXRlIGF0IGV4dGVybmFsIEFTQlJzIGFuZCBrZWVwIHRoYXQgaW5mbw0KYWNyb3NzIHRo ZSBpbnRlcm5hbCBBU04gYm91bmRhcmllcyB3b3VsZCBtYWtlIGEgZGVwbG95bWVudCBpbiBuZXR3 b3Jrcw0KbGlrZSBtaW5lIG11Y2ggc2ltcGxlciB0aGFuIGlmIHdlIGhhdmUgdG8gcmV2YWxpZGF0 ZSBhdCB0aGUgaW50ZXJuYWwgQVNCUnMuDQoNClRoYW5rcw0KV2VzIEdlb3JnZQ0KDQoNClRoaXMg RS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVy IENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5l ciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWlu Zywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0 YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJl IHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUg dGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0 Lg0K From nobody Fri Jun 13 09:03:25 2014 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 F08101B297A for ; Fri, 13 Jun 2014 09:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 kHJGXUk-970Z for ; Fri, 13 Jun 2014 09:03:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DAB1A055D for ; Fri, 13 Jun 2014 09:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3540; q=dns/txt; s=iport; t=1402675403; x=1403885003; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=NmQtxzRCY9EELI2GcPK32gX1V9s7pTKx3h/xC0AeFXs=; b=bJX52VyvOEMYJ4zrPETY3KmF7HSQIbouxhgfbqyLo4IU9yuyfCCHbY3i u8USCIdmwS8703WAhfQaNktLw5FKizlGx3zHsqGQT+0iVvodrPTlF7UZY gIlso3v/5BkCkiIXzOxNBJPe4efQStGbzztg140E6TVMZblQPv+3npYRN w=; X-IronPort-AV: E=Sophos;i="5.01,471,1400025600"; d="scan'208";a="332956526" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP; 13 Jun 2014 16:03:23 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5DG3LNb029299; Fri, 13 Jun 2014 16:03:21 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id 71863775; Fri, 13 Jun 2014 12:03:21 -0400 (EDT) From: Eric Rosen To: "John G. Scudder" In-reply-to: Your message of Thu, 12 Jun 2014 16:12:47 -0400. <98112CB7-3F9F-4713-9D43-F16BFB63C7C0@juniper.net> Date: Fri, 13 Jun 2014 12:03:21 -0400 Message-ID: <15311.1402675401@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/JUD_oFzm_zfU-YMYfMK3bWguCR0 Cc: "idr@ietf. org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:03:24 -0000 I wonder if the first two bullet items of Section 7.11 should be slightly revised (and perhaps expanded to three items), as follows: o If the Next Hop field contains an IPv4 address (possibly as a sub-field), the field SHOULD be considered invalid if the IPv4 address appears in the "IANA IPv4 Special-Purpose Address Registry" [IANA-IPV4] and either the "destination" or the "forwardable" boolean in that registry is given as "false". o If the Next Hop field contains an IPv6 address (possibly as a sub-field), the field SHOULD be considered invalid if the IPv6 address appears in the "IANA IPv6 Special-Purpose Address Registry" [IANA-IPV6], the address is not an IPv4-mapped IPv6 address, and either the "destination" or the "forwardable" boolean in that registry is given as "false". o If the Next Hop field contains an IPv4-mapped IPv6 address (possibly as a sub-field), the field SHOULD be considered invalid unless the use of such addresses has been explicitly allowed for the particular AFI/SAFI that occurs in this MP_REACH_NLRI attribute. (E.g., see RFC 4659 and RFC 4798.) This would cover the 6PE and 6vPE cases, and would also cover the cases where the next hop field contains an RD followed by an IP address. John> Another alternative, if it gets too hairy to spec this, would be to John> back the changes out. I don't know how the rest of the WG would feel John> about that. That's also a possibility. The IANA special-purpose address registries really seem to be focused on the use of addresses in the data plane rather than the control plane; it's not obvious that the content of those registries should affect the control plane. Are we sure that there are no deployments (other than 6PE and 6vPE deployments) that use IP special-purpose addresses as (part of) the Next Hop field? > > "Certain address families, for example MVPN [RFC7117] and EVPN > [I-D.ietf-l2vpn-evpn] have NLRI that are typed." > > I believe the first reference is supposed to be either "MCAST-VPN [RFC6514]" > or "MCAST-VPLS [RFC7117]", or perhaps both. OK, thanks. I'll address this in the next rev. Eric> If information about the TE path attribute is blocking the progress of Eric> the error handling draft, please consider advancing the draft without Eric> that information. John> While I'd be overjoyed to RFC this thing and move on, off-hand I can't John> think of a justification for singling the TE path attribute out as not John> needing to be updated. I'd be pleased to be provided with one, John> though. Well, let me quote from some previous messages regarding this draft: "Of course we could continue error-handling as a seemingly eternal draft, but I think there is some value in saying "close enough" and graduating it to RFC, especially for implementors that are less steeped in the WG and don't necessarily have the background to distinguish between Internet Drafts that are really *drafts* and those that are de-facto standards." "The draft does try to strike a balance between prudence and avoidance of ever-mounting complexity of error-detection heuristics to attempt to detect ever less-likely problems." These sentiments seem very wise, and I think the draft has been around long enough for use to say that anything not incorporated yet is "out of scope" and will have to be covered in future documents. From nobody Fri Jun 13 10:04:13 2014 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 D892A1B2973 for ; Fri, 13 Jun 2014 10:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 bhpIgurhxGdV for ; Fri, 13 Jun 2014 10:04:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E2A1A01A8 for ; Fri, 13 Jun 2014 10:04:09 -0700 (PDT) Received: from [172.29.6.121] (66.129.239.13) by BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) with Microsoft SMTP Server (TLS) id 15.0.959.24; Fri, 13 Jun 2014 17:04:06 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <15311.1402675401@erosen-lnx> Date: Fri, 13 Jun 2014 13:03:55 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <9EC7FE4D-583C-49F4-BB3F-8879FA677573@juniper.net> References: <15311.1402675401@erosen-lnx> To: X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.239.13] X-ClientProxiedBy: BY2PR07CA051.namprd07.prod.outlook.com (10.141.251.26) To BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0241D5F98C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(51704005)(199002)(189002)(164054003)(24454002)(377454003)(83072002)(88136002)(81342001)(4396001)(19580395003)(83322001)(21056001)(42186004)(93916002)(19580405001)(74502001)(62966002)(86362001)(92566001)(46406003)(83716003)(104166001)(31966008)(57306001)(74662001)(79102001)(105586001)(66066001)(76482001)(81542001)(77982001)(46102001)(89996001)(80022001)(50226001)(97756001)(87286001)(64706001)(23726002)(47776003)(20776003)(87976001)(33656002)(36756003)(50466002)(76176999)(85852003)(50986999)(82746002)(92726001)(102836001)(99396002)(77156001)(101416001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB721; H:[172.29.6.121]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/qTlpcWCRvH8bMRwAOO3vjHLRbW8 Cc: "idr@ietf. org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:04:12 -0000 Eric, On Jun 13, 2014, at 12:03 PM, Eric Rosen wrote: > I wonder if the first two bullet items of Section 7.11 should be = slightly > revised (and perhaps expanded to three items), as follows: >=20 > o If the Next Hop field contains an IPv4 address (possibly as a > sub-field), the field SHOULD be considered invalid if the IPv4 = address > appears in the "IANA IPv4 Special-Purpose Address Registry" = [IANA-IPV4] > and either the "destination" or the "forwardable" boolean in that > registry is given as "false". >=20 > o If the Next Hop field contains an IPv6 address (possibly as a > sub-field), the field SHOULD be considered invalid if the IPv6 = address > appears in the "IANA IPv6 Special-Purpose Address Registry" > [IANA-IPV6], the address is not an IPv4-mapped IPv6 address, and = either > the "destination" or the "forwardable" boolean in that registry is > given as "false". >=20 > o If the Next Hop field contains an IPv4-mapped IPv6 address = (possibly as > a sub-field), the field SHOULD be considered invalid unless the = use of > such addresses has been explicitly allowed for the particular = AFI/SAFI > that occurs in this MP_REACH_NLRI attribute. (E.g., see RFC 4659 = and > RFC 4798.) >=20 > This would cover the 6PE and 6vPE cases, and would also cover the = cases > where the next hop field contains an RD followed by an IP address. =20= Thanks. This looks good. Barring further discussion, I'll plan to = incorporate your text into -13. > John> Another alternative, if it gets too hairy to spec this, would be = to > John> back the changes out. I don't know how the rest of the WG would = feel > John> about that. >=20 > That's also a possibility. The IANA special-purpose address = registries > really seem to be focused on the use of addresses in the data plane = rather > than the control plane; it's not obvious that the content of those > registries should affect the control plane. Are we sure that there = are no > deployments (other than 6PE and 6vPE deployments) that use IP > special-purpose addresses as (part of) the Next Hop field? No, I'm not sure, although the reasoning in citing the registry was that = if the address is non-forwardable, how do you expect to use it as a next = hop? You're right that this seems like an perversion of the registry's = original purpose. However the options I could see came down to: - Cite the registries as I've done, - Find a better citation -- I looked and didn't find anything, - Define "invalid IP host address" from the ground up -- seemed like a = terrible idea to do in this document, or - Ignore the issue as in earlier versions of the draft. Of these, citing the registries seemed less terrible than the = alternatives. I'm certainly open to proposals on how to improve. I guess = we could explicitly acknowledge that it's underspecified and invite = interested parties to write a spec to properly define "invalid IP host = address", without trying to actually fix it in this document. The = question comes down to whether the current text helps more than it = hurts. I'm inclined to think that it does, but then I would, wouldn't I? >> "Certain address families, for example MVPN [RFC7117] and EVPN >> [I-D.ietf-l2vpn-evpn] have NLRI that are typed." >>=20 >> I believe the first reference is supposed to be either "MCAST-VPN = [RFC6514]" >> or "MCAST-VPLS [RFC7117]", or perhaps both. >=20 > OK, thanks. I'll address this in the next rev. >=20 > Eric> If information about the TE path attribute is blocking the = progress of > Eric> the error handling draft, please consider advancing the draft = without > Eric> that information. >=20 > John> While I'd be overjoyed to RFC this thing and move on, off-hand I = can't > John> think of a justification for singling the TE path attribute out = as not > John> needing to be updated. I'd be pleased to be provided with one, > John> though. >=20 > Well, let me quote from some previous messages regarding this draft: >=20 > "Of course we could continue error-handling as a seemingly = eternal > draft, but I think there is some value in saying "close enough" = and > graduating it to RFC, especially for implementors that are less > steeped in the WG and don't necessarily have the background to > distinguish between Internet Drafts that are really *drafts* and = those > that are de-facto standards." >=20 > "The draft does try to strike a balance between prudence and = avoidance > of ever-mounting complexity of error-detection heuristics to = attempt > to detect ever less-likely problems." >=20 > These sentiments seem very wise, and I think the draft has been around = long > enough for use to say that anything not incorporated yet is "out of = scope" > and will have to be covered in future documents. Well-played. I'm OK with that approach. I'd like to invite anyone who feels we MUST = have coverage of the TE path attribute before publishing error-handing, = to propose text. Otherwise, I'll replace the section with something = like: 7.13. Traffic Engineering path attribute We note that [RFC5543] does not detail what constitutes "malformation" for the Traffic Engineering path attribute. A future update to that specification may provide more guidance. In the interim, an implementation that determines (for whatever reason) that an UPDATE message contains a malformed Traffic Engineering path attribute MUST handle it using the approach of "treat-as-withdraw". One final point to discuss is whether the proper approach is = "treat-as-withdraw" or if "attribute discard" would be OK in this case. Thanks, --John= From nobody Fri Jun 13 11:32:25 2014 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 1E8171B29CB; Fri, 13 Jun 2014 11:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvZVdxSaFfgZ; Fri, 13 Jun 2014 11:32:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 476A61A05F5; Fri, 13 Jun 2014 11:32:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613183222.27662.91400.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 11:32:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/RCJBLfHAPN6kvFfEZmS_dMLNvZA Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-13.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, 13 Jun 2014 18:32:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Revised Error Handling for BGP UPDATE Messages Authors : Enke Chen John G. Scudder Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-13.txt Pages : 18 Date : 2014-06-13 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, 6368 and 6790. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 13 11:42:23 2014 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 E3E111A05F5 for ; Fri, 13 Jun 2014 11:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xPw6hXq5_CSX for ; Fri, 13 Jun 2014 11:42:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F031A01F3 for ; Fri, 13 Jun 2014 11:42:20 -0700 (PDT) Received: from [172.29.6.121] (66.129.239.13) by BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) with Microsoft SMTP Server (TLS) id 15.0.959.24; Fri, 13 Jun 2014 18:42:17 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <20140613183222.27662.91400.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 14:42:10 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <48D0139F-CD0E-474C-A557-E18E6100157A@juniper.net> References: <20140613183222.27662.91400.idtracker@ietfa.amsl.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.239.13] X-ClientProxiedBy: BY2PR07CA075.namprd07.prod.outlook.com (10.141.251.50) To BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0241D5F98C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(51704005)(199002)(189002)(24454002)(377454003)(377424004)(83072002)(15975445006)(15202345003)(88136002)(81342001)(4396001)(19580395003)(21056001)(83322001)(93916002)(74502001)(19580405001)(42186004)(62966002)(86362001)(92566001)(46406003)(83716003)(104166001)(31966008)(57306001)(74662001)(79102001)(105586001)(66066001)(76482001)(77982001)(81542001)(46102001)(89996001)(80022001)(50226001)(87286001)(97756001)(64706001)(23726002)(47776003)(87976001)(20776003)(33656002)(36756003)(50466002)(76176999)(85852003)(50986999)(82746002)(92726001)(102836001)(99396002)(77156001)(101416001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB721; H:[172.29.6.121]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/tCGt8lAMLE9vTpb4mOynG5Bpb6k Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:42:23 -0000 This version incorporates Eric, Deniz and Adam's recent comments. I'd be particularly interested in thoughts as to whether it would be OK = to soften the error-handling approach for the TE attribute to "attribute = discard". Frankly, I just threw "treat-as-withdraw" in there since it's = the default choice. --John On Jun 13, 2014, at 2:32 PM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Revised Error Handling for BGP UPDATE = Messages > Authors : Enke Chen > John G. Scudder > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-13.txt > Pages : 18 > Date : 2014-06-13 >=20 > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not = only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for a number of existing attributes. >=20 > This document updates error handling for RFCs 1997, 4271, 4360, = 4456, > 4760, 5543, 5701, 6368 and 6790. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-13 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 13 12:15:48 2014 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 BD8601B29E8 for ; Fri, 13 Jun 2014 12:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKnvVy9P6-bh for ; Fri, 13 Jun 2014 12:15:46 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7761B27BB for ; Fri, 13 Jun 2014 12:15:45 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id rl12so2886899iec.11 for ; Fri, 13 Jun 2014 12:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wqMWvwGiyBgzghVIWz9tn7nZsn2UDspXP410WmXGXao=; b=04hjhZGvL/0TLVJeTzPchQZtNVvCr7inwlsnCL5WguDNNw3w6OOKC2W0XROW2KCEq+ vTE/twAEdNix0m7snXwoq1wM5fCd+B+OM5duVfpDLy3XgDpTCEQiWm/IlN9okiX5BjND 6DAoSjGfGb0ZAzrLX4FDXF5K/Hdn7QBeCpsNJ2/Gt52hNforEXLxiS4vCdhySGtizFf/ 21VrG4Wu20rHxtXVX9L3zt8Sx/tsKl7AiUqZtd5pF2kXgnQOiFeLWYJn/fiP21DxzrCC mc6g+HCPR52tRYFLaj/NYnKVo0fX372rkR/NVEf3hPJdICmaoDeFxOKvdYW/gN4qvUJx 294A== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr7281204igb.21.1402686945344; Fri, 13 Jun 2014 12:15:45 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 13 Jun 2014 12:15:45 -0700 (PDT) In-Reply-To: <48D0139F-CD0E-474C-A557-E18E6100157A@juniper.net> References: <20140613183222.27662.91400.idtracker@ietfa.amsl.com> <48D0139F-CD0E-474C-A557-E18E6100157A@juniper.net> Date: Fri, 13 Jun 2014 21:15:45 +0200 X-Google-Sender-Auth: 7vMvN3hzuoerecoW_vwF7WMHW6A Message-ID: From: Robert Raszuk To: "John G. Scudder" , "erosen@cisco.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/bNeDHFto9UjLr9foffazMVu8QMg Cc: "idr@ietf. org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 19:15:46 -0000 John, Eric, I am not too happy with the updated section 7.11. Not that the update was wrong, but it seems incomplete. You now precisely provide definition of "valid host address" It says ... o If the Next Hop field contains an IPv4 address (possibly as a sub- ... o If the Next Hop field contains an IPv6 address (possibly as a sub- ... o If the Next Hop field contains an IPv4-mapped IPv6 address ... o If the Next Hop field is some other form of address, it should be considered invalid. However let's observe that we do have RFC5575 where there is no need to neither carry NEXT HOP ATTRIBUTE nor have it as part of MP_REACH_NLRI (length 0) Quote from RFC 5575 section 4: Whenever the corresponding application does not require Next-Hop information, this shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI attribute and ignored on receipt. Therefor if an implementation would take current text of the draft very serious it may consider all flow-spec MP_REACH_NLRI attributes as invalid. I would therefor propose to modify the current section 7.11 accordingly: consider what it means for the Next Hop field of the MP_REACH attribute to be a "valid host address" unless it is of 0-octet length: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Regards, R. From nobody Fri Jun 13 13:18:09 2014 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 D88EA1A023A; Fri, 13 Jun 2014 13:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 n5OiDnDMUhFc; Fri, 13 Jun 2014 13:18:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 453F41B2A20; Fri, 13 Jun 2014 13:18:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613201804.32294.52821.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 13:18:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/bCeTPshY_v_dUM4-S__b_kvPSfE Cc: idr mailing list , idr chair , RFC Editor Subject: [Idr] Protocol Action: 'Enhanced Route Refresh Capability for BGP-4' to Proposed Standard (draft-ietf-idr-bgp-enhanced-route-refresh-10.txt) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 20:18:07 -0000 The IESG has approved the following document: - 'Enhanced Route Refresh Capability for BGP-4' (draft-ietf-idr-bgp-enhanced-route-refresh-10.txt) as Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh/ Technical Summary In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP RIB inconsistencies in a non-disruptive manner. Working Group Summary WG discussion was extremely active and produced changes that were fed back into the implementations of 3 router vendors. Document Quality Debate provided good feedback and refinement for 3 implementations. 2 Implementations (Cisco and NTT I3) are described the implementation report: http://tools.ietf.org/html/draft-ietf-idr-enhanced-refresh-impl-00 Personnel Document shepherd: Susan Hares Responsible AD: Alia Atlas IANA Note IANA is requested to modify the name of a registry at http://www.iana.org/assignments/bgp-parameters/ OLD: BGP Error Codes NEW: BGP Error (Notification) Codes From nobody Sat Jun 14 00:07:09 2014 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 1D42A1B2B92 for ; Sat, 14 Jun 2014 00:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 gR92jWV-Zr9F for ; Sat, 14 Jun 2014 00:07:06 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7E61B2B89 for ; Sat, 14 Jun 2014 00:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2956; q=dns/txt; s=iport; t=1402729626; x=1403939226; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SYZM77k1kTCS03tVd7UwByJakFYZy0fE4X7iXFkQSsw=; b=JNd4i1e1PMTsHlUQyx9UARdWoPzm/vIWHgeaCNNqSKbdu8NtD4kn8w12 R6OEn1913/gF4pG5diGbPjROGqw0Gaxjbd5LWiFmgnZm7mpKzKwbXvz7E Przezvk3TG6i4D9KU7m9O9rGm0AeoiBM6OW5Zb0tRtE9BVRfdodiNg4RI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFALbzm1OtJV2U/2dsb2JhbABagw1SWalkAQEBAQEHkWWHPQGBAhZ1hAMBAQEDAQEBARodNAsSAQgYHjcLJQIEAQ0FFIgmCA3PZRMEhV2FZII8EQEOQgeEQQSaPZNYgX2BQYFwBxcGHA X-IronPort-AV: E=Sophos;i="5.01,476,1400025600"; d="scan'208";a="52983487" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP; 14 Jun 2014 07:07:06 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5E775v3026129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 14 Jun 2014 07:07:05 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.72]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Sat, 14 Jun 2014 02:07:05 -0500 From: "Keyur Patel (keyupate)" To: "bruno.decraene@orange.com" , Robert Raszuk , Randy Bush Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPh58/Oi4vUxQoyUumRHha7cuMKg== Date: Sat, 14 Jun 2014 07:07:04 +0000 Message-ID: In-Reply-To: <11288_1402650149_539ABE25_11288_1186_5_53C29892C857584299CBF5D05346208A07162986@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.88.173] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D19849D994F244EBDFF0D3309D35FC3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AvUFCwBEwWiSEFkeRMisnWCvPS4 Cc: idr wg , Susan Hares , "John G. Scudder" Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 14 Jun 2014 07:07:08 -0000 Hi Bruno, On 6/13/14 2:02 AM, "bruno.decraene@orange.com" wrote: >> > Validity state signaling SHOULD NOT be accepted from a neighbor AS. >>=20 >> I would agree > >I agree on the goal. >Now the question is how do you protect from this, if you're unstrusted >neighbor AS send this community over eBGP session. I suggest we log an error and drop the community. Regards, Keyur > >> + also add that setting this extended community by manual >> EBGP policy should NOT be supported. > >IMO adding the text "The sender should not do that" is not a very strong >protection. Otherwise, we would not need any crypto signature. (e.g. you >should not originate a BGP route if you are not the true originator). >You can add the check on the receiver side, but this would now require >that all ASBR be upgraded to support this new community, before it could >be used. If this is the chosen path, it should be written in the draft in >the deployment consideration section >=20 >> The above along with the fact that this is already non-transitive in >>the AS >> scope should solve that worry completely. > >Not yet. >=20 >> r. >>=20 >> On Fri, Jun 13, 2014 at 4:12 AM, Randy Bush wrote: >> >> #Keyur: Ideally, the usage of this community should NOT be encouraged >> >> #across inter-as boundaries. We can add necessary text to reflect >> >> #that part. >> > >> > from rfc 7115, end of sec 5 >> > >> > Validity state signaling SHOULD NOT be accepted from a neighbor AS. >> > The validity state of a received announcement has only local scope >> > due to issues such as scope of trust, RPKI synchrony, and >>management >> > of local trust anchors [LTA-USE]. >> > >> > randy >> > >> > _______________________________________________ >> > Idr mailing list >> > Idr@ietf.org >> > https://www.ietf.org/mailman/listinfo/idr >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > From nobody Sat Jun 14 07:45:53 2014 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 CBBE51B2920 for ; Sat, 14 Jun 2014 07:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1co7_sVywXX for ; Sat, 14 Jun 2014 07:45:38 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CEA1B2910 for ; Sat, 14 Jun 2014 07:45:30 -0700 (PDT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WvpCy-0005gr-4o for idr@ietf.org; Sat, 14 Jun 2014 14:45:28 +0000 From: "Chris Hall" To: "'idr@ietf. org'" References: <20140613183222.27662.91400.idtracker@ietfa.amsl.com> <48D0139F-CD0E-474C-A557-E18E6100157A@juniper.net> In-Reply-To: Date: Sat, 14 Jun 2014 15:45:22 +0100 Organization: Highwayman Message-ID: <009f01cf87df$48630760$d9291620$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 thread-index: AQJXjkKBWtNg6j4xdnquExntuI8nmQJ70ufhAUdSOjCaQm0sAA== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/dNtCd_YhBQ9ej_LwiN6QUSjR29c Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 14:45:42 -0000 Robert Raszuk wrote (on Fri 13-Jun-2014 at 20:16 +0100): .... > You now precisely provide definition of "valid host address" It says .... > Therefor if an implementation would take current text of the draft > very serious it may consider all flow-spec MP_REACH_NLRI attributes > as invalid. .... I have a feeling that defining "valid host address" is more trouble than it is worth. The draft has, as far as I can see, by stages ended up as: "on any error do treat-as-withdraw, unless the error affects Parsing of NLRI (do session-reset), or unless the error is trivial (do attribute-discard)" The upshot is that errors can be classified as "venial" (treat-as-withdraw), "mortal" (session-reset) and "trivial" (attribute-discard) -- where, unless otherwise specified, an error is implicitly "venial". (IMHO anyone contemplating attribute-discard is in a state of sin, and the whole thing would be made simpler by placing that vanity on the nearest bonfire. But that's another story.) It really doesn't matter why a given next-hop is invalid or unusable or nonsense or otherwise no more use than a chocolate teapot: all next-hop errors are venial errors. So the draft doesn't, AFAICS, need to get sucked into defining "valid host address". (RFC4271 goes some way to distinguish the handling of syntactically and semantically incorrect NEXT_HOP attribute -- the father of treat-as-withdraw, perhaps. But that distinction is rendered irrelevant by this draft.) UNLESS, that is, there are next-hop errors which should be deemed mortal. The NEXT_HOP attribute can be completely broken without affecting the Parsing of NLRI. But for MP_REACH_NLRI: (1) noting that (a) the draft treats invalid prefix lengths as mortal errors, because they cast doubt on the Parsing of NLRI... ...and that (b) in an MP_REACH_NLRI, the start of the NLRI is given by the next-hop-length.... ...is an invalid next-hop-length a mortal error ? (2) some Next-Hop values could be deemed "nonsense", meaning that their presence should be considered a symptom of a much more serious underlying error, so... ...are there any Next-Hop values that should be deemed mortal errors ? Chris From nobody Sat Jun 14 09:57:21 2014 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 B663A1A0522; Sat, 14 Jun 2014 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nrCruisPeUja; Sat, 14 Jun 2014 09:57:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D081B2884; Sat, 14 Jun 2014 09:57:11 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4B3BC2AC5E7; Sat, 14 Jun 2014 18:57:09 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 282CD15804E; Sat, 14 Jun 2014 18:57:09 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Sat, 14 Jun 2014 18:57:08 +0200 From: To: "Keyur Patel (keyupate)" Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPh58/B/uGL+YYM0KA0B8arly+15tw0zlw Date: Sat, 14 Jun 2014 16:57:08 +0000 Message-ID: <30320_1402765029_539C7EE5_30320_2004_1_53C29892C857584299CBF5D05346208A07162EB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <11288_1402650149_539ABE25_11288_1186_5_53C29892C857584299CBF5D05346208A07162986@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.4.22118 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/tP-mS173SfWhQhdXWV4Wd0nu9RU Cc: idr wg , "sidr@ietf.org list" Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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, 14 Jun 2014 16:57:15 -0000 Hi Keyur, > From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > Sent: Saturday= , June 14, 2014 9:07 AM >=20 > Hi Bruno, >=20 >=20 > On 6/13/14 2:02 AM, "bruno.decraene@orange.com" > wrote: >=20 > >> > Validity state signaling SHOULD NOT be accepted from a neighbor AS. > >> > >> I would agree > > > >I agree on the goal. > >Now the question is how do you protect from this, if you're unstrusted > >neighbor AS send this community over eBGP session. >=20 >=20 > I suggest we log an error and drop the community. Looks good. Could you please add this in the draft? Thanks. Bruno >=20 > Regards, > Keyur >=20 > > > >> + also add that setting this extended community by manual > >> EBGP policy should NOT be supported. > > > >IMO adding the text "The sender should not do that" is not a very > >strong protection. Otherwise, we would not need any crypto signature. > >(e.g. you should not originate a BGP route if you are not the true > originator). > >You can add the check on the receiver side, but this would now require > >that all ASBR be upgraded to support this new community, before it > >could be used. If this is the chosen path, it should be written in the > >draft in the deployment consideration section > > > >> The above along with the fact that this is already non-transitive in > >>the AS scope should solve that worry completely. > > > >Not yet. > > > >> r. > >> > >> On Fri, Jun 13, 2014 at 4:12 AM, Randy Bush wrote: > >> >> #Keyur: Ideally, the usage of this community should NOT be > >> >> encouraged #across inter-as boundaries. We can add necessary text > >> >> to reflect #that part. > >> > > >> > from rfc 7115, end of sec 5 > >> > > >> > Validity state signaling SHOULD NOT be accepted from a neighbor A= S. > >> > The validity state of a received announcement has only local scope > >> > due to issues such as scope of trust, RPKI synchrony, and > >>management > >> > of local trust anchors [LTA-USE]. > >> > > >> > randy > >> > > >> > _______________________________________________ > >> > Idr mailing list > >> > Idr@ietf.org > >> > https://www.ietf.org/mailman/listinfo/idr > >_________________________________________________________ > ______________ > >___ _______________________________________________ > > > >Ce message et ses pieces jointes peuvent contenir des informations > >confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >exploites ou copies sans autorisation. Si vous avez recu ce message par > >erreur, veuillez le signaler a l'expediteur et le detruire ainsi que > >les pieces jointes. Les messages electroniques etant susceptibles > >d'alteration, Orange decline toute responsabilite si ce message a ete > >altere, deforme ou falsifie. Merci. > > > >This message and its attachments may contain confidential or privileged > >information that may be protected by law; they should not be > >distributed, used or copied without authorisation. > >If you have received this email in error, please notify the sender and > >delete this message and its attachments. > >As emails may be altered, Orange is not liable for messages that have > >been modified, changed or falsified. > >Thank you. > > ___________________________________________________________________________= ______________________________________________ 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 Sat Jun 14 18:00:41 2014 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 35A891B2A52; Sat, 14 Jun 2014 18:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 Ew878Y2rAtP0; Sat, 14 Jun 2014 18:00:35 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BBE31B2A4A; Sat, 14 Jun 2014 18:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4576; q=dns/txt; s=iport; t=1402794035; x=1404003635; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cWVcOSV6yIT4ewHREEWYuIyNUB/R6jVGN2UUvwGZ0o8=; b=HyJd1zrUGGaoc8EdmvbvvPrLbhM0270BJGrQxCLKFTuMfF1tzKG+Q9pf i+HWVU+gSptJiNZfjii1bLOLxi3CL9vKeyaX08UP3ku1uC13yupTFMQ/Q RaHf9IkP9EWVCQ+kL2W9DnW13nQxBpnzC2uZ0jR6zDcOHxXgjLYsR+EZE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FABXwnFOtJA2M/2dsb2JhbABagw1SWqlnAQEBAQEHkWeHPQGBAxZ1hAMBAQEEAQEBGh00CxIBCBUBAh4JLgsUEQIEDgUUiC4NzzATBIVjhXSCPREBDkIHhEMEmkOTWIF+gUKBcAcXBhw X-IronPort-AV: E=Sophos;i="5.01,479,1400025600"; d="scan'208";a="330068751" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 15 Jun 2014 01:00:17 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5F10HAU022664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Jun 2014 01:00:17 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.78]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Sat, 14 Jun 2014 20:00:17 -0500 From: "Keyur Patel (keyupate)" To: "bruno.decraene@orange.com" Thread-Topic: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Thread-Index: AQHPh58/B/uGL+YYM0KA0B8arly+15tw0zlwgABpi4A= Date: Sun, 15 Jun 2014 01:00:16 +0000 Message-ID: In-Reply-To: <30320_1402765029_539C7EE5_30320_2004_1_53C29892C857584299CBF5D05346208A07162EB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.89.142] Content-Type: text/plain; charset="us-ascii" Content-ID: <95BA9A48EF52184ABAD4F8028BB174BB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/q0DdvsdnHfhA_UBmscyikHzEeIw Cc: idr wg , "sidr@ietf.org list" Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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: Sun, 15 Jun 2014 01:00:37 -0000 Hi Bruno, On 6/14/14 9:57 AM, "bruno.decraene@orange.com" wrote: >Hi Keyur, > >> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > Sent: >>Saturday, June 14, 2014 9:07 AM >>=20 >> Hi Bruno, >>=20 >>=20 >> On 6/13/14 2:02 AM, "bruno.decraene@orange.com" >> wrote: >>=20 >> >> > Validity state signaling SHOULD NOT be accepted from a neighbor AS. >> >> >> >> I would agree >> > >> >I agree on the goal. >> >Now the question is how do you protect from this, if you're unstrusted >> >neighbor AS send this community over eBGP session. >>=20 >>=20 >> I suggest we log an error and drop the community. > >Looks good. Could you please add this in the draft? Sure. Regards, Keyur > >Thanks. >Bruno > >>=20 >> Regards, >> Keyur >>=20 >> > >> >> + also add that setting this extended community by manual >> >> EBGP policy should NOT be supported. >> > >> >IMO adding the text "The sender should not do that" is not a very >> >strong protection. Otherwise, we would not need any crypto signature. >> >(e.g. you should not originate a BGP route if you are not the true >> originator). >> >You can add the check on the receiver side, but this would now require >> >that all ASBR be upgraded to support this new community, before it >> >could be used. If this is the chosen path, it should be written in the >> >draft in the deployment consideration section >> > >> >> The above along with the fact that this is already non-transitive in >> >>the AS scope should solve that worry completely. >> > >> >Not yet. >> > >> >> r. >> >> >> >> On Fri, Jun 13, 2014 at 4:12 AM, Randy Bush wrote: >> >> >> #Keyur: Ideally, the usage of this community should NOT be >> >> >> encouraged #across inter-as boundaries. We can add necessary text >> >> >> to reflect #that part. >> >> > >> >> > from rfc 7115, end of sec 5 >> >> > >> >> > Validity state signaling SHOULD NOT be accepted from a neighbor >>AS. >> >> > The validity state of a received announcement has only local >>scope >> >> > due to issues such as scope of trust, RPKI synchrony, and >> >>management >> >> > of local trust anchors [LTA-USE]. >> >> > >> >> > randy >> >> > >> >> > _______________________________________________ >> >> > Idr mailing list >> >> > Idr@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/idr >> >_________________________________________________________ >> ______________ >> >___ _______________________________________________ >> > >> >Ce message et ses pieces jointes peuvent contenir des informations >> >confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> >exploites ou copies sans autorisation. Si vous avez recu ce message par >> >erreur, veuillez le signaler a l'expediteur et le detruire ainsi que >> >les pieces jointes. Les messages electroniques etant susceptibles >> >d'alteration, Orange decline toute responsabilite si ce message a ete >> >altere, deforme ou falsifie. Merci. >> > >> >This message and its attachments may contain confidential or privileged >> >information that may be protected by law; they should not be >> >distributed, used or copied without authorisation. >> >If you have received this email in error, please notify the sender and >> >delete this message and its attachments. >> >As emails may be altered, Orange is not liable for messages that have >> >been modified, changed or falsified. >> >Thank you. >> > > > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > From nobody Sun Jun 15 20:22:25 2014 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 915431B2A22 for ; Sun, 15 Jun 2014 20:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 zDVCYivu9XE9 for ; Sun, 15 Jun 2014 20:22:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DCC1B2A1F for ; Sun, 15 Jun 2014 20:22:19 -0700 (PDT) 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 BFL16950; Mon, 16 Jun 2014 03:22:18 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Jun 2014 04:22:17 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 16 Jun 2014 11:22:10 +0800 From: "Dongjie (Jimmy)" To: "erosen@cisco.com" , "John G. Scudder" Thread-Topic: [Idr] RFC 4684 pedantry - routes with no Route Target Thread-Index: AQHPfAfCSdt6mgQZTkKmeoaf0TXRm5tzJsXg Date: Mon, 16 Jun 2014 03:22:09 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273367B9D0@nkgeml512-mbx.china.huawei.com> References: Your message of Thu, 29 May 2014 14:20:50 -0400. <25B13537-15F0-4994-8504-C04FF94C72C3@juniper.net> <13330.1401455098@erosen-lnx> In-Reply-To: <13330.1401455098@erosen-lnx> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ylAU3fM1hXpPkNIEeAWTlSlD5PI Cc: "idr@ietf.org" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 03:22:21 -0000 Hi Eric,=20 Some of my thoughts about this discussion: > I think everyone agrees that it should be possible to enable RTC on a par= ticular > AFI/SAFI, while allowing "RT-less routes" (routes with no RTs) of that AF= I/SAFI to > be distributed. In my understanding, this implies two things:=20 1) RTC could be enabled on a particular AFI/SAFI; 2) RTC processing for different AFI/SAFIs could be different; While currently RTC is a global capability, which cannot be enabled on a pa= rticular AFI/SAFI only, either cannot behave differently for different AFI/= SAFIs. So can I infer that you prefer to make RTC a AFI/SAFI specific capab= ility? Best regards, Jie From nobody Sun Jun 15 20:51:44 2014 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 BB62D1B2BF1 for ; Sun, 15 Jun 2014 20:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 tSUG4aIdhDLz for ; Sun, 15 Jun 2014 20:51:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC991B29A8 for ; Sun, 15 Jun 2014 20:51:40 -0700 (PDT) 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 BIL33657; Mon, 16 Jun 2014 03:51:38 +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.158.1; Mon, 16 Jun 2014 04:51:38 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 16 Jun 2014 11:51:34 +0800 From: "Dongjie (Jimmy)" To: Jeffrey Haas , Robert Raszuk Thread-Topic: [Idr] RFC 4684 pedantry - routes with no Route Target Thread-Index: AQHPdQhfSdt6mgQZTkKmeoaf0TXRm5tKsR4AgAAETYCAAACwgIAAAgWAgBZCFoCAEkASsA== Date: Mon, 16 Jun 2014 03:51:33 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273367B9FE@nkgeml512-mbx.china.huawei.com> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521163621.GF9789@pfrc> <20140604204017.GB13606@pfrc> In-Reply-To: <20140604204017.GB13606@pfrc> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/abiPDCqR1_3C6ckAckPj6A7twjc Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 03:51:42 -0000 Hi Jeff,=20 > This suggests the behavior we want may be: > - Permit a per-peer, per-AFI/SAFI knob to enable/disable RT-C processing. > JUNOS, e.g., filters VPN families by default. Agree that this way we can solve some problem without modifying the RTC pro= tocol, a.k.a backward compatibility is maintained. > - Provide for exceptions to the rule and document them. > That second point covers the MDT scenario. It also suggests that IDR sho= uld > probably make sure the other WGs using BGP as a transport for their VPNs = or > otherwise using RTs should be reminded that RT-C exists and their extensi= ons > had best document their interaction with it if they inconsistently RT tag= their > routes. Fully agree that for different VPNs which may use RTC, the possible interac= tion and extensions should be documented somewhere. Then RFC 4684 may need = to be updated by many newly defined VPN specifications. This reminds me of the MP-BGP (RFC 4760), which keeps stable while can supp= ort lots of new VPNs. I'm thinking whether we should make RTC a scalable an= d stable mechanism in a similar way. Thoughts? Best regards, Jie From nobody Mon Jun 16 01:28:43 2014 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 9772D1B2B95 for ; Mon, 16 Jun 2014 01:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlt5ZuPLf5K9 for ; Mon, 16 Jun 2014 01:28:29 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0E81B2B9D for ; Mon, 16 Jun 2014 01:28:29 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id tp5so4733359ieb.34 for ; Mon, 16 Jun 2014 01:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eLRYWGc3BdzuUJbr4FYcIXSTyYeC8wBG/u6YshHRoZM=; b=LOYLFgQn4V4LI1jHwGjAD2NDyi7aG+wBW9sipAOQblPlU7QkpXGsrdKwTzcatIHjhT IEONfJmxAfZ3rerpQEzHAZng/rDS3naESybHnoP7ZCBr6whGHhR58+YAcjJ1HxCKuR1i Brr4zG70t0mgYfAg0tOgzzAV0kwnRonUsxCskviQ7URVbzCYa+tiiWTLLpq22eO7ESpZ /dOHVjhYP9vKH77paZBGDdLIx5zYqSPehnEujIx5kxFsqglLeQv3L+A9JKGZUOAgQChF Qapuj/Qrx0DMMnAc/f8gS3jgA8bv9fFn64VliP2UC17kbUw3TATtFUp1/WwMa4nT4tlm 9gmg== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr23847410igb.21.1402907308487; Mon, 16 Jun 2014 01:28:28 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 16 Jun 2014 01:28:28 -0700 (PDT) In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273367B9D0@nkgeml512-mbx.china.huawei.com> References: <25B13537-15F0-4994-8504-C04FF94C72C3@juniper.net> <13330.1401455098@erosen-lnx> <76CD132C3ADEF848BD84D028D243C9273367B9D0@nkgeml512-mbx.china.huawei.com> Date: Mon, 16 Jun 2014 10:28:28 +0200 X-Google-Sender-Auth: k7VH6CTB5n3e2UCfNiaJkpIK88c Message-ID: From: Robert Raszuk To: "Dongjie (Jimmy)" Content-Type: multipart/alternative; boundary=089e013a0c68c67a3604fbefcf06 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/MEb1Cw0ad09v1aeI1hxsdsGtzio Cc: "erosen@cisco.com" , "idr@ietf.org" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 08:28:33 -0000 --089e013a0c68c67a3604fbefcf06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jie, In my understanding, this implies two things: > > 1) RTC could be enabled on a particular AFI/SAFI; > =E2=80=8BYes.=E2=80=8B > 2) RTC processing for different AFI/SAFIs could be different; > =E2=80=8BNo.=E2=80=8B > While currently RTC is a global capability, which cannot be enabled on a > particular AFI/SAFI only, =E2=80=8BOf course we can - why not ? To send RTs and to process them requi= res a command on a per AF basis. =E2=80=8B > either cannot behave differently for different AFI/SAFIs. =E2=80=8BThat was never subject of this discussion. It's completely separat= e change which does require changes to base spec.=E2=80=8B So can I infer that you prefer to make RTC a AFI/SAFI specific capability? > =E2=80=8BThat was also never part of this topic. I would recommend to separate the discussion into specifying =E2=80=8Bthe d= efault behavior for routes with no RTs while separately discuss changes to base RFC to make it per AFI/SAFI (provided there is community support for such major rewrite). Best, R. --089e013a0c68c67a3604fbefcf06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jie,

In my understanding, this implies two things:

=C2=A01) RTC could be enabled on a particular AFI/SAFI;

=E2=80=8BYes.=E2=80=8B
=
=C2=A0
=C2=A02) RTC processing for different AFI/SAFIs could be different;

=E2=80=8BNo.=E2=80=8B<= /div>
=C2=A0
While currently RTC is a glo= bal capability, which cannot be enabled on a particular AFI/SAFI only,


=E2=80=8BOf cour= se we can - why not ? To send RTs and to process them requires a command on= a per AF basis. =E2=80=8B

=C2=A0
ei= ther cannot behave differently for different AFI/SAFIs.
<= br>
=E2=80=8BThat was never subject of this discus= sion. It's completely separate change which does require changes to bas= e spec.=E2=80=8B


So can I infer that you prefer to make RTC a AFI/SAFI specific capability?<= br>

=E2=80=8BThat w= as also never part of this topic.=C2=A0

I would recommend= to separate the discussion into specifying =E2=80=8Bthe default behavior f= or routes with no RTs while separately discuss changes to base RFC to make = it per AFI/SAFI (provided there is community support for such major rewrite= ).=C2=A0

Best,
R.


--089e013a0c68c67a3604fbefcf06-- From nobody Mon Jun 16 07:24:24 2014 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 3A9DB1A0035 for ; Mon, 16 Jun 2014 07:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 LcSwEJZr7r2E for ; Mon, 16 Jun 2014 07:24:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178BA1A002B for ; Mon, 16 Jun 2014 07:24:17 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id E4AADC09B4; Mon, 16 Jun 2014 16:24:14 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id CB9CD384066; Mon, 16 Jun 2014 16:24:14 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 16 Jun 2014 16:24:14 +0200 From: To: Susan Hares , "'John G. Scudder'" Thread-Topic: [Idr] WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14 Thread-Index: Ac95z8QWQFsTe791Q6yxUrmTxDTYYgPk0LXQ Date: Mon, 16 Jun 2014 14:24:13 +0000 Message-ID: <462_1402928654_539EFE0E_462_2820_6_53C29892C857584299CBF5D05346208A07163323@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com> In-Reply-To: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A07163323PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.16.93030 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/LvMBKp60dddLTSeAyJSoSVX_eKQ Cc: idr wg Subject: Re: [Idr] WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:24:22 -0000 --_000_53C29892C857584299CBF5D05346208A07163323PEXCVZYM11corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Read and support. 1) "1. Introduction [...] This is also true for HOLDTIME expiration" IMHO this is a significant point that could be added in the Abstract. e.g. OLD: when the BGP speaker receives a BGP NOTIFICATION Message NEW: when the BGP speaker receives a BGP NOTIFICATION Message or the HOLDTI= ME expires. In particular, if the BGP speaker is down, the upper bound to keep BGP rout= es is increased. IHMO this should be indicated in a new deployment consider= ation section. Also it's not very clear how long the routes are kept. I guess HOLDTIME + "= the possible local unnamed timer at the end of RFC 4724 section 4.2". If th= is is a case, this timer should probably be given an name and become a MUST= to implement (it's a MAY in RFC 4271) -- 3) " Flags for Address Family: This field contains bit flags relating to routes that were advertised with the given AFI and SAFI. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|N| Reserved | +-+-+-+-+-+-+-+-+ The usage of second most significant bit "N" is deprecated. This bit MUST be advertised as 0 and MUST be ignored upon receipt." IMHO the above text could be deleted from the document. (IINM, this flag "N= " has been tentatively defined in earlier version of _this_ draft. When thi= s docs becomes RFC, there is nothing the deprecate has this flag would have= never been specified) -- =A7 4. Operation A BGP speaker that is willing to receive and send BGP NOTIFICATION messages in Graceful mode MUST advertise the BGP Graceful Notification Flag "N" using the Graceful Restart Capability as defined in [RFC4724]. When such a BGP Speaker receives a BGP NOTIFICATION message other than a Hard Reset, it MUST follow the rules for the Receiving Speaker mentioned in Section 4.1. Between both sentences, IMHO a text is missing stating that this new behavi= or is only activated when both speakers advertised flag "N". With current s= econd sentence, only the sending of this N flag would be enough to trigger = the new behavior. =A74.1 Rules for the Receiving Speaker I don't find particularly easy to red no clear this section 4.1 which is tr= ying to patch section 4.2 of RFC4274. e.g. " As part of this extension, routes from the peer previously marked as stale MUST NOT be deleted, until and unless the timer mentioned in the final paragraph of [RFC4724] S. = 4.2 expires, or unless a Hard Reset is performed. =BB - So the STALE routes are not deleted when I received an End-of-RIB marker?= ? (I know the answer but it's not crystal clear what exactly the above sent= ence overwrite) As an alternative, the whole RFC 4724 s4.2 could be copied and updated as n= eeded. Or the OLD/NEW deliminater could be used to indicate what is removed= and what is added. - Also it's not clear whether these modifications only apply to GR triggere= d by NOTIFICATION/HOLDTIME expiration or by "regular" (RFC 4274) GR cases. --- Nits (IMHO) : OLD: If a Hard Reset is used, a full session reset is performed. NEW: If a Hard Reset is used, a session reset is performed as per RFC 4271. OLD: A new BGP NOTIFICATION Cease message subcode is defined known as the= BGP Hard Reset Subcode. NEW: A new BGP NOTIFICATION Cease message subcode called "BGP Hard Reset Su= bcode" is defined. Thanks, Best regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, May 27, 2014 7:19 PM To: idr wg Cc: 'John G. Scudder' Subject: [Idr] WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/= 14 to 6/10/14 Working Group, This is to begin a 2 week WG LC for draft-ietf-idr-bgp-gr-notification-02.t= xt which will end on 6/10/2014. Please put within your comments: "support= " or "no-support" for WG LC. Jeff Haas comments that the most recent changes reflect implementation expe= rience and some word smithing. There is also a minor clarification in the = NOTIFICATION message with respect to including a data byte so the original = reason for the event can be propagated. (See sec. 3.1 in the diff.) The abstract is below. Sue Hares ---------- Abstract: The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A07163323PEXCVZYM11corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

Read an= d support.

&n= bsp;

1)=

“= 1. Introduction

[…= ;]

This is also true for HOLDTIME expiration&#= 8221;

&n= bsp;

IMHO th= is is a significant point that could be added in the Abstract.

e.g.

OLD:  when t=
he BGP speaker receives a BGP NOTIFICATION Message
NEW: when the BGP=
 speaker receives a BGP NOTIFICATION Message or the HOLDTIME expires.<=
/o:p>

&n= bsp;

&n= bsp;

In part= icular, if the BGP speaker is down, the upper bound to keep BGP routes is i= ncreased. IHMO this should be indicated in a new deployment consideration s= ection.

Also it= ’s not very clear how long the routes are kept. I guess HOLDTIME += ; “the possible local unnamed timer at the end of RFC 4724 section 4.= 2”. If this is a case, this timer should probably be given an name and become a MUST to implement (it’s a MAY in RFC 4271)=

--

 

3)

“  Flags for Address Family:

 

       &= nbsp;    This field contains bit flags relating to routes th= at were

       &= nbsp;    advertised with the given AFI and SAFI.<= /span>

 

       &= nbsp;        0 1 2 3 4 5 6 7<= /span>

       &= nbsp;       +-+-+-+-+-= 3;-+-+-+

       &= nbsp;       |F|N| Reserved  |=

       &= nbsp;       +-+-+-+-+-= 3;-+-+-+

 

   The usage of second most signi= ficant bit "N" is deprecated.  This bit

   MUST be advertised as 0 and MU= ST be ignored upon receipt.”

&n= bsp;

IMHO th= e above text could be deleted from the document. (IINM, this flag “N&= #8221; has been tentatively defined in earlier version of _this_ dra= ft. When this docs becomes RFC, there is nothing the deprecate has this flag would have never been specified)=

&n= bsp;

--

=A7 4. = Operation

   A BGP speaker that is willing = to receive and send BGP NOTIFICATION

   messages in Graceful mode MUST= advertise the BGP Graceful

   Notification Flag "N"= ; using the Graceful Restart Capability as

   defined in [RFC4724].<= /o:p>

 

   When such a BGP Speaker receiv= es a BGP NOTIFICATION message other

   than a Hard Reset, it MUST fol= low the rules for the Receiving Speaker

   mentioned in Section 4.1.

&n= bsp;

Between= both sentences, IMHO a text is missing stating that this new behavior is o= nly activated when both speakers advertised flag “N”. With curr= ent second sentence, only the sending of this N flag would be enough to trigger the new behavior.

&n= bsp;

=A74.1<= /span>  Rules for the Rec= eiving Speaker

I don&#= 8217;t find particularly easy to red no clear this section 4.1 which is try= ing to patch section 4.2 of RFC4274.

e.g. “ As p=
art of this extension, routes from the peer previously marked as=

   stale MUST NOT be deleted, unt= il and unless the timer mentioned in

   the final paragraph of [RFC4724] S. 4.2 expires, or unless a Hard

   Reset is performed. =BB

&n= bsp;

- So th= e STALE routes are not deleted when I received an End-of-RIB marker?? (I kn= ow the answer but it’s not crystal clear what exactly the above sente= nce overwrite)

As an a= lternative, the whole RFC 4724 s4.2 could be copied and updated as needed. = Or the OLD/NEW deliminater could be used to indicate what is removed and wh= at is added.

&n= bsp;

- Also = it’s not clear whether these modifications only apply to GR triggered= by NOTIFICATION/HOLDTIME expiration or by “regular” (RFC 4274)= GR cases.

---

Nits (I= MHO) :

 
OLD: If a Hard Re=
set is used, a full session reset is performed.

NEW: If a Hard Re=
set is used, a session reset is performed as per RFC 4271.


&n=
bsp;


OLD:   =
A new BGP NOTIFICATION Cease message subcode is defined known as the=
 BGP Hard Reset Subcode.


NEW: A new BGP NOTIFICATION Cease message subcode called “BG=
P Hard Reset Subcode” is defined.


&n=
bsp;


Thanks,=



Best re=
gards,


Bruno


&n=
bsp;








From: Idr [mailto:idr-bounces@ietf.org]
On Behalf Of Susan Hares

Sent: Tuesday, May 27, 2014 7:19 PM

To: idr wg

Cc: 'John G. Scudder'

Subject: [Idr] WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - fro=
m 5/27/14 to 6/10/14






 


Working Group,


 


This is to begin a 2 week WG LC=
 for draft-ietf-idr-bgp-gr-notification-02.txt which will end on 6/10/2014.=
  Please put within your comments:  “support” or
 “no-support” for WG LC. 


 


Jeff Haas comments that the mos=
t recent changes reflect implementation experience and some word smithing.&=
nbsp; There is also a minor clarification in the NOTIFICATION
 message with respect to including a data byte so the original reason for t=
he event can be propagated.  (See sec. 3.1 in the diff.)


 


The abstract is below.



 


Sue Hares


 


 


----------


 


Abstract:


   The current BGP Gr=
aceful Restart mechanism limits the usage of BGP


   Graceful Restart t=
o BGP protocol messages other than a BGP


   NOTIFICATION messa=
ge.  This document defines an extension to the BGP

   Graceful Restart t=
hat permits the Graceful Restart procedures to be


   performed when the=
 BGP speaker receives a BGP NOTIFICATION Message.


   This document also=
 defines a new BGP NOTIFICATION Cease Error subcode


   to prevent BGP spe=
akers supporting the extension defined in this


   document from perf=
orming a Graceful Restart.


 


 




______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A07163323PEXCVZYM11corpo_-- From nobody Mon Jun 16 07:43:11 2014 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 B156A1A0062 for ; Mon, 16 Jun 2014 07:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FDP77YGCItqj for ; Mon, 16 Jun 2014 07:43:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88DDD1A004C for ; Mon, 16 Jun 2014 07:43:06 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id AE10222C31E for ; Mon, 16 Jun 2014 16:43:04 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6594927C066 for ; Mon, 16 Jun 2014 16:43:04 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 16 Jun 2014 16:43:04 +0200 From: To: idr wg Thread-Topic: [Idr] WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14 Thread-Index: Ac95z8QW0vzMlOacTU2VJDkM0E8LngPk0LXQAANld9A= Date: Mon, 16 Jun 2014 14:43:03 +0000 Message-ID: <1376_1402929784_539F0278_1376_885_1_53C29892C857584299CBF5D05346208A0716337B@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.4.92121 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ghe6HDssPi-a8b0WooNhu0TSP6s Subject: [Idr] FW: WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:43:08 -0000 Resending as text only, as I've been told the previous email was hard to pa= rse. Sorry for the spam. ----- Hi, Read and support. Please find below some comments: 1) "1. Introduction [.] This is also true for HOLDTIME expiration" IMHO this is a significant point that could be added in the Abstract.=20 e.g. OLD: =A0when the BGP speaker receives a BGP NOTIFICATION Message NEW: when the BGP speaker receives a BGP NOTIFICATION Message or the HOLDTI= ME expires. ----------------------- 2) In particular, if the BGP speaker is down, the upper bound to keep BGP r= outes is increased. IHMO this should be indicated in a new deployment consi= deration section. Also it's not very clear how long the routes are kept. I guess HOLDTIME + "= the possible local unnamed timer at the end of RFC 4724 section 4.2". If th= is is the case, this timer should probably be given a name and become a MUS= T to implement (it's a MAY in RFC 4271) -----------------------=A0=20 3)=20 "=A0 Flags for Address Family: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This field contains bit flags relating t= o routes that were =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 advertised with the given AFI and SAFI. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |F|N| Reserved=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+ =A0=A0 The usage of second most significant bit "N" is deprecated.=A0 This= bit =A0=A0 MUST be advertised as 0 and MUST be ignored upon receipt." IMHO the above text could be deleted from the document. (IINM, this flag "N= " has been tentatively defined in earlier version of _this_ draft. When thi= s docs becomes RFC, there is nothing the deprecate has this flag would have= never been specified) ----------------------- =A7 4. Operation "=A0=A0 A BGP speaker that is willing to receive and send BGP NOTIFICATION =A0=A0 messages in Graceful mode MUST advertise the BGP Graceful =A0 =A0Notification Flag "N" using the Graceful Restart Capability as =A0=A0 defined in [RFC4724]. =A0=A0 When such a BGP Speaker receives a BGP NOTIFICATION message other =A0 =A0than a Hard Reset, it MUST follow the rules for the Receiving Speaker =A0=A0 mentioned in Section 4.1." Between both sentences, IMHO a text is missing stating that this new behavi= or is only activated when both speakers advertised flag "N". With current s= econd sentence, only the sending of this N flag would be enough to trigger = the new behavior. ----------------------- =A74.1 =A0Rules for the Receiving Speaker This section 4.1 tries to patch section 4.2 of RFC4274 but I don't find it = easy to read nor clear. e.g. " As part of this extension, routes from the peer previously marked as =A0=A0 stale MUST NOT be deleted, until and unless the timer mentioned in =A0=A0 the final paragraph of [RFC4724] S. 4.2 expires, or unless a Hard =A0=A0 Reset is performed.=A0=BB - So the STALE routes are not deleted when I received an End-of-RIB marker?= ? (I know the answer but it's not crystal clear what exactly the above sent= ence overwrites) As an alternative, the whole RFC 4724 s4.2 could be copied and updated as n= eeded. Or the OLD/NEW deliminater could be used to indicate what is removed= and what is added. - Also it's not clear whether these modifications only apply to GR triggere= d by NOTIFICATION/HOLDTIME expiration or by "regular" (RFC 4274) GR cases. --- Nits (IMHO) : OLD: If a Hard Reset is used, a full session reset is performed. NEW: If a Hard Reset is used, a session reset is performed as per RFC 4271. OLD: =A0=A0A new BGP NOTIFICATION Cease message subcode is defined known as= the BGP Hard Reset Subcode. NEW: A new BGP NOTIFICATION Cease message subcode called "BGP Hard Reset Su= bcode" is defined. Thanks, Best regards, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, May 27, 2014 7:19 PM To: idr wg Cc: 'John G. Scudder' Subject: [Idr] WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/= 14 to 6/10/14 Working Group, This is to begin a 2 week WG LC for draft-ietf-idr-bgp-gr-notification-02.t= xt which will end on 6/10/2014. =A0Please put within your comments:=A0 "sup= port" or "no-support" for WG LC.=20 Jeff Haas comments that the most recent changes reflect implementation expe= rience and some word smithing.=A0 There is also a minor clarification in th= e NOTIFICATION message with respect to including a data byte so the origina= l reason for the event can be propagated.=A0 (See sec. 3.1 in the diff.) The abstract is below.=20 Sue Hares ---------- Abstract: =A0=A0 The current BGP Graceful Restart mechanism limits the usage of BGP =A0=A0 Graceful Restart to BGP protocol messages other than a BGP =A0=A0 NOTIFICATION message.=A0 This document defines an extension to the B= GP =A0=A0 Graceful Restart that permits the Graceful Restart procedures to be =A0=A0 performed when the BGP speaker receives a BGP NOTIFICATION Message. =A0=A0 This document also defines a new BGP NOTIFICATION Cease Error subcode =A0=A0 to prevent BGP speakers supporting the extension defined in this =A0=A0 document from performing a Graceful Restart. ___________________________________________________________________________= ______________________________________________ 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 Mon Jun 16 11:47:28 2014 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 BF7AC1A014C for ; Mon, 16 Jun 2014 11:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 X4MPYXDfM3jJ for ; Mon, 16 Jun 2014 11:47:26 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F3A311A013B for ; Mon, 16 Jun 2014 11:47:25 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9D4BDC406; Mon, 16 Jun 2014 14:47:25 -0400 (EDT) Date: Mon, 16 Jun 2014 14:47:25 -0400 From: Jeffrey Haas To: Chris Hall Message-ID: <20140616184725.GB31387@pfrc> References: <20140613183222.27662.91400.idtracker@ietfa.amsl.com> <48D0139F-CD0E-474C-A557-E18E6100157A@juniper.net> <009f01cf87df$48630760$d9291620$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009f01cf87df$48630760$d9291620$@highwayman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/t2zgRsd9-4P3TI8CO3MfLW2rqp8 Cc: "'idr@ietf. org'" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 18:47:26 -0000 On Sat, Jun 14, 2014 at 03:45:22PM +0100, Chris Hall wrote: > I have a feeling that defining "valid host address" is more trouble > than it is worth. I'm also a bit concerned here. RFC 4271 and earlier went through a lot of wrangling to end up with the idea syntactically correct vs. semantically correct. If it's syntactically incorrect, treat as withdraw is quite reasonable. Semantically incorrect gets heavily tied up into how we're breaking original rules today in a given spec. E.g. RFC 5575 zero length. What happens when we decide to get clever and end up using a class D/E address in IPv4? Etc. For any future Clever Feature, deployment of it will need to be pervasive enough for the networks using it to make use of it. This means an island of semantic correctness for something that didn't used to be that way. If you're outside of the island, it's semantically incorrect, treat as withdraw. It may thus be worthwhile simplifying the section: "If the next hop field contains a semantically incorrect address within the context of deployed features and address family, treat as withdraw behavior should be used." I'd keep the section on martians. -- Jeff From nobody Mon Jun 16 13:39:27 2014 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 7FB5E1A021A for ; Mon, 16 Jun 2014 13:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RM1P9hHo2npV for ; Mon, 16 Jun 2014 13:38:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2308D1A01EB for ; Mon, 16 Jun 2014 13:38:54 -0700 (PDT) Received: from hjohnson-sslvpn-nc.jnpr.net (66.129.241.17) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.959.24; Mon, 16 Jun 2014 20:38:52 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <1376_1402929784_539F0278_1376_885_1_53C29892C857584299CBF5D05346208A0716337B@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Mon, 16 Jun 2014 16:38:41 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <93D9A082-5E9E-4C39-8E5B-2C6616B04516@juniper.net> References: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com> <1376_1402929784_539F0278_1376_885_1_53C29892C857584299CBF5D05346208A0716337B@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.17] X-ClientProxiedBy: BY2PR02CA019.namprd02.prod.outlook.com (10.242.234.147) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0244637DEA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(199002)(189002)(51704005)(24454002)(5423002)(76482001)(105586001)(64706001)(102836001)(20776003)(87976001)(93916002)(47776003)(66066001)(46102001)(81542001)(50466002)(83072002)(23756003)(80022001)(99396002)(19580395003)(86362001)(76176999)(83322001)(89996001)(92566001)(82746002)(77982001)(77156001)(57306001)(69596002)(31966008)(33656002)(104166001)(4396001)(101416001)(88136002)(74502001)(83716003)(42186005)(79102001)(85852003)(92726001)(87286001)(77096002)(21056001)(50226001)(19580405001)(53416004)(62966002)(81342001)(50986999)(85306003)(95666004)(74662001)(81156003)(36756003)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:hjohnson-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/f7kf_zLZ4dPZ8rL3dVsg5nIXink Cc: idr wg Subject: Re: [Idr] FW: WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 20:39:02 -0000 A couple of responses below As for the rest, I either agree or anyway = don't disagree, and will try to take the comments on board. On Jun 16, 2014, at 10:43 AM, = wrote: > ----------------------- =20 > 3)=20 > " Flags for Address Family: >=20 > This field contains bit flags relating to routes = that were > advertised with the given AFI and SAFI. >=20 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |F|N| Reserved | > +-+-+-+-+-+-+-+-+ >=20 > The usage of second most significant bit "N" is deprecated. = This bit > MUST be advertised as 0 and MUST be ignored upon receipt." >=20 >=20 >=20 > IMHO the above text could be deleted from the document. (IINM, this = flag "N" has been tentatively defined in earlier version of _this_ = draft. When this docs becomes RFC, there is nothing the deprecate has = this flag would have never been specified) Given that an earlier version was published that proposed the use of = this flag, I see no downside to marking it deprecated now, just in case = someone did implement that version or somehow happens upon it. Do you = see any reason to remove it, other than orderliness? Bear in mind that = "deprecated" means "can eventually be reused". > ----------------------- > =A7 4. Operation > " A BGP speaker that is willing to receive and send BGP = NOTIFICATION > messages in Graceful mode MUST advertise the BGP Graceful > Notification Flag "N" using the Graceful Restart Capability = as > defined in [RFC4724]. >=20 > When such a BGP Speaker receives a BGP NOTIFICATION message other > than a Hard Reset, it MUST follow the rules for the Receiving = Speaker > mentioned in Section 4.1." >=20 >=20 > Between both sentences, IMHO a text is missing stating that this new = behavior is only activated when both speakers advertised flag "N". With = current second sentence, only the sending of this N flag would be enough = to trigger the new behavior. Do you see some advantage to requiring that the sender has sent the N = flag, before you process a graceful notification? I can see some = advantage to NOT so requiring, for example it allows you to enable = support without having to re-exchange Capabilities. This does call into = question why we even need the Capability flag, though I think things are = still tidier if we have it. --John= From nobody Mon Jun 16 19:16:09 2014 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 0BAF71A02E9 for ; Mon, 16 Jun 2014 19:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 l_JV7nSqGx1V for ; Mon, 16 Jun 2014 19:16:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E0F1A02E8 for ; Mon, 16 Jun 2014 19:15:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFM72561; Tue, 17 Jun 2014 02:14:58 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Jun 2014 03:14:57 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 17 Jun 2014 10:14:52 +0800 From: "Dongjie (Jimmy)" To: Robert Raszuk Thread-Topic: [Idr] RFC 4684 pedantry - routes with no Route Target Thread-Index: AQHPfAfCSdt6mgQZTkKmeoaf0TXRm5tzJsXg///U9ACAAaGZ8A== Date: Tue, 17 Jun 2014 02:14:51 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273367BED3@nkgeml512-mbx.china.huawei.com> References: <25B13537-15F0-4994-8504-C04FF94C72C3@juniper.net> <13330.1401455098@erosen-lnx> <76CD132C3ADEF848BD84D028D243C9273367B9D0@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C9273367BED3nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/s3WLGU-Kx21V88CJgEc5Q1T6B0M Cc: "erosen@cisco.com" , "idr@ietf.org" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target 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, 17 Jun 2014 02:16:06 -0000 --_000_76CD132C3ADEF848BD84D028D243C9273367BED3nkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMsIHBsZWFzZSBzZWUgbXkgcmVw bGllcyBpbmxpbmU6DQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0Bn bWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBNb25kYXksIEp1bmUg MTYsIDIwMTQgNDoyOCBQTQ0KVG86IERvbmdqaWUgKEppbW15KQ0KQ2M6IGVyb3NlbkBjaXNjby5j b207IEpvaG4gRy4gU2N1ZGRlcjsgaWRyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lkcl0gUkZD IDQ2ODQgcGVkYW50cnkgLSByb3V0ZXMgd2l0aCBubyBSb3V0ZSBUYXJnZXQNCg0KSmllLA0KDQpJ biBteSB1bmRlcnN0YW5kaW5nLCB0aGlzIGltcGxpZXMgdHdvIHRoaW5nczoNCg0KIDEpIFJUQyBj b3VsZCBiZSBlbmFibGVkIG9uIGEgcGFydGljdWxhciBBRkkvU0FGSTsNCg0K4oCLWWVzLuKAiw0K DQogMikgUlRDIHByb2Nlc3NpbmcgZm9yIGRpZmZlcmVudCBBRkkvU0FGSXMgY291bGQgYmUgZGlm ZmVyZW50Ow0KDQrigItOby7igIsNCg0KI0ppZTogVGhlIFJUQyBwcm9jZXNzaW5nIGZvciB0aGUg TURUIFNBRkkgaXMgbm90IHRoZSBzYW1lIGFzIGZvciBvdGhlciBWUE4gQUZJL1NBRklzLCBpcyBt eSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQoNCg0KV2hpbGUgY3VycmVudGx5IFJUQyBpcyBhIGds b2JhbCBjYXBhYmlsaXR5LCB3aGljaCBjYW5ub3QgYmUgZW5hYmxlZCBvbiBhIHBhcnRpY3VsYXIg QUZJL1NBRkkgb25seSwNCg0KDQrigItPZiBjb3Vyc2Ugd2UgY2FuIC0gd2h5IG5vdCA/IFRvIHNl bmQgUlRzIGFuZCB0byBwcm9jZXNzIHRoZW0gcmVxdWlyZXMgYSBjb21tYW5kIG9uIGEgcGVyIEFG IGJhc2lzLiDigIsNCg0KI0ppZTogSSBndWVzcyB5b3UgbWVhbiB1c2luZyBzb21lIHBlci1BRkkv U0FGSSBrbm9iIGFzIG1lbnRpb25lZCBpbiBKZWZm4oCZcyBtYWlsOg0KDQotIFBlcm1pdCBhIHBl ci1wZWVyLCBwZXItQUZJL1NBRkkga25vYiB0byBlbmFibGUvZGlzYWJsZSBSVC1DIHByb2Nlc3Np bmcuDQoNCldoaWxlIHRoaXMgY291bGQgY29udHJvbCB0aGUgbG9jYWwgUlRDIHByb2Nlc3Npbmcs IHRoZSBwb2ludCBpcyB3aXRoIGN1cnJlbnQgUlRDIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gdGhl IEJHUCBwZWVyIG9ubHkga25vd3MgdGhhdCBSVEMgaXMgZW5hYmxlZCBvbiB0aGlzIHNlc3Npb24s IGFuZCBoYXMgbm8gaWRlYSB3aGljaCBBRkkvU0FGSSBvbiBpdHMgcGVlciBpcyBhbGxvd2VkIGJ5 IHRoZSBsb2NhbCBrbm9iIHRvIHByb2Nlc3MgUlRDLiBJZiBvbiB0d28gcGVlcmluZyBzcGVha2Vy cyB0aGUga25vYnMgYXJlIGVuYWJsZWQgaW5jb25zaXN0ZW50bHksIHRoaXMgY2Fubm90IGJlIGZv dW5kIHRocm91Z2ggQkdQIGNhcGFiaWxpdHkgYWR2ZXJ0aXNlbWVudC4gU2luY2UgUlRDIGNhbiB3 b3JrIGNvcnJlY3RseSBvbmx5IGlmIHRoZSBrbm9iIGlzIGVuYWJsZWQgY29uc2lzdGVudGx5IGlu IHRoZSBuZXR3b3JrLCBpdCBtYXkgYmUgaGVscGZ1bCB0byBhZHZlcnRpc2UgdGhlIFJUQyBjYXBh YmlsaXR5IG9mIHNwZWNpZmljIEFGSS9TQUZJcy4NCg0KZWl0aGVyIGNhbm5vdCBiZWhhdmUgZGlm ZmVyZW50bHkgZm9yIGRpZmZlcmVudCBBRkkvU0FGSXMuDQoNCuKAi1RoYXQgd2FzIG5ldmVyIHN1 YmplY3Qgb2YgdGhpcyBkaXNjdXNzaW9uLiBJdCdzIGNvbXBsZXRlbHkgc2VwYXJhdGUgY2hhbmdl IHdoaWNoIGRvZXMgcmVxdWlyZSBjaGFuZ2VzIHRvIGJhc2Ugc3BlYy7igIsNCg0KI0ppZTogdGhl IE1EVCBTQUZJIHJlcXVpcmVzIGRpZmZlcmVudCBSVEMgcHJvY2Vzc2luZywgYW5kIGl0IHdhcm5z IHVzIHRoYXQgc29tZSBvdGhlciBhZGRyZXNzIGZhbWlsaWVzIG1heSBoYXZlIHNpbWlsYXIgcmVx dWlyZW1lbnQgaW4gZnV0dXJlLiBUaGlzIG1heSBiZSBhY2hpZXZlZCBlaXRoZXIgYnkgQUYgc3Bl Y2lmaWMgdXBkYXRlIGRvY3VtZW50cywgb3IgYnkgc29tZSB1cGRhdGUgdG8gdGhlIGJhc2Ugc3Bl Yy4NCg0KDQpTbyBjYW4gSSBpbmZlciB0aGF0IHlvdSBwcmVmZXIgdG8gbWFrZSBSVEMgYSBBRkkv U0FGSSBzcGVjaWZpYyBjYXBhYmlsaXR5Pw0KDQrigItUaGF0IHdhcyBhbHNvIG5ldmVyIHBhcnQg b2YgdGhpcyB0b3BpYy4NCg0KSSB3b3VsZCByZWNvbW1lbmQgdG8gc2VwYXJhdGUgdGhlIGRpc2N1 c3Npb24gaW50byBzcGVjaWZ5aW5nIOKAi3RoZSBkZWZhdWx0IGJlaGF2aW9yIGZvciByb3V0ZXMg d2l0aCBubyBSVHMgd2hpbGUgc2VwYXJhdGVseSBkaXNjdXNzIGNoYW5nZXMgdG8gYmFzZSBSRkMg dG8gbWFrZSBpdCBwZXIgQUZJL1NBRkkgKHByb3ZpZGVkIHRoZXJlIGlzIGNvbW11bml0eSBzdXBw b3J0IGZvciBzdWNoIG1ham9yIHJld3JpdGUpLg0KDQojSmllOiBUaGUgZGVmYXVsdCBiZWhhdmlv ciBmb3Igcm91dGVzIHdpdGggbm8gUlRzIG1heSBiZSBkaWZmZXJlbnQgZm9yIGRpZmZlcmVudCBB RkkvU0FGSXMsIHRoYXTigJlzIHdoeSBJIGJyaW5ncyB0aGUgQUZJL1NBRkkgc3BlY2lmaWMgZGlz Y3Vzc2lvbiBoZXJlLg0KDQpJ4oCZbSBPSyB3aXRoIGNvbnRpbnVpbmcgdGhpcyBwZXIgQUZJL1NB RkkgZGlzY3Vzc2lvbiBzZXBhcmF0ZWx5LCBhbmQgSSBhbHNvIHByZWZlciBub3QgdG8gbWFrZSBt YWpvciBjaGFuZ2VzIHRvIGJhc2UgUlRDIGlmIHBvc3NpYmxlLg0KDQpCZXN0IHJlZ2FyZHMsDQpK aWUNCg0K --_000_76CD132C3ADEF848BD84D028D243C9273367BED3nkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHls ZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkw LjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SGkgUm9iZXJ0LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBm b3IgeW91ciBjb21tZW50cywgcGxlYXNlIHNlZSBteSByZXBsaWVzIGlubGluZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWls LmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9i PiBNb25kYXksIEp1bmUgMTYsIDIwMTQgNDoyOCBQTTxicj4NCjxiPlRvOjwvYj4gRG9uZ2ppZSAo SmltbXkpPGJyPg0KPGI+Q2M6PC9iPiBlcm9zZW5AY2lzY28uY29tOyBKb2huIEcuIFNjdWRkZXI7 IGlkckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkcl0gUkZDIDQ2ODQgcGVk YW50cnkgLSByb3V0ZXMgd2l0aCBubyBSb3V0ZSBUYXJnZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+SmllLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SW4gbXkgdW5kZXJzdGFuZGluZywgdGhpcyBpbXBsaWVz IHR3byB0aGluZ3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KJm5ic3A7MSkgUlRDIGNvdWxkIGJlIGVu YWJsZWQgb24gYSBwYXJ0aWN1bGFyIEFGSS9TQUZJOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FtYnJpYSBNYXRoJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+WWVzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oCLPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsyKSBSVEMgcHJvY2Vzc2luZyBmb3IgZGlmZmVyZW50IEFGSS9TQUZJcyBjb3Vs ZCBiZSBkaWZmZXJlbnQ7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1h dGgmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Oby48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPuKAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4jSmllOiBUaGUgUlRDIHByb2Nlc3NpbmcgZm9yIHRoZSBNRFQgU0FGSSBpcyBub3QgdGhl IHNhbWUgYXMgZm9yIG90aGVyIFZQTiBBRkkvU0FGSXMsIGlzIG15IHVuZGVyc3RhbmRpbmcgY29y cmVjdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoaWxlIGN1cnJlbnRseSBSVEMgaXMgYSBnbG9iYWwg Y2FwYWJpbGl0eSwgd2hpY2ggY2Fubm90IGJlIGVuYWJsZWQgb24gYSBwYXJ0aWN1bGFyIEFGSS9T QUZJIG9ubHksDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPuKAizwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5PZiBjb3Vyc2Ugd2UgY2FuIC0gd2h5IG5vdCA/IFRvIHNlbmQgUlRzIGFuZCB0 byBwcm9jZXNzIHRoZW0gcmVxdWlyZXMgYSBjb21tYW5kIG9uIGEgcGVyIEFGIGJhc2lzLg0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSBN YXRoJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7igIs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+I0ppZTogSSBndWVzcyB5b3UgbWVhbiB1c2luZyBzb21lIHBlci1BRkkvU0FG SSBrbm9iIGFzIG1lbnRpb25lZCBpbiBKZWZm4oCZcyBtYWlsOg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwLjVwdDt0 ZXh0LWluZGVudDoxMC41cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIFBlcm1pdCBhIHBlci1wZWVy LCBwZXItQUZJL1NBRkkga25vYiB0byBlbmFibGUvZGlzYWJsZSBSVC1DIHByb2Nlc3NpbmcuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ V2hpbGUgdGhpcyBjb3VsZCBjb250cm9sIHRoZSBsb2NhbCBSVEMgcHJvY2Vzc2luZywgdGhlIHBv aW50IGlzIHdpdGggY3VycmVudCBSVEMgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiB0aGUgQkdQIHBl ZXIgb25seSBrbm93cyB0aGF0IFJUQyBpcyBlbmFibGVkDQogb24gdGhpcyBzZXNzaW9uLCBhbmQg aGFzIG5vIGlkZWEgd2hpY2ggQUZJL1NBRkkgb24gaXRzIHBlZXIgaXMgYWxsb3dlZCBieSB0aGUg bG9jYWwga25vYiB0byBwcm9jZXNzIFJUQy4gSWYgb24gdHdvIHBlZXJpbmcgc3BlYWtlcnMgdGhl IGtub2JzIGFyZSBlbmFibGVkIGluY29uc2lzdGVudGx5LCB0aGlzIGNhbm5vdCBiZSBmb3VuZCB0 aHJvdWdoIEJHUCBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQuIFNpbmNlIFJUQyBjYW4gd29yayBj b3JyZWN0bHkNCiBvbmx5IGlmIHRoZSBrbm9iIGlzIGVuYWJsZWQgY29uc2lzdGVudGx5IGluIHRo ZSBuZXR3b3JrLCBpdCBtYXkgYmUgaGVscGZ1bCB0byBhZHZlcnRpc2UgdGhlIFJUQyBjYXBhYmls aXR5IG9mIHNwZWNpZmljIEFGSS9TQUZJcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ZWl0aGVy IGNhbm5vdCBiZWhhdmUgZGlmZmVyZW50bHkgZm9yIGRpZmZlcmVudCBBRkkvU0FGSXMuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+4oCLPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoYXQgd2FzIG5ldmVyIHN1YmplY3Qgb2YgdGhpcyBk aXNjdXNzaW9uLiBJdCdzIGNvbXBsZXRlbHkgc2VwYXJhdGUgY2hhbmdlIHdoaWNoIGRvZXMgcmVx dWlyZSBjaGFuZ2VzIHRvIGJhc2Ugc3BlYy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PuKAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4jSmllOiB0aGUgTURUIFNB RkkgcmVxdWlyZXMgZGlmZmVyZW50IFJUQyBwcm9jZXNzaW5nLCBhbmQgaXQgd2FybnMgdXMgdGhh dCBzb21lIG90aGVyIGFkZHJlc3MgZmFtaWxpZXMgbWF5IGhhdmUgc2ltaWxhciByZXF1aXJlbWVu dCBpbiBmdXR1cmUuDQogVGhpcyBtYXkgYmUgYWNoaWV2ZWQgZWl0aGVyIGJ5IEFGIHNwZWNpZmlj IHVwZGF0ZSBkb2N1bWVudHMsIG9yIGJ5IHNvbWUgdXBkYXRlIHRvIHRoZSBiYXNlIHNwZWMuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+U28gY2FuIEkgaW5mZXIgdGhhdCB5b3UgcHJlZmVyIHRvIG1h a2UgUlRDIGEgQUZJL1NBRkkgc3BlY2lmaWMgY2FwYWJpbGl0eT88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oCLPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPlRoYXQgd2FzIGFsc28gbmV2ZXIgcGFydCBvZiB0aGlzIHRvcGljLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgd291bGQgcmVjb21tZW5kIHRvIHNlcGFyYXRlIHRoZSBk aXNjdXNzaW9uIGludG8gc3BlY2lmeWluZw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSBNYXRoJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij7igIs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+dGhlIGRlZmF1bHQgYmVoYXZpb3IgZm9yIHJvdXRlcyB3aXRoIG5v IFJUcyB3aGlsZSBzZXBhcmF0ZWx5IGRpc2N1c3MgY2hhbmdlcyB0byBiYXNlIFJGQyB0byBtYWtl IGl0IHBlciBBRkkvU0FGSSAocHJvdmlkZWQgdGhlcmUNCiBpcyBjb21tdW5pdHkgc3VwcG9ydCBm b3Igc3VjaCBtYWpvciByZXdyaXRlKS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+I0ppZTogVGhlIGRlZmF1bHQgYmVoYXZpb3IgZm9yIHJvdXRlcyB3aXRoIG5vIFJU cyBtYXkgYmUgZGlmZmVyZW50IGZvciBkaWZmZXJlbnQgQUZJL1NBRklzLCB0aGF04oCZcyB3aHkg SSBicmluZ3MgdGhlIEFGSS9TQUZJIHNwZWNpZmljIGRpc2N1c3Npb24NCiBoZXJlLiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gT0sgd2l0aCBjb250aW51aW5nIHRo aXMgcGVyIEFGSS9TQUZJIGRpc2N1c3Npb24gc2VwYXJhdGVseSwgYW5kIEkgYWxzbyBwcmVmZXIg bm90IHRvIG1ha2UgbWFqb3IgY2hhbmdlcyB0byBiYXNlIFJUQyBpZiBwb3NzaWJsZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmllPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_76CD132C3ADEF848BD84D028D243C9273367BED3nkgeml512mbxchi_-- From nobody Mon Jun 16 23:55:04 2014 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 457B01A0299 for ; Mon, 16 Jun 2014 23:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj339TUnZZW4 for ; Mon, 16 Jun 2014 23:55:01 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C08E1A0289 for ; Mon, 16 Jun 2014 23:55:01 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id a13so3860524igq.9 for ; Mon, 16 Jun 2014 23:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GUyg/e3QWueMsvyWJp28w1lcXYShRM+gAyuKr5zeYls=; b=laT8H4l7JjpDA9H5MMEBHgKWGJP5PIhLk+9/z+1nugajFyLzsAeZsExHol5RP71Q0W d4la1PSDdAlDK6I9+HX/R/PHC+xU42K0a1U8QslgP46WJnlougwKtHrRHN8bDuST1GG/ x0avojqCXVRvAXB9YhGdc684Cy8X4vz1sF3rk7H2P/9D4RPGN/obV7ng+tbEfdLDr6ld 4QxmZY9Xw0J982jw6GG9QQlT3iOTo/AYxoI6OUk/+pOSyp9ym6vjicMoeYNWUPHYKkQT MuEhK+IavEHKA/cR7wJmkxW74EyRHkvmm1aWHAV820tG4fkyTS5XSMOfzvBXisOsGvb4 9cMA== MIME-Version: 1.0 X-Received: by 10.50.79.137 with SMTP id j9mr30270205igx.29.1402988100866; Mon, 16 Jun 2014 23:55:00 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 16 Jun 2014 23:55:00 -0700 (PDT) In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273367BED3@nkgeml512-mbx.china.huawei.com> References: <25B13537-15F0-4994-8504-C04FF94C72C3@juniper.net> <13330.1401455098@erosen-lnx> <76CD132C3ADEF848BD84D028D243C9273367B9D0@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273367BED3@nkgeml512-mbx.china.huawei.com> Date: Tue, 17 Jun 2014 08:55:00 +0200 X-Google-Sender-Auth: EieJNVJXN3ee7x6rZhfbTLTRTMw Message-ID: From: Robert Raszuk To: "Dongjie (Jimmy)" Content-Type: multipart/alternative; boundary=089e013a0c1e6058dd04fc029f25 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/iXUMWW-3wCM-fPhZw34TjAsZ9rE Cc: "erosen@cisco.com" , "idr@ietf.org" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target 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, 17 Jun 2014 06:55:03 -0000 --089e013a0c1e6058dd04fc029f25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jie, #Jie: The RTC processing for the MDT SAFI is not the same as for other VPN > AFI/SAFIs, is my understanding correct? > =E2=80=8BNot sure what you call processing. The current RTC model is that you advertise interesting RTs as a global property of the peer. It's not even per session as far as set of advertised RTs. That means that given RT value should be used for specific address family or if there is congruence for more the one AF. That also means that in order to apply different filtering rules on a per specific SAFI basis set of RTs used by that SAFI must be unique. Of course one can debate if this model is best or not but if you think about VPN focus as major application the VPN topologies do not different that much on a per AFI/SAFI basis for a given customer. Moreover I do not think we are anywhere near starvation in the space of 6 or 18 octet RTs. As to your comment of using BGP capability to verify configuration correctness on both ends well while the idea is great there are much more knobs and twicks in BGP which would benefit from the same. Do we want to load all of them to capabilities ? I am under impression that we should keep capabilities only to critical session related information. =E2=80=8BMoreover I do not see much harm in potential hypothetical config inconsistency. The RTC sender if enabled will or will not send all RTs he is interested in globally on a per session basis while the receiver will or will not apply such filter on a per SAFI basis. Due to lack of dynamic capabilities each change in such config will result in session reset. Do we want to go that path ? =E2=80=8BBest, r.=E2=80=8B > > > > > While currently RTC is a global capability, which cannot be enabled on a > particular AFI/SAFI only, > > > > > > =E2=80=8BOf course we can - why not ? To send RTs and to process them req= uires a > command on a per AF basis. =E2=80=8B > > > > #Jie: I guess you mean using some per-AFI/SAFI knob as mentioned in Jeff= =E2=80=99s > mail: > > - Permit a per-peer, per-AFI/SAFI knob to enable/disable RT-C processing. > > > > While this could control the local RTC processing, the point is with > current RTC capability negotiation the BGP peer only knows that RTC is > enabled on this session, and has no idea which AFI/SAFI on its peer is > allowed by the local knob to process RTC. If on two peering speakers the > knobs are enabled inconsistently, this cannot be found through BGP > capability advertisement. Since RTC can work correctly only if the knob i= s > enabled consistently in the network, it may be helpful to advertise the R= TC > capability of specific AFI/SAFIs. > > > > either cannot behave differently for different AFI/SAFIs. > > > > =E2=80=8BThat was never subject of this discussion. It's completely separ= ate > change which does require changes to base spec.=E2=80=8B > > > > #Jie: the MDT SAFI requires different RTC processing, and it warns us tha= t > some other address families may have similar requirement in future. This > may be achieved either by AF specific update documents, or by some update > to the base spec. > > > > > > So can I infer that you prefer to make RTC a AFI/SAFI specific capability= ? > > > > =E2=80=8BThat was also never part of this topic. > > > > I would recommend to separate the discussion into specifying =E2=80=8Bthe= default > behavior for routes with no RTs while separately discuss changes to base > RFC to make it per AFI/SAFI (provided there is community support for such > major rewrite). > > > > #Jie: The default behavior for routes with no RTs may be different for > different AFI/SAFIs, that=E2=80=99s why I brings the AFI/SAFI specific di= scussion > here. > > > > I=E2=80=99m OK with continuing this per AFI/SAFI discussion separately, a= nd I also > prefer not to make major changes to base RTC if possible. > > > > Best regards, > > Jie > > > --089e013a0c1e6058dd04fc029f25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jie,

#Jie: The RTC processing for the MDT SAFI is not the same a= s for other VPN AFI/SAFIs, is my understanding correct?


=E2=80=8BNot sure what you call processing.= =C2=A0

The current RTC model is that you adverti= se interesting RTs as a global property of the peer. It's not even per = session as far as set of advertised RTs.=C2=A0

That means that g= iven RT value should be used for specific address family or if there is con= gruence for more the one AF.

That also means t= hat in order to apply different filtering rules on a per specific SAFI basi= s set of RTs used by that SAFI must be unique.=C2=A0

Of course one can= debate if this model is best or not but if you think about VPN focus as ma= jor application the VPN topologies do not different that much on a per AFI/= SAFI basis for a given customer.=C2=A0

Moreover I do not= think we are anywhere near starvation in the space of 6 or 18 octet RTs.= =C2=A0

As to your commen= t of using BGP capability to verify configuration correctness on both ends = well while the idea is great there are much more knobs and twicks in BGP wh= ich would benefit from the same. Do we want to load all of them to capabili= ties ? I am under impression that we should keep capabilities only to criti= cal session related information.=C2=A0

=E2=80=8BMoreover I do not see much = harm in potential hypothetical config inconsistency. The RTC sender if enab= led will or will not send all RTs he is interested in globally on a per ses= sion basis while the receiver will or will not apply such filter on a per S= AFI basis.=C2=A0

Due to lack of dy= namic capabilities each change in such config will result in session reset.= Do we want to go that path ?=C2=A0

=E2=80=8BBest,
r.=E2=80=8B



=C2=A0

=C2=A0

=C2=A0

While currently RTC is a global= capability, which cannot be enabled on a particular AFI/SAFI only,

=C2=A0

=C2=A0

=E2=80=8BOf course we can - why not ? To s= end RTs and to process them requires a command on a per AF basis. =E2=80=8B

=C2= =A0

#Jie: I gu= ess you mean using some per-AFI/SAFI knob as mentioned in Jeff=E2=80=99s ma= il:

- P= ermit a per-peer, per-AFI/SAFI knob to enable/disable RT-C processing.

=C2= =A0

While this= could control the local RTC processing, the point is with current RTC capa= bility negotiation the BGP peer only knows that RTC is enabled on this session, and has no idea which AFI/SAFI on its peer is allowed by = the local knob to process RTC. If on two peering speakers the knobs are ena= bled inconsistently, this cannot be found through BGP capability advertisem= ent. Since RTC can work correctly only if the knob is enabled consistently in the network, it may be helpful= to advertise the RTC capability of specific AFI/SAFIs.

=C2=A0

either cannot behave differentl= y for different AFI/SAFIs.

=C2=A0

=E2=80=8BThat was never subject of this di= scussion. It's completely separate change which does require changes to= base spec.=E2=80=8B

=C2= =A0

#Jie: the = MDT SAFI requires different RTC processing, and it warns us that some other= address families may have similar requirement in future. This may be achieved either by AF specific update documents, or by some up= date to the base spec.

=C2=A0

=C2=A0

So can I infer that you prefer = to make RTC a AFI/SAFI specific capability?

=C2=A0

=E2=80=8BThat was also never part of this = topic.=C2=A0

=C2=A0

I would recommend to separate the discussion into specifying =E2=80=8Bthe default behavior for routes with no RTs while= separately discuss changes to base RFC to make it per AFI/SAFI (provided t= here is community support for such major rewrite).=C2=A0

=C2= =A0

#Jie: The = default behavior for routes with no RTs may be different for different AFI/= SAFIs, that=E2=80=99s why I brings the AFI/SAFI specific discussion here.

=C2= =A0

I=E2=80=99= m OK with continuing this per AFI/SAFI discussion separately, and I also pr= efer not to make major changes to base RTC if possible.

=C2= =A0

Best regar= ds,

Jie=

=C2=A0


--089e013a0c1e6058dd04fc029f25-- From nobody Tue Jun 17 01:02:50 2014 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 D760F1A02FC for ; Tue, 17 Jun 2014 01:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 l_jPw9_85Cfq for ; Tue, 17 Jun 2014 01:02:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA141A0302 for ; Tue, 17 Jun 2014 01:02:38 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id BBBEC2AC368; Tue, 17 Jun 2014 10:02:36 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 8CA83C8056; Tue, 17 Jun 2014 10:02:36 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 10:02:36 +0200 From: To: "John G. Scudder" Thread-Topic: [Idr] FW: WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14 Thread-Index: AQHPiaL1AfmZaIcXYESZq2jNHSB8apt05PFg Date: Tue, 17 Jun 2014 08:02:35 +0000 Message-ID: <32122_1402992156_539FF61C_32122_3084_2_53C29892C857584299CBF5D05346208A07163736@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com> <1376_1402929784_539F0278_1376_885_1_53C29892C857584299CBF5D05346208A0716337B@PEXCVZYM11.corporate.adroot.infra.ftgroup> <93D9A082-5E9E-4C39-8E5B-2C6616B04516@juniper.net> In-Reply-To: <93D9A082-5E9E-4C39-8E5B-2C6616B04516@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.16.93030 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/804yWV7V1WAYwcOspw6MxIDKLxk Cc: idr wg Subject: Re: [Idr] FW: WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14 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, 17 Jun 2014 08:02:47 -0000 Hi John, all Thanks for the answer and clarifications. Please see inline. > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Monday, June 16, 2= 014 10:39 PM >=20 > A couple of responses below As for the rest, I either agree or anyway don= 't > disagree, and will try to take the comments on board. Thank you. > On Jun 16, 2014, at 10:43 AM, > wrote: > > ----------------------- > > 3) > > " Flags for Address Family: > > > > This field contains bit flags relating to routes that were > > advertised with the given AFI and SAFI. > > > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+-+ > > |F|N| Reserved | > > +-+-+-+-+-+-+-+-+ > > > > The usage of second most significant bit "N" is deprecated. This b= it > > MUST be advertised as 0 and MUST be ignored upon receipt." > > > > > > > > IMHO the above text could be deleted from the document. (IINM, this flag > "N" has been tentatively defined in earlier version of _this_ draft. When= this > docs becomes RFC, there is nothing the deprecate has this flag would have > never been specified) >=20 > Given that an earlier version was published that proposed the use of this > flag, I see no downside to marking it deprecated now, just in case someone > did implement that version or somehow happens upon it. Do you see any > reason to remove it, other than orderliness? Bear in mind that "deprecate= d" > means "can eventually be reused". I agree that it's nicer and safer for pre-standard implementations. I agree that deprecating is the way to go. Thanks for the clarification. Mostly it reads strange to have an RFC define a code point and deprecate it= the line after. Eventually an alternative to avoid "polluting" the RFC for= ever may be to perform an early allocation, or some chair/AD magic to make = it deprecated without an RFC. But I'm also fine with the current text. (yet may be this deprecated alloca= tion needs to be added in the "IANA Considerations" section 6) =20 > > ----------------------- > > =A7 4. Operation > > " A BGP speaker that is willing to receive and send BGP > NOTIFICATION > > messages in Graceful mode MUST advertise the BGP Graceful > > Notification Flag "N" using the Graceful Restart Capability as > > defined in [RFC4724]. > > > > When such a BGP Speaker receives a BGP NOTIFICATION message other > > than a Hard Reset, it MUST follow the rules for the Receiving Speaker > > mentioned in Section 4.1." > > > > > > Between both sentences, IMHO a text is missing stating that this new > behavior is only activated when both speakers advertised flag "N". With > current second sentence, only the sending of this N flag would be enough = to > trigger the new behavior. >=20 > Do you see some advantage to requiring that the sender has sent the N fla= g, > before you process a graceful notification? I can see some advantage to = NOT > so requiring, for example it allows you to enable support without having = to > re-exchange Capabilities. This does call into question why we even need t= he > Capability flag, though I think things are still tidier if we have it. IMO, the capability flag looks useful to indicate to the peer how to trigge= r a full/4271 BGP session termination: - if both BGP speaker supports gr-notification, a Hard Reset must be used - if one speaker does not support gr-notification, a regular NOTIFICATION m= ust be used. So if you don't require the sender to send the N flag, you disallow the sen= der the ability to perform a full/4271 BGP session reset (since the receive= r requires a Hard Reset message and the sender is not compliant). ( Also the sender will try to initiate a RFC 4271 restart while the receive= r will initiate a 4724/gr-notification restart. Looks a priori complex to m= e, but I'm not sure this will work (e.g. the sender will a priori clear the= "F" (Forwarding State bit), no? so the receiver will still have to remove = routes from its RIB and gr-notification will not really succeed in preservi= ng the RIB)) Regards, Bruno =20 > --John ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jun 17 07:11:15 2014 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 9F6901A0037 for ; Tue, 17 Jun 2014 07:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdxqyHaLnDxi for ; Tue, 17 Jun 2014 07:11:11 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABB71A0117 for ; Tue, 17 Jun 2014 07:11:10 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: Jeffrey Haas , Chris Hall Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-13.txt Thread-Index: AQHPhzXdONcTVw9o/kqbHkQkJIcDk5tvPmsAgAAJYoCAAUbJAIADaEuAgAFhyaA= Date: Tue, 17 Jun 2014 14:11:04 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B019C5BA6@EX01.swan.local> References: <20140613183222.27662.91400.idtracker@ietfa.amsl.com> <48D0139F-CD0E-474C-A557-E18E6100157A@juniper.net> <009f01cf87df$48630760$d9291620$@highwayman.com> <20140616184725.GB31387@pfrc> In-Reply-To: <20140616184725.GB31387@pfrc> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.40.93] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/TfaSn1r7OGstYxlzIXKTzbUePNI Cc: "'idr@ietf. org'" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 14:11:12 -0000 I think we should leave the semantics out of it and Jeff I really like your= sentence:=20 > It may thus be worthwhile simplifying the section: > "If the next hop field contains a semantically incorrect address within t= he > context of deployed features and address family, treat as withdraw behavi= or > should be used."=20 However I would leave the martians out.=20 We should not dictate what addresses may be used as NH in various BGP featu= res - that would be for another document.=20 We should focus on the syntactic correctness of the NH=20 And I think Chris has some valid questions there:=20 > UNLESS, that is, there are next-hop errors which should be deemed mortal. > The NEXT_HOP attribute can be completely broken without affecting the > Parsing of NLRI. But for MP_REACH_NLRI: >=20 > (1) noting that (a) the draft treats invalid prefix > lengths as mortal errors, because they cast doubt > on the Parsing of NLRI... >=20 > ...and that (b) in an MP_REACH_NLRI, the start of > the NLRI is given by the next-hop-length.... >=20 > ...is an invalid next-hop-length a mortal error ? >=20 > (2) some Next-Hop values could be deemed "nonsense", > meaning that their presence should be considered > a symptom of a much more serious underlying > error, so... >=20 > ...are there any Next-Hop values that should be > deemed mortal errors ? >=20 > Chris adam From nobody Tue Jun 17 07:59:56 2014 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 4B3061A0008 for ; Tue, 17 Jun 2014 07:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Ridl2WSf3JSF for ; Tue, 17 Jun 2014 07:59:51 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561D01A038E for ; Tue, 17 Jun 2014 07:59:46 -0700 (PDT) Received: from hjohnson-sslvpn-nc.jnpr.net (66.129.241.17) by BLUPR05MB723.namprd05.prod.outlook.com (10.141.207.153) with Microsoft SMTP Server (TLS) id 15.0.959.24; Tue, 17 Jun 2014 14:59:45 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <32122_1402992156_539FF61C_32122_3084_2_53C29892C857584299CBF5D05346208A07163736@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Tue, 17 Jun 2014 10:59:33 -0400 Content-Transfer-Encoding: 7bit Message-ID: <16B5FA2A-CF7D-4D2C-AF52-A19A8DC44334@juniper.net> References: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com> <1376_1402929784_539F0278_1376_885_1_53C29892C857584299CBF5D05346208A0716337B@PEXCVZYM11.corporate.adroot.infra.ftgroup> <93D9A082-5E9E-4C39-8E5B-2C6616B04516@juniper.net> <32122_1402992156_539FF61C_32122_3084_2_53C29892C857584299CBF5D05346208A07163736@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.17] X-ClientProxiedBy: BY2PR02CA017.namprd02.prod.outlook.com (10.242.234.145) To BLUPR05MB723.namprd05.prod.outlook.com (10.141.207.153) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0245702D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(5423002)(87976001)(79102001)(558084003)(105586001)(81342001)(81156003)(89996001)(83072002)(104166001)(99396002)(85852003)(95666004)(33656002)(88136002)(62966002)(77096002)(93916002)(86362001)(23756003)(93886003)(42186005)(92726001)(21056001)(57306001)(20776003)(64706001)(82746002)(76482001)(47776003)(92566001)(77156001)(77982001)(101416001)(85306003)(81542001)(50466002)(69596002)(53416004)(83322001)(50226001)(4396001)(46102001)(31966008)(83716003)(87286001)(74502001)(50986999)(102836001)(66066001)(36756003)(74662001)(76176999)(80022001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB723; H:hjohnson-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vyNPnsu03EQCA0QcOXR9z2ZazxU Cc: idr wg Subject: Re: [Idr] FW: WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14 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, 17 Jun 2014 14:59:53 -0000 Apropos the N flag, you're right of course. Thanks. --John From nobody Tue Jun 17 08:11:53 2014 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 B77C01A0078 for ; Tue, 17 Jun 2014 08:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 TSbSvj_nluHL for ; Tue, 17 Jun 2014 08:11:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB03A1A0369 for ; Tue, 17 Jun 2014 08:11:36 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id EE2983243DA for ; Tue, 17 Jun 2014 17:11:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C2483238070 for ; Tue, 17 Jun 2014 17:11:34 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 17:11:34 +0200 From: To: "idr@ietf.org" Thread-Topic: Clarification required on RFC4684 Thread-Index: Ac+KPmzEzLDgWeziR7SWXjr4OsHe+Q== Date: Tue, 17 Jun 2014 15:11:34 +0000 Message-ID: <9640_1403017894_53A05AA6_9640_6243_1_9E32478DFA9976438E7A22F69B08FF92021613@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF92021613OPEXCLILM34corpor_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.17.80917 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/fXM3XrfNsdu7hz5OpuASKT-5s7Y Subject: [Idr] Clarification required on RFC4684 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, 17 Jun 2014 15:11:47 -0000 --_004_9E32478DFA9976438E7A22F69B08FF92021613OPEXCLILM34corpor_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92021613OPEXCLILM34corpor_" --_000_9E32478DFA9976438E7A22F69B08FF92021613OPEXCLILM34corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, During some testing, we detected some deprecancies in implementations leadi= ng to different behaviors in a single multi-network. The setup is as follows : Consider the following setup (to simplify) CE1 ----- (mpebgp+rtc) ---- PE1 \ RR / CE2 -----(mpebgp+rtc) ----- PE2 CE1 and CE2 are in the same AS(65000) and are both originating an RTC updat= e (65000:2:1:1) PE1 and PE2 are sending the external RTC update to RR RR has two path for the RTC NLRI 65000:2:1:1 (from PE1 & PE2). Let's consid= er that PE1 is the best path, here comes the issue : - In Implementation #1, only PE1 receives VPNv4 routes associated = with RT 1:1 - In implementation #2, both PEs are receiving VPNv4 routes Implementation #1 is causing us some issue but sounds to be inline with the= RFC, where the specification tries to find out the shortest path to the AS= to establish the flooding tree : "As indicated above, the inter-AS VPN route distribution graph, for a given route-target, is constructed by creating a directed arc on the inverse direction of received Route Target membership UPDATEs containing an NLRI of the form {origin-as#, route-target}. Inside the BGP topology of a given autonomous-system, as far as external RT membership information is concerned (route-targets where the as# is not the local as), it is easy to see that standard BGP route selection and advertisement rules [4] will allow a transit AS to create the necessary flooding state. " There is also in Section 3.2 some ambiguity introduced : "Inside the BGP topology of a given autonomous-system, as far as external RT membership information is concerned (route-targets where the as# is not the local as), it is easy to see that standard BGP route selection and advertisement rules [4] will allow a transit AS to create the necessary flooding state. " Then "Route Target membership information that is originated within the autonomous-system, however, requires more careful examination. " Implementation #2 applies 3.2 behavior to external informations (originas <= > localas), while implementation #1 applies 3.2 behavior only to locally or= iginated routes. Your thoughts on this ? What is the expected behavior ? I think we would need to fix the specification to have a more clear behavio= r described for such situation. [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert NoF phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF92021613OPEXCLILM34corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

During some testing, we detected some deprecancies i= n implementations leading to different behaviors in a single multi-network.=

 

The setup is as follows :

 

Consider the following setup (to simplify)

 

 

CE1 ----- (mpebgp+rtc) ---- PE1

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     \

     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        RR

     &nbs= p;             =             &nb= sp;            =             &nb= sp;    /

CE2 -----(mpebgp+rtc) ----- PE= 2

 

 

CE1 and CE2 are in the same AS(65000) and are both o= riginating an RTC update (65000:2:1:1)

PE1 and PE2 are sending the external RTC update to R= R

 

RR has two path for the RTC NLRI 65000:2:1:1 (from P= E1 & PE2). Let’s consider that PE1 is the best path, here comes t= he issue :

 

-     &= nbsp;    In Implementation #1, only PE1 receives VPNv4 route= s associated with RT 1:1

-     &= nbsp;    In implementation #2, both PEs are receiving VPNv4 = routes

 

Implementation #1 is causing us some issue but sound= s to be inline with the RFC, where the specification tries to find out the = shortest path to the AS to establish the flooding tree :

“As indicated above, the inter-AS VPN route distribution gr=
aph, for a
   given route-target, is constructed by creating a dir=
ected arc on the
   inverse direction of received Route Target membershi=
p UPDATEs
   containing an NLRI of the form {origin-as#, route-ta=
rget}.
 
   Inside the BGP topology of a given autonomous-system=
, as far as
   external RT membership information is concerned (rou=
te-targets where
   the as# is not the local as), it is easy to see that=
 standard BGP
   route selection and advertisement rules [4] will allow a transit AS

   to create the necessary flooding state.


 


“


 


There is also in Section 3.2 some ambiguity introduc=
ed :


 


“Inside the BGP topology of a given autonomous-system, as f=
ar as


   external RT membership information is concerned (rou=
te-targets where


   the as# is not the local as), it is easy to see that=
 standard BGP


   route selection and advertisement rules [4] will allow a transit AS

   to create the necessary flooding state.


“


 


Then 


“Route =
Target membership information that is originated within the


  =
; autonomous-system, however, requires more careful examination.=



“


 


 


Implementation #2 applies 3.2 behavior to external informations (=
originas <> localas), while implementation #1 applies 3.2 behavior on=
ly to locally originated routes.


 


Your thoughts on this ? What is the expected behavio=
r ?


 


I think we would need to fix the specification to ha=
ve a more clear behavior described for such situation.


 


 


 


3D"O=


 <=
o:p>


Stephane Litkowski


Network Architect


Orange/SCE/EQUANT/IBNF/ENDD/NDE



Orange Expert NoF=



phone:

+33 2 23 28 49 83 

mobile:

+33 6 37 86 97 52 

stephane.litkowski@orange.com



 


 


______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF92021613OPEXCLILM34corpor_-- --_004_9E32478DFA9976438E7A22F69B08FF92021613OPEXCLILM34corpor_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Tue, 17 Jun 2014 15:11:34 GMT"; modification-date="Tue, 17 Jun 2014 15:11:34 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_9E32478DFA9976438E7A22F69B08FF92021613OPEXCLILM34corpor_-- From nobody Tue Jun 17 08:31:08 2014 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 D41461A0024 for ; Tue, 17 Jun 2014 08:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 1HQvZZT9Psz5 for ; Tue, 17 Jun 2014 08:31:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E761A0061 for ; Tue, 17 Jun 2014 08:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=558; q=dns/txt; s=iport; t=1403019061; x=1404228661; h=from:to:subject:date:message-id; bh=aOHJBfzwUqRlUymbRxpnSfCtnYnCZyZAKPsrFqAUV7U=; b=QsJW7OA38F/YVyIZO/cNPokmQqrIy5nDDymdPuLFMJpvDbgJOqWU7S7a 8/hPsvqdT77o4AApLimZTsc8TfjsnVFaq8rif6JuU62jdN87xgdVyIUlu MJ2/ahb/RFAmn2p8ZXTPCSopeY4UjTXilDFJxwiwdOlzm2ARWfTNTmCNi Q=; X-IronPort-AV: E=Sophos;i="5.01,494,1400025600"; d="scan'208";a="333685132" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jun 2014 15:31:01 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5HFV0cv008467; Tue, 17 Jun 2014 15:31:00 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id F392778B; Tue, 17 Jun 2014 11:30:59 -0400 (EDT) From: erosen@cisco.com To: IDR WG X-Mailer: MH-E 8.3.1; nmh 1.5; GNU Emacs 24.3.1 Date: Tue, 17 Jun 2014 11:30:59 -0400 Message-ID: <31802.1403019059@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rqkkiDj8tOuxWP4yLL0YdKIJzck Subject: [Idr] RTC and Routes w/o RTs 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, 17 Jun 2014 15:31:08 -0000 Those who have been following the thread on "RFC4684 pedantry" ;-) may wish to look at draft-rosen-idr-rtc-no-rt-00.txt. This draft establishes a new "default behavior" for RTC which takes account of the peculiarities of SAFIs 66 and 5, while applying the old "default behavior" to other SAFIs. It also states that the specification of a new SAFI should may specify the default RTC behavior for that SAFI, and it allows implementations to override the default behaviors. The draft does not add any new BGP capabilities. Comments are welcome. From nobody Tue Jun 17 09:27:44 2014 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 0A8801A0061 for ; Tue, 17 Jun 2014 09:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 XoNV04v7-IRn for ; Tue, 17 Jun 2014 09:27:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EC3BA1A0027 for ; Tue, 17 Jun 2014 09:27:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 48134C23D; Tue, 17 Jun 2014 12:27:41 -0400 (EDT) Date: Tue, 17 Jun 2014 12:27:41 -0400 From: Jeffrey Haas To: stephane.litkowski@orange.com Message-ID: <20140617162741.GA11842@pfrc> References: <9640_1403017894_53A05AA6_9640_6243_1_9E32478DFA9976438E7A22F69B08FF92021613@OPEXCLILM34.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9640_1403017894_53A05AA6_9640_6243_1_9E32478DFA9976438E7A22F69B08FF92021613@OPEXCLILM34.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/GVfKYXyvQgGMfuObFKsY_wGWCdg Cc: "idr@ietf.org" Subject: Re: [Idr] Clarification required on RFC4684 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, 17 Jun 2014 16:27:43 -0000 Stefane, On Tue, Jun 17, 2014 at 03:11:34PM +0000, stephane.litkowski@orange.com wrote: > During some testing, we detected some deprecancies in implementations leading to different behaviors in a single multi-network. > > The setup is as follows : > Consider the following setup (to simplify) > > CE1 ----- (mpebgp+rtc) ---- PE1 > \ > RR > / > CE2 -----(mpebgp+rtc) ----- PE2 > > > CE1 and CE2 are in the same AS(65000) and are both originating an RTC update (65000:2:1:1) > PE1 and PE2 are sending the external RTC update to RR [...] > Implementation #2 applies 3.2 behavior to external informations (originas <> localas), while implementation #1 applies 3.2 behavior only to locally originated routes. > > Your thoughts on this ? What is the expected behavior ? I'll publicly own up to working on an implementation that applies the external checks within a route reflector. :-) (And IDR is a fine place to discuss what we should do for interop.) My interpretation is that this behavior is correct. Here are the premises that I'm working from that lead to this conclusion: 1. The fact that the received RT-C route is from the same source AS (65000) 2. The expectation in BGP that routing is internally consistent for a given AS. 3. A route reflector is expected to effectively be transparent. In detail: 1/2. If you surrounded CE1 and CE2 in the diagram by the usual picture of an AS-cloud, you'd normally expect a route received at the ingress for PE1 to be available internally at CE2 via internal propagation. 3. If PE1/RR/PE2 were a single router, the behavior you would expect is that one path is selected and some router (PE3, e.g.) would have its routes flow over a single path. Since the motivation was to reduce the amount of flooding, I would expect that once we have one or more RRs involved, we're effectively selecting a single flooding path to 65000 throughout the AS. ----- The above said, you still have a legitimate issue. If CE1 and CE2 aren't really "in the same AS" because the sites are disconnected and we just happen to be using BGP as the PE-CE protocol, then the premise of 1/2 above isn't helpful. One option to address this is, for a given AS (by configuration), do not enforce the path pruning. Perhaps don't enforce it by default for private AS# paths, but that might be a incorrect observation based on the example AS# above. -- Jeff From nobody Tue Jun 17 10:49:58 2014 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 84C161A03BA for ; Tue, 17 Jun 2014 10:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 TeVCtzNRyUL9 for ; Tue, 17 Jun 2014 10:49:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE421A00FF for ; Tue, 17 Jun 2014 10:49:54 -0700 (PDT) Received: from hjohnson-sslvpn-nc.jnpr.net (66.129.241.12) by BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 17 Jun 2014 17:49:52 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <20140617162741.GA11842@pfrc> Date: Tue, 17 Jun 2014 13:49:39 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <438DC44D-81FF-4897-AC14-9D53410D165F@juniper.net> References: <9640_1403017894_53A05AA6_9640_6243_1_9E32478DFA9976438E7A22F69B08FF92021613@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140617162741.GA11842@pfrc> To: Jeffrey Haas , "stephane.litkowski@orange.com DTF/DERX" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR06CA002.namprd06.prod.outlook.com (10.255.223.140) To BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0245702D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(189002)(377454003)(199002)(24454002)(164054003)(77156001)(20776003)(81156003)(64706001)(47776003)(101416001)(66066001)(83072002)(36756003)(21056001)(85852003)(80022001)(83716003)(74502001)(87286001)(105586001)(74662001)(31966008)(23726002)(89996001)(95666004)(87976001)(86362001)(92566001)(92726001)(93916002)(88136002)(79102001)(19580405001)(83322001)(19580395003)(46406003)(50226001)(69596002)(4396001)(57306001)(50466002)(76482001)(46102001)(33656002)(42186005)(77982001)(104166001)(85306003)(81342001)(81542001)(97756001)(76176999)(50986999)(53416004)(102836001)(82746002)(77096002)(62966002)(99396002)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB724; H:hjohnson-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/VfDTY-S__1ONDNp17SpUGSPd7W0 Cc: "idr@ietf.org" Subject: Re: [Idr] Clarification required on RFC4684 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, 17 Jun 2014 17:49:57 -0000 Jeff, Stephane, On Jun 17, 2014, at 12:27 PM, Jeffrey Haas wrote: > My interpretation is that this behavior is correct.=20 Mine too, for the reasons you gave. I also remember discussing this (the = multi-AS behavior, not the CE behavior) with the authors when it was in = draft. Both my reading of the spec and my recollection of the authors' = intent says this is working as designed. > The above said, you still have a legitimate issue. Yes, and as you note, it exists because EBGP as a PE-CE protocol doesn't = fit so well into the normal BGP paradigm. I'll add that also, it's not = part of the usual L3VPN paradigm to have the CE dynamically signal the = PE with its RT interests -- the usual paradigm is for it to be = provider-provisioned. For that matter, the PE-CE connection doesn't = typically use a VPN address family, and RTC only applies to VPN address = families -- though admittedly RFC 4684 is also a bit ambiguous there. = But still: This mechanism is applicable to any BGP NLRI that controls the distribution of routing information by using Route Targets, such as VPLS [9]. That said, it seems quite reasonable to add support for the use case = (which might need a little more explanation), and the approach you = describe sounds fine (though I haven't thought through any alternatives. = =20 On Jun 17, 2014, at 11:11 AM, stephane.litkowski@orange.com wrote: > I think we would need to fix the specification to have a more clear = behavior described for such situation. Seems as though a short draft that updates 4684 to cover this use case = would be a good approach. Thanks, --John From nobody Tue Jun 17 20:56:12 2014 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 03B9F1A021A for ; Tue, 17 Jun 2014 20:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 rVF2fiZCt8MN for ; Tue, 17 Jun 2014 20:56:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3A51A0219 for ; Tue, 17 Jun 2014 20:56:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIN86381; Wed, 18 Jun 2014 03:56:00 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 04:55:59 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 11:55:52 +0800 From: "Dongjie (Jimmy)" To: "erosen@cisco.com" , IDR WG Thread-Topic: [Idr] RTC and Routes w/o RTs Thread-Index: AQHPikE1uxORjU3KHU2GZiVfRBXfd5t2LztQ Date: Wed, 18 Jun 2014 03:55:51 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273367C6B5@nkgeml512-mbx.china.huawei.com> References: <31802.1403019059@erosen-lnx> In-Reply-To: <31802.1403019059@erosen-lnx> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/yDM6mUxO2qIGxvvJhNRtuVIYAG0 Subject: Re: [Idr] RTC and Routes w/o RTs 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, 18 Jun 2014 03:56:11 -0000 Hi Eric,=20 Thanks for the information. Here are some comments on this new draft. 1. In Section 1, Paragraph 2, it says: "In [RFC4684] it is implicitly assumed that RTC will only by applied to AFI= /SAFIs where all the routes carry RTs." This may not be quite accurate. In RFC 4684 the RTC capability is negotiate= d between the BGP speakers for the whole BGP session, not for specific AFI/= SAFIs. Thus RTC should apply to ANY route which use RT to control the distr= ibution, unless some knob is used to control the applicability of RTC. In a= nother word, RFC 4684 does not specify AFI/SAFI specific behaviors. Thus if this draft propose some AFI/SAFI specific RTC behavior update, do w= e need some specification to make the RTC mechanism AFI/SAFI specific first= ? 2. This draft does not define new capability for the new "default behaviors= ", then in deployment how could we know whether a BGP speaker supports the = "default behaviors" in this draft or not? Best regards, Jie > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of erosen@cisco.com > Sent: Tuesday, June 17, 2014 11:31 PM > To: IDR WG > Subject: [Idr] RTC and Routes w/o RTs >=20 > Those who have been following the thread on "RFC4684 pedantry" ;-) may wi= sh > to look at draft-rosen-idr-rtc-no-rt-00.txt. >=20 > This draft establishes a new "default behavior" for RTC which takes accou= nt of > the peculiarities of SAFIs 66 and 5, while applying the old "default beha= vior" to > other SAFIs. It also states that the specification of a new SAFI should = may > specify the default RTC behavior for that SAFI, and it allows implementat= ions to > override the default behaviors. >=20 > The draft does not add any new BGP capabilities. >=20 > Comments are welcome. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jun 18 00:49:43 2014 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 918AC1A008B for ; Wed, 18 Jun 2014 00:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DkXJgBrVUhl3 for ; Wed, 18 Jun 2014 00:49:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1A11A005D for ; Wed, 18 Jun 2014 00:49:40 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 75F582DC072; Wed, 18 Jun 2014 09:49:38 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 55249238048; Wed, 18 Jun 2014 09:49:38 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Wed, 18 Jun 2014 09:49:38 +0200 From: To: "John G. Scudder" , Jeffrey Haas Thread-Topic: [Idr] Clarification required on RFC4684 Thread-Index: Ac+KPmzEzLDgWeziR7SWXjr4OsHe+f//872AgAAW54D//vSj8A== Date: Wed, 18 Jun 2014 07:49:37 +0000 Message-ID: <15719_1403077778_53A14492_15719_4102_1_9E32478DFA9976438E7A22F69B08FF92021A04@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <9640_1403017894_53A05AA6_9640_6243_1_9E32478DFA9976438E7A22F69B08FF92021613@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140617162741.GA11842@pfrc> <438DC44D-81FF-4897-AC14-9D53410D165F@juniper.net> In-Reply-To: <438DC44D-81FF-4897-AC14-9D53410D165F@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.18.34819 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/pLRlRTrCDNoWoz-u-eaHo_Nnb1c Cc: "idr@ietf.org" Subject: Re: [Idr] Clarification required on RFC4684 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, 18 Jun 2014 07:49:42 -0000 Hi John, and Jeff, Thanks for your feedback ... The fact is that with DC interconnection to VPN network, MPLS VPN interconn= ection with CE is more and more used and as you pointed, CE in VPN environm= ents may use the same private AS numbering even if not really part of the s= ame AS. I will initiate a short draft to describe this use case. Best Regards, Stephane -----Original Message----- From: John G. Scudder [mailto:jgs@juniper.net]=20 Sent: Tuesday, June 17, 2014 19:50 To: Jeffrey Haas; LITKOWSKI Stephane SCE/IBNF Cc: idr@ietf.org Subject: Re: [Idr] Clarification required on RFC4684 Jeff, Stephane, On Jun 17, 2014, at 12:27 PM, Jeffrey Haas wrote: > My interpretation is that this behavior is correct.=20 Mine too, for the reasons you gave. I also remember discussing this (the mu= lti-AS behavior, not the CE behavior) with the authors when it was in draft= . Both my reading of the spec and my recollection of the authors' intent sa= ys this is working as designed. > The above said, you still have a legitimate issue. Yes, and as you note, it exists because EBGP as a PE-CE protocol doesn't fi= t so well into the normal BGP paradigm. I'll add that also, it's not part o= f the usual L3VPN paradigm to have the CE dynamically signal the PE with it= s RT interests -- the usual paradigm is for it to be provider-provisioned. = For that matter, the PE-CE connection doesn't typically use a VPN address f= amily, and RTC only applies to VPN address families -- though admittedly RF= C 4684 is also a bit ambiguous there. But still: This mechanism is applicable to any BGP NLRI that controls the distribution of routing information by using Route Targets, such as VPLS [9]. That said, it seems quite reasonable to add support for the use case (which= might need a little more explanation), and the approach you describe sound= s fine (though I haven't thought through any alternatives.=20=20 On Jun 17, 2014, at 11:11 AM, stephane.litkowski@orange.com wrote: > I think we would need to fix the specification to have a more clear behav= ior described for such situation. Seems as though a short draft that updates 4684 to cover this use case woul= d be a good approach. Thanks, --John ___________________________________________________________________________= ______________________________________________ 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 Wed Jun 18 02:03:00 2014 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 4BE591A008E for ; Wed, 18 Jun 2014 02:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 jkA64AJ17nHK for ; Wed, 18 Jun 2014 02:02:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2731A008B for ; Wed, 18 Jun 2014 02:02:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIO13303; Wed, 18 Jun 2014 09:02:55 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 10:02:53 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 17:02:47 +0800 From: "Dongjie (Jimmy)" To: "stephane.litkowski@orange.com" , "John G. Scudder" , Jeffrey Haas Thread-Topic: [Idr] Clarification required on RFC4684 Thread-Index: Ac+KPmzEzLDgWeziR7SWXjr4OsHe+f//jyiAgAAW54CAAOqvgP//dDvg Date: Wed, 18 Jun 2014 09:02:47 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273367C798@nkgeml512-mbx.china.huawei.com> References: <9640_1403017894_53A05AA6_9640_6243_1_9E32478DFA9976438E7A22F69B08FF92021613@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140617162741.GA11842@pfrc> <438DC44D-81FF-4897-AC14-9D53410D165F@juniper.net> <15719_1403077778_53A14492_15719_4102_1_9E32478DFA9976438E7A22F69B08FF92021A04@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <15719_1403077778_53A14492_15719_4102_1_9E32478DFA9976438E7A22F69B08FF92021A04@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/unKX316vWlzlYg0fpLwJdAjx2hE Cc: "idr@ietf.org" Subject: Re: [Idr] Clarification required on RFC4684 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, 18 Jun 2014 09:02:59 -0000 Hi Stephane, John and Jeff,=20 Agree that a short draft is needed to clarify this. And if the CEs use the = same private AS number, then AS substitution may be needed to make sure the= RT membership route is not discarded by the CE so that VPN routes can be r= eceived by all the PEs. And a similar case can happen in networks with hierarchical RRs, as shown i= n the figure below: PE1---RR2 \ \ =20 PE1- RR1 \ / \ / RR3 / / PE2- RR1 is level-1 RR, and RR2 and RR3 are level-2 RRs. 1. All the PEs advertise RTC route of RT-X to their connecting RRs. 2. RR2 and RR3 select the best RTC route, add their cluster_id to the clust= er_list and advertise the RTC route to RR1 respectively.=20 3. RR1 selects one RTC route as best (let's say RTC route from RR2), adds i= ts cluster_id into the cluster_list and advertises it to RR2 and RR3.=20 4. Then RR2 would receive the RTC route from RR1 with its own cluster_id in= the cluster_list and will drop this RTC route. 5. As a result, RR2 will not advertise VPN routes with RT-X to RR1.=20 We are working on a short draft to update the RTC behavior to cover this hi= erarchical RR case. Best regards, Jie > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of > stephane.litkowski@orange.com > Sent: Wednesday, June 18, 2014 3:50 PM > To: John G. Scudder; Jeffrey Haas > Cc: idr@ietf.org > Subject: Re: [Idr] Clarification required on RFC4684 >=20 > Hi John, and Jeff, >=20 > Thanks for your feedback ... > The fact is that with DC interconnection to VPN network, MPLS VPN > interconnection with CE is more and more used and as you pointed, CE in V= PN > environments may use the same private AS numbering even if not really par= t of > the same AS. >=20 > I will initiate a short draft to describe this use case. >=20 >=20 > Best Regards, >=20 > Stephane >=20 >=20 > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Tuesday, June 17, 2014 19:50 > To: Jeffrey Haas; LITKOWSKI Stephane SCE/IBNF > Cc: idr@ietf.org > Subject: Re: [Idr] Clarification required on RFC4684 >=20 > Jeff, Stephane, >=20 > On Jun 17, 2014, at 12:27 PM, Jeffrey Haas wrote: >=20 > > My interpretation is that this behavior is correct. >=20 > Mine too, for the reasons you gave. I also remember discussing this (the > multi-AS behavior, not the CE behavior) with the authors when it was in d= raft. > Both my reading of the spec and my recollection of the authors' intent sa= ys this > is working as designed. >=20 > > The above said, you still have a legitimate issue. >=20 > Yes, and as you note, it exists because EBGP as a PE-CE protocol doesn't = fit so > well into the normal BGP paradigm. I'll add that also, it's not part of t= he usual > L3VPN paradigm to have the CE dynamically signal the PE with its RT inter= ests -- > the usual paradigm is for it to be provider-provisioned. For that matter,= the > PE-CE connection doesn't typically use a VPN address family, and RTC only > applies to VPN address families -- though admittedly RFC 4684 is also a b= it > ambiguous there. But still: >=20 > This mechanism is applicable to any BGP NLRI that controls the > distribution of routing information by using Route Targets, such as > VPLS [9]. >=20 > That said, it seems quite reasonable to add support for the use case (whi= ch > might need a little more explanation), and the approach you describe soun= ds > fine (though I haven't thought through any alternatives. >=20 > On Jun 17, 2014, at 11:11 AM, stephane.litkowski@orange.com wrote: >=20 > > I think we would need to fix the specification to have a more clear beh= avior > described for such situation. >=20 > Seems as though a short draft that updates 4684 to cover this use case wo= uld > be a good approach. >=20 > Thanks, >=20 > --John >=20 > ________________________________________________________________ > _________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used > or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jun 18 06:27:16 2014 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 179411A0217 for ; Wed, 18 Jun 2014 06:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 DH0u5UQLP95P for ; Wed, 18 Jun 2014 06:27:10 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 69AAA1A0212 for ; Wed, 18 Jun 2014 06:27:10 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 189EDC27E; Wed, 18 Jun 2014 09:27:10 -0400 (EDT) Date: Wed, 18 Jun 2014 09:27:10 -0400 From: Jeffrey Haas To: "Dongjie (Jimmy)" Message-ID: <20140618132710.GG11842@pfrc> References: <31802.1403019059@erosen-lnx> <76CD132C3ADEF848BD84D028D243C9273367C6B5@nkgeml512-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273367C6B5@nkgeml512-mbx.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/6DPaBujLjUk9TPrfU0zpNUJp0vQ Cc: IDR WG , "erosen@cisco.com" Subject: Re: [Idr] RTC and Routes w/o RTs 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, 18 Jun 2014 13:27:15 -0000 Jie, On Wed, Jun 18, 2014 at 03:55:51AM +0000, Dongjie (Jimmy) wrote: > 2. This draft does not define new capability for the new "default behaviors", then in deployment how could we know whether a BGP speaker supports the "default behaviors" in this draft or not? The routers that care about whether this is present in the network or not may be multiple BGP hops away. I don't think a capability is terribly helpful here. More to the point, this becomes akin to policy. Policy isn't generally signaled. -- Jeff From nobody Wed Jun 18 07:32:23 2014 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 34CA01A0297 for ; Wed, 18 Jun 2014 07:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 KKXJV6CYNFz3 for ; Wed, 18 Jun 2014 07:32:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC741A0292 for ; Wed, 18 Jun 2014 07:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1327; q=dns/txt; s=iport; t=1403101938; x=1404311538; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=/4Gg6I2geJU3sVI72Qz2GQILzig02CdtqqtTM4usA70=; b=EN7vL47SIun/JzOKjnQxEHw6JimJjRQvbEgkkZqVUjD8Bl94V88lvNFB u7semvPSjuf+IEl95CFP1oviguaHqY3gjEG33iREMP3DfduOewmy5Dh7/ WkE89T21FY+oIrqEw6P3C2bSMBXDHEFzJCAdLcbstJdzkWb6gRRTxcHXt U=; X-IronPort-AV: E=Sophos;i="5.01,501,1400025600"; d="scan'208";a="334002392" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jun 2014 14:32:18 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5IEWIUj004519; Wed, 18 Jun 2014 14:32:18 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id D5727769; Wed, 18 Jun 2014 10:32:17 -0400 (EDT) From: Eric Rosen To: "Dongjie (Jimmy)" In-reply-to: Your message of Wed, 18 Jun 2014 03:55:51 -0000. <76CD132C3ADEF848BD84D028D243C9273367C6B5@nkgeml512-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8610.1403101937.1@erosen-lnx> Date: Wed, 18 Jun 2014 10:32:17 -0400 Message-ID: <8611.1403101937@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/LkLNBcn0qC0r425X7JXh1x4a5-k Cc: IDR WG Subject: Re: [Idr] RTC and Routes w/o RTs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 14:32:23 -0000 > In RFC 4684 the RTC capability is negotiated between the BGP speakers for > the whole BGP session, not for specific AFI/SAFIs. The capability just indicates that updates of AFI/SAFI 1/132 can be sent and received. It's only real purpose is to prevent a BGP speaker from sending 1/132 updates to a peer that can't handle them. > Thus RTC should apply to ANY route which use RT to control the > distribution, The discussion has revealed a few cases where RTC doesn't seem to do the right thing, and the purpose of the draft is to establish default behaviors that make it more likely for the right thing to happen. (The "right thing" being that RTC passes routes that need to pass in order for proper operation, and RTC only filters routes that can be filtered without impairing proper operation.) > This draft does not define new capability for the new "default behaviors", > then in deployment how could we know whether a BGP speaker supports the > "default behaviors" in this draft or not? To use RTC, the desired behavior (which is not necessarily the default behavior) has to be supported throughout the network. A per-session mechanism like Capability isn't really helpful in determining whether all the network's BGP speakers support a particular RTC behavior for a particular AFI/SAFI. From nobody Thu Jun 19 01:58:26 2014 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 CFA5F1A007C for ; Thu, 19 Jun 2014 01:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rQj81ojIKlEN for ; Thu, 19 Jun 2014 01:58:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F9B1A00B8 for ; Thu, 19 Jun 2014 01:58:22 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 570391901FF; Thu, 19 Jun 2014 10:58:21 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 2F8BF158052; Thu, 19 Jun 2014 10:58:21 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 19 Jun 2014 10:58:21 +0200 From: To: "John G. Scudder" , Jeffrey Haas Thread-Topic: [Idr] Clarification required on RFC4684 Thread-Index: Ac+KPmzEzLDgWeziR7SWXjr4OsHe+f//872AgAAW54D//U5fMA== Date: Thu, 19 Jun 2014 08:58:21 +0000 Message-ID: <12960_1403168301_53A2A62D_12960_16634_1_9E32478DFA9976438E7A22F69B08FF920220EF@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <9640_1403017894_53A05AA6_9640_6243_1_9E32478DFA9976438E7A22F69B08FF92021613@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140617162741.GA11842@pfrc> <438DC44D-81FF-4897-AC14-9D53410D165F@juniper.net> In-Reply-To: <438DC44D-81FF-4897-AC14-9D53410D165F@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.19.30021 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/3QXhxP5VORKqH_rDhFTteOGbXj8 Cc: "idr@ietf.org" Subject: Re: [Idr] Clarification required on RFC4684 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, 19 Jun 2014 08:58:25 -0000 Here is our draft proposal : A new version of I-D, draft-litkowski-idr-rtc-interas-00.txt has been successfully submitted by Stephane Litkowski and posted to the IET= F repository. Name: draft-litkowski-idr-rtc-interas Revision: 00 Title: Inter Domain considerations for Constrained Route distribution Document date: 2014-06-18 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-litkowski-idr-rtc= -interas-00.txt Status: https://datatracker.ietf.org/doc/draft-litkowski-idr-rtc-in= teras/ Htmlized: http://tools.ietf.org/html/draft-litkowski-idr-rtc-interas-= 00 Abstract: [RFC4684] defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information in order to limit the propagation of Virtual Private Networks (VPN) Network Layer Reachability Information (NLRI). [RFC4684] addresses both intra domain and inter domain distributions. Based on operational deployments, the current distribution model defined in [RFC4684] may cause some issue in specific scenarios. This document refines the route distribution rules for inter domain NLRIs in order to address these specific scenarios. =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 -----Original Message----- From: John G. Scudder [mailto:jgs@juniper.net]=20 Sent: Tuesday, June 17, 2014 19:50 To: Jeffrey Haas; LITKOWSKI Stephane SCE/IBNF Cc: idr@ietf.org Subject: Re: [Idr] Clarification required on RFC4684 Jeff, Stephane, On Jun 17, 2014, at 12:27 PM, Jeffrey Haas wrote: > My interpretation is that this behavior is correct.=20 Mine too, for the reasons you gave. I also remember discussing this (the mu= lti-AS behavior, not the CE behavior) with the authors when it was in draft= . Both my reading of the spec and my recollection of the authors' intent sa= ys this is working as designed. > The above said, you still have a legitimate issue. Yes, and as you note, it exists because EBGP as a PE-CE protocol doesn't fi= t so well into the normal BGP paradigm. I'll add that also, it's not part o= f the usual L3VPN paradigm to have the CE dynamically signal the PE with it= s RT interests -- the usual paradigm is for it to be provider-provisioned. = For that matter, the PE-CE connection doesn't typically use a VPN address f= amily, and RTC only applies to VPN address families -- though admittedly RF= C 4684 is also a bit ambiguous there. But still: This mechanism is applicable to any BGP NLRI that controls the distribution of routing information by using Route Targets, such as VPLS [9]. That said, it seems quite reasonable to add support for the use case (which= might need a little more explanation), and the approach you describe sound= s fine (though I haven't thought through any alternatives.=20=20 On Jun 17, 2014, at 11:11 AM, stephane.litkowski@orange.com wrote: > I think we would need to fix the specification to have a more clear behav= ior described for such situation. Seems as though a short draft that updates 4684 to cover this use case woul= d be a good approach. Thanks, --John ___________________________________________________________________________= ______________________________________________ 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 Jun 19 19:54:59 2014 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 4063D1A0248 for ; Thu, 19 Jun 2014 19:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 6pEYyIgy0A6J for ; Thu, 19 Jun 2014 19:54:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417961A01A5 for ; Thu, 19 Jun 2014 19:54:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFP72390; Fri, 20 Jun 2014 02:54:52 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Jun 2014 03:54:50 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 20 Jun 2014 10:54:45 +0800 From: "Dongjie (Jimmy)" To: "idr@ietf.org" Thread-Topic: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPA Date: Fri, 20 Jun 2014 02:54:45 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/V-Ikj1vmAsAWFRTtrfqwRvq6YDE Subject: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 02:54:56 -0000 SGkgYWxsLCANCg0KVGhpcyBpcyBhIHNob3J0IGRyYWZ0IHRvIG1ha2UgUlRDIGFwcGxpY2FibGUg aW4gaGllcmFyY2hpY2FsIFJSIHNjZW5hcmlvLg0KDQpDb21tZW50cyBhcmUgd2VsY29tZS4NCg0K QmVzdCByZWdhcmRzLA0KSmllDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gDQo+ IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJy LTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppZSBEb25nIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1kb25n LWlkci1ydGMtaGllcmFyY2hpY2FsLXJyDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCUV4dGVu c2lvbnMgdG8gUlQtQ29uc3RyYWluIGluIEhpZXJhcmNoaWNhbCBSb3V0ZSBSZWZsZWN0aW9uDQo+ IFNjZW5hcmlvcw0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTA2LTE5DQo+IEdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJNQ0KPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAu dHh0DQo+IFN0YXR1czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt ZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci8NCj4gSHRtbGl6ZWQ6DQo+IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDANCj4g DQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhlIFJvdXRlIFRhcmdldCAoUlQpIENvbnN0cmFpbiBt ZWNoYW5pc20gc3BlY2lmaWVkIGluIFJGQyA0Njg0IGlzDQo+ICAgIHVzZWQgdG8gYnVpbGQgYSBy b3V0ZSBkaXN0cmlidXRpb24gZ3JhcGggaW4gb3JkZXIgdG8gcmVzdHJpY3QgdGhlDQo+ICAgIHBy b3BhZ2F0aW9uIG9mIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrIChWUE4pIHJvdXRlcy4gIEluIG5l dHdvcmsNCj4gICAgc2NlbmFyaW9zIHdoZXJlIGhpZXJhcmNoaWNhbCByb3V0ZSByZWZsZWN0aW9u IChSUikgaXMgdXNlZCwgdGhlDQo+ICAgIGV4aXN0aW5nIFJULUNvbnN0cmFpbiBtZWNoYW5pc20g Y2Fubm90IGJ1aWxkIGEgY29ycmVjdCByb3V0ZQ0KPiAgICBkaXN0cmlidXRpb24gZ3JhcGguICBU aGlzIGRvY3VtZW50IHJlZmluZXMgdGhlIHJvdXRlIGRpc3RyaWJ1dGlvbg0KPiAgICBydWxlcyBv ZiBSVC1Db25zdHJhaW4gdG8gYWRkcmVzcyB0aGUgaGllcmFyY2hpY2FsIFJSIHNjZW5hcmlvcy4N Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Jun 20 02:27:35 2014 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 662D51B279C for ; Fri, 20 Jun 2014 02:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM6t9CsRlZsG for ; Fri, 20 Jun 2014 02:27:31 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67F21A035E for ; Fri, 20 Jun 2014 02:27:31 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id c1so571406igq.0 for ; Fri, 20 Jun 2014 02:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HD8ZxhPnDSFO4XSJDCN+4kMoIicd9cVEiGylFWui0gU=; b=jhs6C2/wRrCinIJbsin+vin/3T5CaqmqbTXCNglCVKLrzSbZifgizxSEguuQ8ppdjY r/UHJWyIMQ5nELkWBIhJm48F5QM338olPXYgwOtXzYInc/bI5jqXhe9y665Xt0E28xuu dZjbkC7CWOWy5ul/ihFmTxClQ0K0ez1911KYEyQu3Z64pPL1zN/PLBBr/XLFWwxh2Bmd UvoZvQiN5d7n/ri/IwU7XZGiRhL998qM/713YDChEDVeYKUVKMNRzkSFcv5KQuw4MJ91 7crxl+PmPyHn75+DG3Jnj5h+d0L+GKEwoHUgp2r+jGUcfyTceIjNP6sanCkyj9JqM1pc HGBA== MIME-Version: 1.0 X-Received: by 10.50.98.100 with SMTP id eh4mr2751959igb.9.1403256451085; Fri, 20 Jun 2014 02:27:31 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 20 Jun 2014 02:27:31 -0700 (PDT) In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> Date: Fri, 20 Jun 2014 11:27:31 +0200 X-Google-Sender-Auth: ve2cARnHGgSqlgTIzeHIv_0RHis Message-ID: From: Robert Raszuk To: "Dongjie (Jimmy)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/C5PF4RRbbr2pySOsnhZkvEAkits Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 09:27:33 -0000 Hello Jie, Please let me understand why instead of defining new BGP term of "the most disjoint alternative route" between RR-1 and RR-2 and between RR-1 and RR-3 you would not simply run add-paths on the RTC address family ? I believe that even add-paths = 2 where next hop is different on the set of advertised paths will solve your issue. Likewise if add-paths is not supported on any of those RRs in question one can also fix the scenario by using concept of diverse-path (RFC 6774) without any additional changes to BGP advertisement machinery on BGP route reflectors. Isn't it always an advantage to use existing mechanism to solve potential deployment problems ? Comments ? Best regards, R. On Fri, Jun 20, 2014 at 4:54 AM, Dongjie (Jimmy) wrote: > Hi all, > > This is a short draft to make RTC applicable in hierarchical RR scenario. > > Comments are welcome. > > Best regards, > Jie > >> -----Original Message----- >> >> A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt >> has been successfully submitted by Jie Dong and posted to the IETF repository. >> >> Name: draft-dong-idr-rtc-hierarchical-rr >> Revision: 00 >> Title: Extensions to RT-Constrain in Hierarchical Route Reflection >> Scenarios >> Document date: 2014-06-19 >> Group: Individual Submission >> Pages: 5 >> URL: >> http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-rr-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ >> Htmlized: >> http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 >> >> >> Abstract: >> The Route Target (RT) Constrain mechanism specified in RFC 4684 is >> used to build a route distribution graph in order to restrict the >> propagation of Virtual Private Network (VPN) routes. In network >> scenarios where hierarchical route reflection (RR) is used, the >> existing RT-Constrain mechanism cannot build a correct route >> distribution graph. This document refines the route distribution >> rules of RT-Constrain to address the hierarchical RR scenarios. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jun 20 05:03:52 2014 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 340F21A0373 for ; Fri, 20 Jun 2014 05:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 A4aaKIAv2MAK for ; Fri, 20 Jun 2014 05:03:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4C11A0114 for ; Fri, 20 Jun 2014 05:03:45 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id ADB801B82D8; Fri, 20 Jun 2014 14:03:41 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 924CF384055; Fri, 20 Jun 2014 14:03:41 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 14:03:41 +0200 From: To: "Dongjie (Jimmy)" , "idr@ietf.org" Thread-Topic: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgACZ1UA= Date: Fri, 20 Jun 2014 12:03:40 +0000 Message-ID: <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.20.19 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/6ZJ51puF468_jmQgWYAT47-Re6E Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 12:03:48 -0000 Hi Jie, Why not just applying the same behavior as for Originator ID for cluster li= st ? So erasing it, and putting RR Cluster ID only in Clist ... Is there some concern about update loop between RRs in RTC scenario that I = missed ? Stephane -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) Sent: Friday, June 20, 2014 04:55 To: idr@ietf.org Subject: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarch= ical-rr-00.txt Hi all,=20 This is a short draft to make RTC applicable in hierarchical RR scenario. Comments are welcome. Best regards, Jie > -----Original Message----- >=20 > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > has been successfully submitted by Jie Dong and posted to the IETF reposi= tory. >=20 > Name: draft-dong-idr-rtc-hierarchical-rr > Revision: 00 > Title: Extensions to RT-Constrain in Hierarchical Route Reflection > Scenarios > Document date: 2014-06-19 > Group: Individual Submission > Pages: 5 > URL: > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-rr > -00.txt > Status: > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ > Htmlized: > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 >=20 >=20 > Abstract: > The Route Target (RT) Constrain mechanism specified in RFC 4684 is > used to build a route distribution graph in order to restrict the > propagation of Virtual Private Network (VPN) routes. In network > scenarios where hierarchical route reflection (RR) is used, the > existing RT-Constrain mechanism cannot build a correct route > distribution graph. This document refines the route distribution > rules of RT-Constrain to address the hierarchical RR scenarios. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ 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 Fri Jun 20 05:08:16 2014 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 B55FB1A0645 for ; Fri, 20 Jun 2014 05:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g3Z7l_uPvGT for ; Fri, 20 Jun 2014 05:08:11 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52651AD6B0 for ; Fri, 20 Jun 2014 05:08:07 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id rl12so3193580iec.11 for ; Fri, 20 Jun 2014 05:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NgbgpKPwxDnq7hzVgUukN5RNC+bfG4OowAra/tf0614=; b=ok57AWRlsQwlFdl78hQOcDoUMVTLxR61186m5Ut9rF3P7ZkNigfiMTzxh99kz0kAzV aM2lTD9kZ9vCtyHXwJsSajcEvEcTG8Apju+xxenymmZ9/QlkLG2nes9jOIMWx/9Tr0JS 4CjKeIsqRMTSGq7Y6ybnYKjQnF26Z5pZNT3RzxvaJqMj8ql1e9OI3ssHtOyI08k3QRz6 jNSeFhVdS6yHd9pxZZef+VohFowiW/fEAs8QF32r00LbPjtU8F34HyYrfxVHZwtcwSrX npaBf7zYkwWzt+QoEPfQKVYjbLN84UccLevtUdN/wwQ+2Iu5cLhfIrB8L9ehhODhyl7f tofQ== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr3764947igb.21.1403266087287; Fri, 20 Jun 2014 05:08:07 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 20 Jun 2014 05:08:07 -0700 (PDT) In-Reply-To: <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Fri, 20 Jun 2014 14:08:07 +0200 X-Google-Sender-Auth: OnRxGH7yWmBw_Qi_2uHhG2nqkLA Message-ID: From: Robert Raszuk To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/SwYIvjHOrdu7K62v_MViCtsGElA Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 12:08:12 -0000 What happens if RR-2 has session with RR-3 - on purpose or by mistake ? I would not go that far ... Cheers, R. On Fri, Jun 20, 2014 at 2:03 PM, wrote: > Hi Jie, > > Why not just applying the same behavior as for Originator ID for cluster list ? So erasing it, and putting RR Cluster ID only in Clist ... > Is there some concern about update loop between RRs in RTC scenario that I missed ? > > > Stephane > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) > Sent: Friday, June 20, 2014 04:55 > To: idr@ietf.org > Subject: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt > > Hi all, > > This is a short draft to make RTC applicable in hierarchical RR scenario. > > Comments are welcome. > > Best regards, > Jie > >> -----Original Message----- >> >> A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt >> has been successfully submitted by Jie Dong and posted to the IETF repository. >> >> Name: draft-dong-idr-rtc-hierarchical-rr >> Revision: 00 >> Title: Extensions to RT-Constrain in Hierarchical Route Reflection >> Scenarios >> Document date: 2014-06-19 >> Group: Individual Submission >> Pages: 5 >> URL: >> http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-rr >> -00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ >> Htmlized: >> http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 >> >> >> Abstract: >> The Route Target (RT) Constrain mechanism specified in RFC 4684 is >> used to build a route distribution graph in order to restrict the >> propagation of Virtual Private Network (VPN) routes. In network >> scenarios where hierarchical route reflection (RR) is used, the >> existing RT-Constrain mechanism cannot build a correct route >> distribution graph. This document refines the route distribution >> rules of RT-Constrain to address the hierarchical RR scenarios. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jun 20 05:44:21 2014 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 1CA341B27C4 for ; Fri, 20 Jun 2014 05:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hpvow204L_Ah for ; Fri, 20 Jun 2014 05:44:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9553A1B27B1 for ; Fri, 20 Jun 2014 05:44:13 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id C5D781B8156; Fri, 20 Jun 2014 14:44:11 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id A527F180054; Fri, 20 Jun 2014 14:44:11 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 14:44:11 +0200 From: To: Robert Raszuk Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgACZ1UD//+BjgIAAJWlw Date: Fri, 20 Jun 2014 12:44:11 +0000 Message-ID: <15043_1403268251_53A42C9B_15043_2147_1_9E32478DFA9976438E7A22F69B08FF92022DEA@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.20.19 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/mMcjPnDSnqSNpFX_rK01jUYrvI8 Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 12:44:17 -0000 SSB3YXMgdGhpbmtpbmcgYWJvdXQgdGhlIHNpdHVhdGlvbiB3aGVyZSBSUiBvZiBzYW1lIGxldmVs IGhhcyBzZXNzaW9uIHRvIGVhY2ggb3RoZXIgLi4uDQpJIHRoaW5rIHRoZSBpc3N1ZSB0aGF0IHlv dSB3b3VsZCBoYXZlIHdpdGggUlRDLCBpcyBvbmx5IHVuZWZmaWNpZW50IFZQTiByb3V0ZSBkaXN0 cmlidXRpb24uDQoNCk5vcm1hbGx5IHlvdSBoYXZlIHRoZSBzYW1lIGtpbmQgb2YgaXNzdWUgd2l0 aCBPcmlnaW5hdG9ySUQgLi4uIGlzbid0IGl0ID8gDQoNCkNvbnNpZGVyaW5nIG5vdyB3ZSBoYXZl IHRoaXMgc2Vzc2lvbiBiZXR3ZWVuIFJSMiBhbmQgUlIzIGFuZCBjb25zaWRlciB0aGF0IFJSMSBk b2VzIG5vdCBoYXZlIGFueSBjbGllbnQgb3duaW5nIFZQTjEsIHRoZSBtb3JlIGVmZmljaWVudCBk aXN0cmlidXRpb24gbWV0aG9kIHdvdWxkIGJlIHRoYXQgZGlzdHJpYnV0aW9uIHRyZWUgZG9lcyBu b3QgaW5jbHVkZSBSUjEgLi4uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBP ZiBSb2JlcnQgUmFzenVrDQpTZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMTQgMTQ6MDgNClRvOiBM SVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYNCkNjOiBEb25namllIChKaW1teSk7IGlkckBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQNCg0KV2hhdCBoYXBwZW5zIGlm IFJSLTIgaGFzIHNlc3Npb24gd2l0aCBSUi0zIC0gb24gcHVycG9zZSBvciBieSBtaXN0YWtlID8N Cg0KSSB3b3VsZCBub3QgZ28gdGhhdCBmYXIgLi4uDQoNCkNoZWVycywNClIuDQoNCg0KDQpPbiBG cmksIEp1biAyMCwgMjAxNCBhdCAyOjAzIFBNLCAgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2Uu Y29tPiB3cm90ZToNCj4gSGkgSmllLA0KPg0KPiBXaHkgbm90IGp1c3QgYXBwbHlpbmcgdGhlIHNh bWUgYmVoYXZpb3IgYXMgZm9yIE9yaWdpbmF0b3IgSUQgZm9yIGNsdXN0ZXIgbGlzdCA/IFNvIGVy YXNpbmcgaXQsIGFuZCBwdXR0aW5nIFJSIENsdXN0ZXIgSUQgb25seSBpbiBDbGlzdCAuLi4NCj4g SXMgdGhlcmUgc29tZSBjb25jZXJuIGFib3V0IHVwZGF0ZSBsb29wIGJldHdlZW4gUlJzIGluIFJU QyBzY2VuYXJpbyB0aGF0IEkgbWlzc2VkID8NCj4NCj4NCj4gU3RlcGhhbmUNCj4NCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBEb25namllIChKaW1teSkNCj4gU2VudDogRnJpZGF5LCBKdW5l IDIwLCAyMDE0IDA0OjU1DQo+IFRvOiBpZHJAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0lkcl0gRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVy YXJjaGljYWwtcnItMDAudHh0DQo+DQo+IEhpIGFsbCwNCj4NCj4gVGhpcyBpcyBhIHNob3J0IGRy YWZ0IHRvIG1ha2UgUlRDIGFwcGxpY2FibGUgaW4gaGllcmFyY2hpY2FsIFJSIHNjZW5hcmlvLg0K Pg0KPiBDb21tZW50cyBhcmUgd2VsY29tZS4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBKaWUNCj4N Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pg0KPj4gQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAudHh0DQo+PiBoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppZSBEb25nIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCj4+DQo+PiBOYW1lOiAgICAgICAgIGRyYWZ0LWRvbmctaWRyLXJ0Yy1o aWVyYXJjaGljYWwtcnINCj4+IFJldmlzaW9uOiAgICAgMDANCj4+IFRpdGxlOiAgICAgICAgICAg ICAgICBFeHRlbnNpb25zIHRvIFJULUNvbnN0cmFpbiBpbiBIaWVyYXJjaGljYWwgUm91dGUgUmVm bGVjdGlvbg0KPj4gU2NlbmFyaW9zDQo+PiBEb2N1bWVudCBkYXRlOiAgICAgICAgMjAxNC0wNi0x OQ0KPj4gR3JvdXA6ICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4gUGFn ZXM6ICAgICAgICAgICAgICAgIDUNCj4+IFVSTDoNCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcg0KPj4gcg0KPj4g LTAwLnR4dA0KPj4gU3RhdHVzOg0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci8NCj4+IEh0bWxpemVkOg0KPj4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1y ci0wMA0KPj4NCj4+DQo+PiBBYnN0cmFjdDoNCj4+ICAgIFRoZSBSb3V0ZSBUYXJnZXQgKFJUKSBD b25zdHJhaW4gbWVjaGFuaXNtIHNwZWNpZmllZCBpbiBSRkMgNDY4NCBpcw0KPj4gICAgdXNlZCB0 byBidWlsZCBhIHJvdXRlIGRpc3RyaWJ1dGlvbiBncmFwaCBpbiBvcmRlciB0byByZXN0cmljdCB0 aGUNCj4+ICAgIHByb3BhZ2F0aW9uIG9mIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrIChWUE4pIHJv dXRlcy4gIEluIG5ldHdvcmsNCj4+ICAgIHNjZW5hcmlvcyB3aGVyZSBoaWVyYXJjaGljYWwgcm91 dGUgcmVmbGVjdGlvbiAoUlIpIGlzIHVzZWQsIHRoZQ0KPj4gICAgZXhpc3RpbmcgUlQtQ29uc3Ry YWluIG1lY2hhbmlzbSBjYW5ub3QgYnVpbGQgYSBjb3JyZWN0IHJvdXRlDQo+PiAgICBkaXN0cmli dXRpb24gZ3JhcGguICBUaGlzIGRvY3VtZW50IHJlZmluZXMgdGhlIHJvdXRlIGRpc3RyaWJ1dGlv bg0KPj4gICAgcnVsZXMgb2YgUlQtQ29uc3RyYWluIHRvIGFkZHJlc3MgdGhlIGhpZXJhcmNoaWNh bCBSUiBzY2VuYXJpb3MuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IFBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPj4gc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KPj4NCj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWls aW5nIGxpc3QNCj4gSWRyQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWRyDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+IENlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyANCj4gY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlm ZnVzZXMsIA0KPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIA0KPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl ciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+DQo+IFRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciANCj4g cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4NCj4gVGhhbmsgeW91Lg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91LgoK From nobody Fri Jun 20 05:53:24 2014 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 342971A0386 for ; Fri, 20 Jun 2014 05:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tJTMA0C1fFtA for ; Fri, 20 Jun 2014 05:53:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0850E1A037F for ; Fri, 20 Jun 2014 05:53:16 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 29BD318C3B2; Fri, 20 Jun 2014 14:53:14 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0A3C227C053; Fri, 20 Jun 2014 14:53:14 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 14:53:13 +0200 From: To: Robert Raszuk , "Dongjie (Jimmy)" Thread-Topic: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgABNWYCAAFpKQA== Date: Fri, 20 Jun 2014 12:53:13 +0000 Message-ID: <7940_1403268794_53A42EBA_7940_180_1_9E32478DFA9976438E7A22F69B08FF92022E0D@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.19.103021 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/pdzTXRGcDs96AQm7un7kOCIwrus Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 12:53:21 -0000 Robert, Regarding add-path or some other knob, I agree that this would work but whe= n you have a basic hierarchical RR design for VPN service, you can expect t= hat RTC works without having to tweak BGP.=20 IMO, the basic spec is really broken for this scenario and we have to addre= ss it. Best Regards, Stephane -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Friday, June 20, 2014 11:28 To: Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hier= archical-rr-00.txt Hello Jie, Please let me understand why instead of defining new BGP term of "the most = disjoint alternative route" between RR-1 and RR-2 and between RR-1 and RR-3 you would not simply run add-paths on the RTC address family ? I believe that even add-paths =3D 2 where next hop is different on the set = of advertised paths will solve your issue. Likewise if add-paths is not supported on any of those RRs in question one = can also fix the scenario by using concept of diverse-path (RFC 6774) without any additional changes to BGP advertisement machinery on BGP = route reflectors. Isn't it always an advantage to use existing mechanism to solve potential d= eployment problems ? Comments ? Best regards, R. On Fri, Jun 20, 2014 at 4:54 AM, Dongjie (Jimmy) wrot= e: > Hi all, > > This is a short draft to make RTC applicable in hierarchical RR scenario. > > Comments are welcome. > > Best regards, > Jie > >> -----Original Message----- >> >> A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt >> has been successfully submitted by Jie Dong and posted to the IETF repos= itory. >> >> Name: draft-dong-idr-rtc-hierarchical-rr >> Revision: 00 >> Title: Extensions to RT-Constrain in Hierarchical Route R= eflection >> Scenarios >> Document date: 2014-06-19 >> Group: Individual Submission >> Pages: 5 >> URL: >> http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-r >> r-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ >> Htmlized: >> http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 >> >> >> Abstract: >> The Route Target (RT) Constrain mechanism specified in RFC 4684 is >> used to build a route distribution graph in order to restrict the >> propagation of Virtual Private Network (VPN) routes. In network >> scenarios where hierarchical route reflection (RR) is used, the >> existing RT-Constrain mechanism cannot build a correct route >> distribution graph. This document refines the route distribution >> rules of RT-Constrain to address the hierarchical RR scenarios. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at tools.ie= tf.org. >> >> The IETF Secretariat > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ 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 Fri Jun 20 05:57:47 2014 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 ADE1F1A0382 for ; Fri, 20 Jun 2014 05:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af6X5f89Ylyr for ; Fri, 20 Jun 2014 05:57:45 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094281A037D for ; Fri, 20 Jun 2014 05:57:28 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id h18so471656igc.13 for ; Fri, 20 Jun 2014 05:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=T+lmR/gRH4ida2yo85CrEIH1Qzpu3PSTs3GlkJLaDlY=; b=AJ+8OIyDTOC/vMprMh+ShCuV8l2ZavARUpyxDnRah0jk2HvI1ESk2yJ/uLppHAy4Oc foZMVvyw8Cfp3aff83qtFuETW4Y39jZhHQYBBAiEfl+LdcoBKtxB3DZda9BWxBwQBtz4 zuhsefDiiTGIVQPYy9OH6YxykAiJ+YoE/wmcOPa1zBL1fk4PENHm+53bjnlkB3mewQAr M/8DhiGGoRh8owk/eY98qwULNIfHOFUZgeiXHogtcV7wHgwJYdRLH9rUFMa4dG+YQfWD 3z4Dtu88XdFWqYCHZt6aCZ5Xtf6wneYg4D02enP2RpmImbuuyFah/51o1uy7EQ0Hv9Oi RJDw== MIME-Version: 1.0 X-Received: by 10.50.62.40 with SMTP id v8mr4146942igr.21.1403269048429; Fri, 20 Jun 2014 05:57:28 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 20 Jun 2014 05:57:28 -0700 (PDT) In-Reply-To: <15043_1403268251_53A42C9B_15043_2147_1_9E32478DFA9976438E7A22F69B08FF92022DEA@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15043_1403268251_53A42C9B_15043_2147_1_9E32478DFA9976438E7A22F69B08FF92022DEA@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Fri, 20 Jun 2014 14:57:28 +0200 X-Google-Sender-Auth: 0UQkfIruin3JrammVAsGiSht2ic Message-ID: From: Robert Raszuk To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_nDP-wAkwLDYPMThYmTcdZ0r950 Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 12:57:46 -0000 Hi Stephane, I am not worried about efficiency here. Imagine worst case of three RRs in this picture having sessions to each other and each deletes and puts it's own CLUSTER LIST before sending the update out. What would stop the RTC SAFI update loop between those RRs if RRs will not be able to tell looking at the CLUSTER_LIST if they have already processed the update before ? Perhaps some implementations would indeed recognized that the same path exist already and suppress generation of new update, but even then when you have more RRs in such setup you are now depending on the timing issues. We are also subject to run into the problem (which Danny has been pointing out many times before) of sending by to clients in the same peer group all paths including his own advertisements, but now without CLUSTER_LIST due to broken (and blessed by the spec) split-horizon in RR peer groups. r. On Fri, Jun 20, 2014 at 2:44 PM, wrote: > I was thinking about the situation where RR of same level has session to each other ... > I think the issue that you would have with RTC, is only unefficient VPN route distribution. > > Normally you have the same kind of issue with OriginatorID ... isn't it ? > > Considering now we have this session between RR2 and RR3 and consider that RR1 does not have any client owning VPN1, the more efficient distribution method would be that distribution tree does not include RR1 ... > > > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk > Sent: Friday, June 20, 2014 14:08 > To: LITKOWSKI Stephane SCE/IBNF > Cc: Dongjie (Jimmy); idr@ietf.org > Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt > > What happens if RR-2 has session with RR-3 - on purpose or by mistake ? > > I would not go that far ... > > Cheers, > R. > > > > On Fri, Jun 20, 2014 at 2:03 PM, wrote: >> Hi Jie, >> >> Why not just applying the same behavior as for Originator ID for cluster list ? So erasing it, and putting RR Cluster ID only in Clist ... >> Is there some concern about update loop between RRs in RTC scenario that I missed ? >> >> >> Stephane >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) >> Sent: Friday, June 20, 2014 04:55 >> To: idr@ietf.org >> Subject: [Idr] FW: New Version Notification for >> draft-dong-idr-rtc-hierarchical-rr-00.txt >> >> Hi all, >> >> This is a short draft to make RTC applicable in hierarchical RR scenario. >> >> Comments are welcome. >> >> Best regards, >> Jie >> >>> -----Original Message----- >>> >>> A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt >>> has been successfully submitted by Jie Dong and posted to the IETF repository. >>> >>> Name: draft-dong-idr-rtc-hierarchical-rr >>> Revision: 00 >>> Title: Extensions to RT-Constrain in Hierarchical Route Reflection >>> Scenarios >>> Document date: 2014-06-19 >>> Group: Individual Submission >>> Pages: 5 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-r >>> r >>> -00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 >>> >>> >>> Abstract: >>> The Route Target (RT) Constrain mechanism specified in RFC 4684 is >>> used to build a route distribution graph in order to restrict the >>> propagation of Virtual Private Network (VPN) routes. In network >>> scenarios where hierarchical route reflection (RR) is used, the >>> existing RT-Constrain mechanism cannot build a correct route >>> distribution graph. This document refines the route distribution >>> rules of RT-Constrain to address the hierarchical RR scenarios. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> ______________________________________________________________________ >> ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Fri Jun 20 06:03:28 2014 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 D6D091B27C0 for ; Fri, 20 Jun 2014 06:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdbwNVcXUTFh for ; Fri, 20 Jun 2014 06:03:22 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2660C1A0390 for ; Fri, 20 Jun 2014 06:03:22 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id tr6so3094728ieb.24 for ; Fri, 20 Jun 2014 06:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1LeUz3XifZCNmLfCF3AYkQ1l1W1Bqn2mhxx0VLXOOyo=; b=j0ydNnGH0POpqIT3/Y9LJ4i9+iRdwxtA3UMOuQFECRpE3lM6EVl3fLNLUWFNAk0sJx IwSKkc/PAbHinPvRInrG5TCtNEkpnJxgD8ovfOYs9Xoy1jO8iAsxXwMYo3dgcZFww/fg 7TxA3l068QleFmvymvlo8qiFMeqzc1pcUrteqvvebmvWEyiJ7EJeHfdqlBd2tSnqEwBr +M3xUTxzxV2Gw6dQJU6Lw/CvV+drDsQMEiFjx11yr7p//twS09np42Jfr3u8E7MrJ6Dk q4l6pMhFoEuwrgVj5n+W1EY8aNIrSFVHjjL/l3F6tq2X9sgGJ2koR7sjwgaQ5UaAx4U/ O6Mg== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr4193185igb.21.1403269401515; Fri, 20 Jun 2014 06:03:21 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 20 Jun 2014 06:03:21 -0700 (PDT) In-Reply-To: <7940_1403268794_53A42EBA_7940_180_1_9E32478DFA9976438E7A22F69B08FF92022E0D@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <7940_1403268794_53A42EBA_7940_180_1_9E32478DFA9976438E7A22F69B08FF92022E0D@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Fri, 20 Jun 2014 15:03:21 +0200 X-Google-Sender-Auth: HKF_Km55q-nZ7SRQ_0GZjBllPKk Message-ID: From: Robert Raszuk To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/0BxQ5RGDzXtMVWjp26k-F0jG_cA Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 13:03:24 -0000 Hi Stephane, My personal believe is that hierarchical RRs is really bad idea especially for VPN cases. In VPNs RRs are the "weakest" points of route accumulation and adding hierarchy there makes the split of VPN routes based on the RTs grouping much harder. Moreover RRs now run just fine on shelf x86 machines and single box can handle easily millions of routes and thousands of sessions so I do not think hierarchy buys you much. If anything IMO we should rather focus to make sure RTC works without RRs in an automatically created full mesh ;). Cheers, R. On Fri, Jun 20, 2014 at 2:53 PM, wrote: > Robert, > > Regarding add-path or some other knob, I agree that this would work but when you have a basic hierarchical RR design for VPN service, you can expect that RTC works without having to tweak BGP. > IMO, the basic spec is really broken for this scenario and we have to address it. > > Best Regards, > > Stephane > > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk > Sent: Friday, June 20, 2014 11:28 > To: Dongjie (Jimmy) > Cc: idr@ietf.org > Subject: Re: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt > > Hello Jie, > > Please let me understand why instead of defining new BGP term of "the most disjoint alternative route" between RR-1 and RR-2 and between > RR-1 and RR-3 you would not simply run add-paths on the RTC address family ? > > I believe that even add-paths = 2 where next hop is different on the set of advertised paths will solve your issue. > > Likewise if add-paths is not supported on any of those RRs in question one can also fix the scenario by using concept of diverse-path (RFC > 6774) without any additional changes to BGP advertisement machinery on BGP route reflectors. > > Isn't it always an advantage to use existing mechanism to solve potential deployment problems ? > > Comments ? > > Best regards, > R. > > > On Fri, Jun 20, 2014 at 4:54 AM, Dongjie (Jimmy) wrote: >> Hi all, >> >> This is a short draft to make RTC applicable in hierarchical RR scenario. >> >> Comments are welcome. >> >> Best regards, >> Jie >> >>> -----Original Message----- >>> >>> A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt >>> has been successfully submitted by Jie Dong and posted to the IETF repository. >>> >>> Name: draft-dong-idr-rtc-hierarchical-rr >>> Revision: 00 >>> Title: Extensions to RT-Constrain in Hierarchical Route Reflection >>> Scenarios >>> Document date: 2014-06-19 >>> Group: Individual Submission >>> Pages: 5 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-r >>> r-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 >>> >>> >>> Abstract: >>> The Route Target (RT) Constrain mechanism specified in RFC 4684 is >>> used to build a route distribution graph in order to restrict the >>> propagation of Virtual Private Network (VPN) routes. In network >>> scenarios where hierarchical route reflection (RR) is used, the >>> existing RT-Constrain mechanism cannot build a correct route >>> distribution graph. This document refines the route distribution >>> rules of RT-Constrain to address the hierarchical RR scenarios. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Fri Jun 20 06:43:49 2014 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 DE2FE1A03A9 for ; Fri, 20 Jun 2014 06:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 sRtj0aW7OJT7 for ; Fri, 20 Jun 2014 06:43:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C3A1A03AA for ; Fri, 20 Jun 2014 06:43:40 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 8B4691B831F; Fri, 20 Jun 2014 15:43:38 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 65E52180042; Fri, 20 Jun 2014 15:43:38 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 15:43:38 +0200 From: To: Robert Raszuk Thread-Topic: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgABNWYCAAFpKQP//4gSAgAAsUfA= Date: Fri, 20 Jun 2014 13:43:37 +0000 Message-ID: <15846_1403271818_53A43A8A_15846_3285_1_9E32478DFA9976438E7A22F69B08FF92022EB1@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <7940_1403268794_53A42EBA_7940_180_1_9E32478DFA9976438E7A22F69B08FF92022E0D@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.20.19 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/k821RxNkEy8Ah3fon96M2OP7hxE Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 13:43:48 -0000 SGksDQoNCkknbSBub3QgcHVzaGluZyBmb3IgaGllcmFyY2hpY2FsIFJSIGF0IGFsbCA6KSBCdXQg SSBjYW4gaW1hZ2luZSB0aGFuIHNvbWUgcGVvcGxlIHVzZSBpdCBhcyBmb3IgSW50ZXJuZXQgbmV0 d29ya3MgLi4uLg0KDQpTdGVwaGFuZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhh bGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogRnJpZGF5LCBKdW5lIDIwLCAyMDE0IDE1OjAzDQpU bzogTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GDQpDYzogRG9uZ2ppZSAoSmltbXkpOyBpZHJA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRyXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTAwLnR4dA0KDQpIaSBTdGVw aGFuZSwNCg0KTXkgcGVyc29uYWwgYmVsaWV2ZSBpcyB0aGF0IGhpZXJhcmNoaWNhbCBSUnMgaXMg cmVhbGx5IGJhZCBpZGVhIGVzcGVjaWFsbHkgZm9yIFZQTiBjYXNlcy4gSW4gVlBOcyBSUnMgYXJl IHRoZSAid2Vha2VzdCIgcG9pbnRzIG9mIHJvdXRlIGFjY3VtdWxhdGlvbiBhbmQgYWRkaW5nIGhp ZXJhcmNoeSB0aGVyZSBtYWtlcyB0aGUgc3BsaXQgb2YgVlBOIHJvdXRlcyBiYXNlZCBvbiB0aGUg UlRzIGdyb3VwaW5nIG11Y2ggaGFyZGVyLg0KDQpNb3Jlb3ZlciBSUnMgbm93IHJ1biBqdXN0IGZp bmUgb24gc2hlbGYgeDg2IG1hY2hpbmVzIGFuZCBzaW5nbGUgYm94IGNhbiBoYW5kbGUgZWFzaWx5 IG1pbGxpb25zIG9mIHJvdXRlcyBhbmQgdGhvdXNhbmRzIG9mIHNlc3Npb25zIHNvIEkgZG8gbm90 IHRoaW5rIGhpZXJhcmNoeSBidXlzIHlvdSBtdWNoLg0KDQpJZiBhbnl0aGluZyBJTU8gd2Ugc2hv dWxkIHJhdGhlciBmb2N1cyB0byBtYWtlIHN1cmUgUlRDIHdvcmtzIHdpdGhvdXQgUlJzIGluIGFu IGF1dG9tYXRpY2FsbHkgY3JlYXRlZCBmdWxsIG1lc2ggOykuDQoNCkNoZWVycywNClIuDQoNCg0K T24gRnJpLCBKdW4gMjAsIDIwMTQgYXQgMjo1MyBQTSwgIDxzdGVwaGFuZS5saXRrb3dza2lAb3Jh bmdlLmNvbT4gd3JvdGU6DQo+IFJvYmVydCwNCj4NCj4gUmVnYXJkaW5nIGFkZC1wYXRoIG9yIHNv bWUgb3RoZXIga25vYiwgSSBhZ3JlZSB0aGF0IHRoaXMgd291bGQgd29yayBidXQgd2hlbiB5b3Ug aGF2ZSBhIGJhc2ljIGhpZXJhcmNoaWNhbCBSUiBkZXNpZ24gZm9yIFZQTiBzZXJ2aWNlLCB5b3Ug Y2FuIGV4cGVjdCB0aGF0IFJUQyB3b3JrcyB3aXRob3V0IGhhdmluZyB0byB0d2VhayBCR1AuDQo+ IElNTywgdGhlIGJhc2ljIHNwZWMgaXMgcmVhbGx5IGJyb2tlbiBmb3IgdGhpcyBzY2VuYXJpbyBh bmQgd2UgaGF2ZSB0byBhZGRyZXNzIGl0Lg0KPg0KPiBCZXN0IFJlZ2FyZHMsDQo+DQo+IFN0ZXBo YW5lDQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElkciBbbWFp bHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KPiBT ZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMTQgMTE6MjgNCj4gVG86IERvbmdqaWUgKEppbW15KQ0K PiBDYzogaWRyQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSWRyXSBGVzogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciANCj4gZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0w MC50eHQNCj4NCj4gSGVsbG8gSmllLA0KPg0KPiBQbGVhc2UgbGV0IG1lIHVuZGVyc3RhbmQgd2h5 IGluc3RlYWQgb2YgZGVmaW5pbmcgbmV3IEJHUCB0ZXJtIG9mICJ0aGUgDQo+IG1vc3QgZGlzam9p bnQgYWx0ZXJuYXRpdmUgcm91dGUiIGJldHdlZW4gUlItMSBhbmQgUlItMiBhbmQgYmV0d2Vlbg0K PiBSUi0xIGFuZCBSUi0zIHlvdSB3b3VsZCBub3Qgc2ltcGx5IHJ1biBhZGQtcGF0aHMgb24gdGhl IFJUQyBhZGRyZXNzIGZhbWlseSA/DQo+DQo+IEkgYmVsaWV2ZSB0aGF0IGV2ZW4gYWRkLXBhdGhz ID0gMiB3aGVyZSBuZXh0IGhvcCBpcyBkaWZmZXJlbnQgb24gdGhlIHNldCBvZiBhZHZlcnRpc2Vk IHBhdGhzIHdpbGwgc29sdmUgeW91ciBpc3N1ZS4NCj4NCj4gTGlrZXdpc2UgaWYgYWRkLXBhdGhz IGlzIG5vdCBzdXBwb3J0ZWQgb24gYW55IG9mIHRob3NlIFJScyBpbiBxdWVzdGlvbiANCj4gb25l IGNhbiBhbHNvIGZpeCB0aGUgc2NlbmFyaW8gYnkgdXNpbmcgY29uY2VwdCBvZiBkaXZlcnNlLXBh dGggKFJGQw0KPiA2Nzc0KSB3aXRob3V0IGFueSBhZGRpdGlvbmFsIGNoYW5nZXMgdG8gQkdQIGFk dmVydGlzZW1lbnQgbWFjaGluZXJ5IG9uIEJHUCByb3V0ZSByZWZsZWN0b3JzLg0KPg0KPiBJc24n dCBpdCBhbHdheXMgYW4gYWR2YW50YWdlIHRvIHVzZSBleGlzdGluZyBtZWNoYW5pc20gdG8gc29s dmUgcG90ZW50aWFsIGRlcGxveW1lbnQgcHJvYmxlbXMgPw0KPg0KPiBDb21tZW50cyA/DQo+DQo+ IEJlc3QgcmVnYXJkcywNCj4gUi4NCj4NCj4NCj4gT24gRnJpLCBKdW4gMjAsIDIwMTQgYXQgNDo1 NCBBTSwgRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4+IEhp IGFsbCwNCj4+DQo+PiBUaGlzIGlzIGEgc2hvcnQgZHJhZnQgdG8gbWFrZSBSVEMgYXBwbGljYWJs ZSBpbiBoaWVyYXJjaGljYWwgUlIgc2NlbmFyaW8uDQo+Pg0KPj4gQ29tbWVudHMgYXJlIHdlbGNv bWUuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4gSmllDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4NCj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZG9uZy1p ZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQNCj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEppZSBEb25nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cj4+Pg0KPj4+IE5hbWU6ICAgICAgICAgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1y cg0KPj4+IFJldmlzaW9uOiAgICAgMDANCj4+PiBUaXRsZTogICAgICAgICAgICAgICAgRXh0ZW5z aW9ucyB0byBSVC1Db25zdHJhaW4gaW4gSGllcmFyY2hpY2FsIFJvdXRlIFJlZmxlY3Rpb24NCj4+ PiBTY2VuYXJpb3MNCj4+PiBEb2N1bWVudCBkYXRlOiAgICAgICAgMjAxNC0wNi0xOQ0KPj4+IEdy b3VwOiAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+PiBQYWdlczogICAg ICAgICAgICAgICAgNQ0KPj4+IFVSTDoNCj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLQ0KPj4+IHINCj4+PiByLTAw LnR4dA0KPj4+IFN0YXR1czoNCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLw0KPj4+IEh0bWxpemVkOg0KPj4+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwt cnItMDANCj4+Pg0KPj4+DQo+Pj4gQWJzdHJhY3Q6DQo+Pj4gICAgVGhlIFJvdXRlIFRhcmdldCAo UlQpIENvbnN0cmFpbiBtZWNoYW5pc20gc3BlY2lmaWVkIGluIFJGQyA0Njg0IGlzDQo+Pj4gICAg dXNlZCB0byBidWlsZCBhIHJvdXRlIGRpc3RyaWJ1dGlvbiBncmFwaCBpbiBvcmRlciB0byByZXN0 cmljdCB0aGUNCj4+PiAgICBwcm9wYWdhdGlvbiBvZiBWaXJ0dWFsIFByaXZhdGUgTmV0d29yayAo VlBOKSByb3V0ZXMuICBJbiBuZXR3b3JrDQo+Pj4gICAgc2NlbmFyaW9zIHdoZXJlIGhpZXJhcmNo aWNhbCByb3V0ZSByZWZsZWN0aW9uIChSUikgaXMgdXNlZCwgdGhlDQo+Pj4gICAgZXhpc3Rpbmcg UlQtQ29uc3RyYWluIG1lY2hhbmlzbSBjYW5ub3QgYnVpbGQgYSBjb3JyZWN0IHJvdXRlDQo+Pj4g ICAgZGlzdHJpYnV0aW9uIGdyYXBoLiAgVGhpcyBkb2N1bWVudCByZWZpbmVzIHRoZSByb3V0ZSBk aXN0cmlidXRpb24NCj4+PiAgICBydWxlcyBvZiBSVC1Db25zdHJhaW4gdG8gYWRkcmVzcyB0aGUg aGllcmFyY2hpY2FsIFJSIHNjZW5hcmlvcy4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4g UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2YgDQo+Pj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4+DQo+Pj4gVGhlIElFVEYg U2VjcmV0YXJpYXQNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gSWRyIG1haWxpbmcgbGlzdA0KPj4gSWRyQGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+ IElkckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk cg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPg0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQo+IGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCANCj4g ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSANCj4gcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPg0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgDQo+IHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K PiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRo YW5rIHlvdS4NCj4NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Fri Jun 20 06:47:44 2014 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 237881A0354 for ; Fri, 20 Jun 2014 06:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 aqoHzdBkhYRa for ; Fri, 20 Jun 2014 06:47:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A041D1A03A9 for ; Fri, 20 Jun 2014 06:47:39 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id DFA501903C5; Fri, 20 Jun 2014 15:47:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id C13C8C805F; Fri, 20 Jun 2014 15:47:34 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 15:47:34 +0200 From: To: Robert Raszuk Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgACZ1UD//+BjgIAAJWlw///oYQCAAC8ycA== Date: Fri, 20 Jun 2014 13:47:34 +0000 Message-ID: <9950_1403272054_53A43B76_9950_3758_1_9E32478DFA9976438E7A22F69B08FF92022ED7@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15043_1403268251_53A42C9B_15043_2147_1_9E32478DFA9976438E7A22F69B08FF92022DEA@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.20.19 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/trxJOMiyaOeuo4xu2MLoXFgzHfw Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 13:47:43 -0000 SSBjb21wbGV0ZWx5IGFncmVlIHRoYXQgdG91Y2hpbmcgbG9vcCBwcmV2ZW50aW9uIG1lY2hhbmlz bSBtYXkgY2F1c2Ugc29tZSBpc3N1ZSAuLi4gDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9u IEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMTQgMTQ6 NTcNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYNCkNjOiBEb25namllIChKaW1teSk7 IGlkckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQNCg0KSGkgU3Rl cGhhbmUsDQoNCkkgYW0gbm90IHdvcnJpZWQgYWJvdXQgZWZmaWNpZW5jeSBoZXJlLg0KDQpJbWFn aW5lIHdvcnN0IGNhc2Ugb2YgdGhyZWUgUlJzIGluIHRoaXMgcGljdHVyZSBoYXZpbmcgc2Vzc2lv bnMgdG8gZWFjaCBvdGhlciBhbmQgZWFjaCBkZWxldGVzIGFuZCBwdXRzIGl0J3Mgb3duIENMVVNU RVIgTElTVCBiZWZvcmUgc2VuZGluZyB0aGUgdXBkYXRlIG91dC4NCg0KV2hhdCB3b3VsZCBzdG9w IHRoZSBSVEMgU0FGSSB1cGRhdGUgbG9vcCBiZXR3ZWVuIHRob3NlIFJScyBpZiBSUnMgd2lsbCBu b3QgYmUgYWJsZSB0byB0ZWxsIGxvb2tpbmcgYXQgdGhlIENMVVNURVJfTElTVCBpZiB0aGV5IGhh dmUgYWxyZWFkeSBwcm9jZXNzZWQgdGhlIHVwZGF0ZSBiZWZvcmUgPw0KDQpQZXJoYXBzIHNvbWUg aW1wbGVtZW50YXRpb25zIHdvdWxkIGluZGVlZCByZWNvZ25pemVkIHRoYXQgdGhlIHNhbWUgcGF0 aCBleGlzdCBhbHJlYWR5IGFuZCBzdXBwcmVzcyBnZW5lcmF0aW9uIG9mIG5ldyB1cGRhdGUsIGJ1 dCBldmVuIHRoZW4gd2hlbiB5b3UgaGF2ZSBtb3JlIFJScyBpbiBzdWNoIHNldHVwIHlvdSBhcmUg bm93IGRlcGVuZGluZyBvbiB0aGUgdGltaW5nIGlzc3Vlcy4NCg0KV2UgYXJlIGFsc28gc3ViamVj dCB0byBydW4gaW50byB0aGUgcHJvYmxlbSAod2hpY2ggRGFubnkgaGFzIGJlZW4gcG9pbnRpbmcg b3V0IG1hbnkgdGltZXMgYmVmb3JlKSAgb2YgIHNlbmRpbmcgYnkgdG8gY2xpZW50cyBpbiB0aGUg c2FtZSBwZWVyIGdyb3VwIGFsbCBwYXRocyBpbmNsdWRpbmcgaGlzIG93biBhZHZlcnRpc2VtZW50 cywgYnV0IG5vdyB3aXRob3V0IENMVVNURVJfTElTVCBkdWUgdG8gYnJva2VuIChhbmQgYmxlc3Nl ZCBieSB0aGUgc3BlYykgc3BsaXQtaG9yaXpvbiBpbiBSUiBwZWVyIGdyb3Vwcy4NCg0Kci4NCg0K DQoNCk9uIEZyaSwgSnVuIDIwLCAyMDE0IGF0IDI6NDQgUE0sICA8c3RlcGhhbmUubGl0a293c2tp QG9yYW5nZS5jb20+IHdyb3RlOg0KPiBJIHdhcyB0aGlua2luZyBhYm91dCB0aGUgc2l0dWF0aW9u IHdoZXJlIFJSIG9mIHNhbWUgbGV2ZWwgaGFzIHNlc3Npb24gdG8gZWFjaCBvdGhlciAuLi4NCj4g SSB0aGluayB0aGUgaXNzdWUgdGhhdCB5b3Ugd291bGQgaGF2ZSB3aXRoIFJUQywgaXMgb25seSB1 bmVmZmljaWVudCBWUE4gcm91dGUgZGlzdHJpYnV0aW9uLg0KPg0KPiBOb3JtYWxseSB5b3UgaGF2 ZSB0aGUgc2FtZSBraW5kIG9mIGlzc3VlIHdpdGggT3JpZ2luYXRvcklEIC4uLiBpc24ndCBpdCA/ DQo+DQo+IENvbnNpZGVyaW5nIG5vdyB3ZSBoYXZlIHRoaXMgc2Vzc2lvbiBiZXR3ZWVuIFJSMiBh bmQgUlIzIGFuZCBjb25zaWRlciB0aGF0IFJSMSBkb2VzIG5vdCBoYXZlIGFueSBjbGllbnQgb3du aW5nIFZQTjEsIHRoZSBtb3JlIGVmZmljaWVudCBkaXN0cmlidXRpb24gbWV0aG9kIHdvdWxkIGJl IHRoYXQgZGlzdHJpYnV0aW9uIHRyZWUgZG9lcyBub3QgaW5jbHVkZSBSUjEgLi4uDQo+DQo+DQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJyYXN6dWtAZ21haWwuY29tIFtt YWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgDQo+IFJhc3p1aw0K PiBTZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMTQgMTQ6MDgNCj4gVG86IExJVEtPV1NLSSBTdGVw aGFuZSBTQ0UvSUJORg0KPiBDYzogRG9uZ2ppZSAoSmltbXkpOyBpZHJAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LWRv bmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAudHh0DQo+DQo+IFdoYXQgaGFwcGVucyBpZiBS Ui0yIGhhcyBzZXNzaW9uIHdpdGggUlItMyAtIG9uIHB1cnBvc2Ugb3IgYnkgbWlzdGFrZSA/DQo+ DQo+IEkgd291bGQgbm90IGdvIHRoYXQgZmFyIC4uLg0KPg0KPiBDaGVlcnMsDQo+IFIuDQo+DQo+ DQo+DQo+IE9uIEZyaSwgSnVuIDIwLCAyMDE0IGF0IDI6MDMgUE0sICA8c3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb20+IHdyb3RlOg0KPj4gSGkgSmllLA0KPj4NCj4+IFdoeSBub3QganVzdCBh cHBseWluZyB0aGUgc2FtZSBiZWhhdmlvciBhcyBmb3IgT3JpZ2luYXRvciBJRCBmb3IgY2x1c3Rl ciBsaXN0ID8gU28gZXJhc2luZyBpdCwgYW5kIHB1dHRpbmcgUlIgQ2x1c3RlciBJRCBvbmx5IGlu IENsaXN0IC4uLg0KPj4gSXMgdGhlcmUgc29tZSBjb25jZXJuIGFib3V0IHVwZGF0ZSBsb29wIGJl dHdlZW4gUlJzIGluIFJUQyBzY2VuYXJpbyB0aGF0IEkgbWlzc2VkID8NCj4+DQo+Pg0KPj4gU3Rl cGhhbmUNCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogSWRyIFtt YWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEb25namllIChKaW1teSkN Cj4+IFNlbnQ6IEZyaWRheSwgSnVuZSAyMCwgMjAxNCAwNDo1NQ0KPj4gVG86IGlkckBpZXRmLm9y Zw0KPj4gU3ViamVjdDogW0lkcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+ PiBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTAwLnR4dA0KPj4NCj4+IEhpIGFs bCwNCj4+DQo+PiBUaGlzIGlzIGEgc2hvcnQgZHJhZnQgdG8gbWFrZSBSVEMgYXBwbGljYWJsZSBp biBoaWVyYXJjaGljYWwgUlIgc2NlbmFyaW8uDQo+Pg0KPj4gQ29tbWVudHMgYXJlIHdlbGNvbWUu DQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4gSmllDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4NCj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZG9uZy1pZHIt cnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQNCj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEppZSBEb25nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4+ Pg0KPj4+IE5hbWU6ICAgICAgICAgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1ycg0K Pj4+IFJldmlzaW9uOiAgICAgMDANCj4+PiBUaXRsZTogICAgICAgICAgICAgICAgRXh0ZW5zaW9u cyB0byBSVC1Db25zdHJhaW4gaW4gSGllcmFyY2hpY2FsIFJvdXRlIFJlZmxlY3Rpb24NCj4+PiBT Y2VuYXJpb3MNCj4+PiBEb2N1bWVudCBkYXRlOiAgICAgICAgMjAxNC0wNi0xOQ0KPj4+IEdyb3Vw OiAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+PiBQYWdlczogICAgICAg ICAgICAgICAgNQ0KPj4+IFVSTDoNCj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLQ0KPj4+IHINCj4+PiByDQo+Pj4g LTAwLnR4dA0KPj4+IFN0YXR1czoNCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLw0KPj4+IEh0bWxpemVkOg0KPj4+ IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGlj YWwtcnItMDANCj4+Pg0KPj4+DQo+Pj4gQWJzdHJhY3Q6DQo+Pj4gICAgVGhlIFJvdXRlIFRhcmdl dCAoUlQpIENvbnN0cmFpbiBtZWNoYW5pc20gc3BlY2lmaWVkIGluIFJGQyA0Njg0IGlzDQo+Pj4g ICAgdXNlZCB0byBidWlsZCBhIHJvdXRlIGRpc3RyaWJ1dGlvbiBncmFwaCBpbiBvcmRlciB0byBy ZXN0cmljdCB0aGUNCj4+PiAgICBwcm9wYWdhdGlvbiBvZiBWaXJ0dWFsIFByaXZhdGUgTmV0d29y ayAoVlBOKSByb3V0ZXMuICBJbiBuZXR3b3JrDQo+Pj4gICAgc2NlbmFyaW9zIHdoZXJlIGhpZXJh cmNoaWNhbCByb3V0ZSByZWZsZWN0aW9uIChSUikgaXMgdXNlZCwgdGhlDQo+Pj4gICAgZXhpc3Rp bmcgUlQtQ29uc3RyYWluIG1lY2hhbmlzbSBjYW5ub3QgYnVpbGQgYSBjb3JyZWN0IHJvdXRlDQo+ Pj4gICAgZGlzdHJpYnV0aW9uIGdyYXBoLiAgVGhpcyBkb2N1bWVudCByZWZpbmVzIHRoZSByb3V0 ZSBkaXN0cmlidXRpb24NCj4+PiAgICBydWxlcyBvZiBSVC1Db25zdHJhaW4gdG8gYWRkcmVzcyB0 aGUgaGllcmFyY2hpY2FsIFJSIHNjZW5hcmlvcy4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+ Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2YgDQo+Pj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4+DQo+Pj4gVGhlIElF VEYgU2VjcmV0YXJpYXQNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gSWRyIG1haWxpbmcgbGlzdA0KPj4gSWRyQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KPj4NCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gXyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+DQo+PiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQo+PiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgDQo+PiBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IA0KPj4gcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4NCj4+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciANCj4+IHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+PiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+IEFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4+IFRoYW5r IHlvdS4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gSWRyIG1haWxpbmcgbGlzdA0KPj4gSWRyQGlldGYub3JnDQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiBD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgDQo+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCANCj4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSANCj4gcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLg0KPg0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgDQo+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4NCj4NCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMK cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQn YWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91 bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz LgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5r IHlvdS4KCg== From nobody Fri Jun 20 12:03:26 2014 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 D21B31B28FB for ; Fri, 20 Jun 2014 12:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 21ieAXuddW6h for ; Fri, 20 Jun 2014 12:03:23 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A64A1B28D3 for ; Fri, 20 Jun 2014 12:03:01 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 56584a35.2ba84a23c940.6700974.00-2482.17182463.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 20 Jun 2014 19:03:01 +0000 (UTC) X-MXL-Hash: 53a485654595edf3-2bfc4627a17385c1a9fd555660a5c947fa39d107 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 05584a35.0.6700783.00-2267.17181943.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 20 Jun 2014 19:02:47 +0000 (UTC) X-MXL-Hash: 53a48557555ffac4-65b547ec49cf234fcbd4fd6349a947298fdfddf8 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5KJ2ejq029041; Fri, 20 Jun 2014 15:02:40 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5KJ2T5i028829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2014 15:02:33 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 20 Jun 2014 19:02:19 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.4]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0174.001; Fri, 20 Jun 2014 15:02:18 -0400 From: "UTTARO, JAMES" To: "'Dongjie (Jimmy)'" , "'idr@ietf.org'" Thread-Topic: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAEPJ1A= Date: Fri, 20 Jun 2014 19:02:18 +0000 Message-ID: References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.240.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Ro1y2laK c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=BbnZtKN_HuwA:10 a=ofMgfj31e3cA:10 a=wnSzVS5SIWAA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=mU5SGK0yj92YAmrJY2wA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=8JjhrM2CGPPEwLR-:21 a=1i7xiam] X-AnalysisOut: [nY6v02Jhe:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/uxDBBamlqPiBXt78b1V7vylFTVQ Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 19:03:25 -0000 Why? A picture would be quite useful here. I am struggling to understand a = hierarcacal design that then needs RT-C?? Maybe if the VPNs are highly loca= lized.. BTW isn't RT-C a good candidate to off net to an SDN controller? IM= O that should be the future. Jim Uttaro -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) Sent: Thursday, June 19, 2014 10:55 PM To: idr@ietf.org Subject: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarch= ical-rr-00.txt Hi all,=20 This is a short draft to make RTC applicable in hierarchical RR scenario. Comments are welcome. Best regards, Jie > -----Original Message----- >=20 > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > has been successfully submitted by Jie Dong and posted to the IETF reposi= tory. >=20 > Name: draft-dong-idr-rtc-hierarchical-rr > Revision: 00 > Title: Extensions to RT-Constrain in Hierarchical Route Reflection > Scenarios > Document date: 2014-06-19 > Group: Individual Submission > Pages: 5 > URL: > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-rr-00= .txt > Status: > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ > Htmlized: > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 >=20 >=20 > Abstract: > The Route Target (RT) Constrain mechanism specified in RFC 4684 is > used to build a route distribution graph in order to restrict the > propagation of Virtual Private Network (VPN) routes. In network > scenarios where hierarchical route reflection (RR) is used, the > existing RT-Constrain mechanism cannot build a correct route > distribution graph. This document refines the route distribution > rules of RT-Constrain to address the hierarchical RR scenarios. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Sat Jun 21 10:19:37 2014 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 B458F1A02AD for ; Sat, 21 Jun 2014 10:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cmw_vc89Bs3q for ; Sat, 21 Jun 2014 10:19:31 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3771A0181 for ; Sat, 21 Jun 2014 10:19:30 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: "Dongjie (Jimmy)" , "idr@ietf.org" Thread-Topic: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAA= Date: Sat, 21 Jun 2014 17:19:22 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.44.10] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/r1tQBlc-rA3HJreDyFEo6lK4B4U Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 17:19:34 -0000 Hi Jie, Well the correctly designed MPLS networks use unique per PE per VRF RDs in = form of RID:xxxxx.=20 Unique per PE RDs makes all copies of the same VPN prefix received from dif= ferent PEs unique so RRs will select all as best path and distribute them a= ccordingly, which solves this and many other issues.=20 In other words if someone tries to shoot himself in the foot I wouldn't dev= elop bulletproof boots for him.=20 adam > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) > Sent: Friday, June 20, 2014 4:55 AM > To: idr@ietf.org > Subject: [Idr] FW: New Version Notification for draft-dong-idr-rtc- > hierarchical-rr-00.txt >=20 > Hi all, >=20 > This is a short draft to make RTC applicable in hierarchical RR scenario. >=20 > Comments are welcome. >=20 > Best regards, > Jie >=20 > > -----Original Message----- > > > > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > > has been successfully submitted by Jie Dong and posted to the IETF > repository. > > > > Name: draft-dong-idr-rtc-hierarchical-rr > > Revision: 00 > > Title: Extensions to RT-Constrain in Hierarchical Route Reflection > > Scenarios > > Document date: 2014-06-19 > > Group: Individual Submission > > Pages: 5 > > URL: > > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-rr > > -00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ > > Htmlized: > > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 > > > > > > Abstract: > > The Route Target (RT) Constrain mechanism specified in RFC 4684 is > > used to build a route distribution graph in order to restrict the > > propagation of Virtual Private Network (VPN) routes. In network > > scenarios where hierarchical route reflection (RR) is used, the > > existing RT-Constrain mechanism cannot build a correct route > > distribution graph. This document refines the route distribution > > rules of RT-Constrain to address the hierarchical RR scenarios. > > > > > > > > > > > > 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.i= etf.org. > > > > The IETF Secretariat >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sat Jun 21 10:52:15 2014 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 49FB81A038B for ; Sat, 21 Jun 2014 10:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hWTWpmHrIu0 for ; Sat, 21 Jun 2014 10:52:10 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49491A0151 for ; Sat, 21 Jun 2014 10:52:09 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id l13so1540639iga.13 for ; Sat, 21 Jun 2014 10:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=cSIEBNLaSE2RM8kxkXE5IgiY/sDJR+HOVOa3o/jFzBk=; b=w8ucY/WbZMv78NLNP2loMaoDmNgg2vmVSHdRSu9EMfxtQlg9ZOYziqbNLl3i6Ar0DU jvKDPOAPjgkGBf/v4Qo/VjsX6ps3DtmkgaKpYsTFOPp5zAKvTlpu0o0+sF7oHhTEOEC2 PN0/ePMrNBOEDyLbvwhxl5dxkHOgBr3PgFJyu5dmR68MhGDRLQykiTC9KTX/TZJUOEKD 4lXFxpZdVb51xYjCs5sNadtrqPeLHxByC2/gnkyTWqLsKI6BWN6SB7IhP6wsyQqRiGJf KizpW4idaX26CnxQjqeXe7neVNBWoQIXovcccFlr1ac6PQCNbmPt7xd4jSaczYQbHS1d 97pw== MIME-Version: 1.0 X-Received: by 10.50.98.100 with SMTP id eh4mr13710898igb.9.1403373129335; Sat, 21 Jun 2014 10:52:09 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Sat, 21 Jun 2014 10:52:09 -0700 (PDT) In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> Date: Sat, 21 Jun 2014 19:52:09 +0200 X-Google-Sender-Auth: tu0ejKqBteYUv8XkfCpuUR-j6hQ Message-ID: From: Robert Raszuk To: =?UTF-8?Q?Vitkovsk=C3=BD_Adam?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/guGTCCV6TB24E0nbax_TOpng9D0 Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 17:52:11 -0000 Hi Adam, Jie is describing RT routes not VPN routes. Your story does not apply to RT routes as format of RT NLRI is well defined by RFC ;) Besides MPLS network or not has nothing to do with it .... Best, R. On Sat, Jun 21, 2014 at 7:19 PM, Vitkovsk=C3=BD Adam wrote: > Hi Jie, > Well the correctly designed MPLS networks use unique per PE per VRF RDs i= n form of RID:xxxxx. > Unique per PE RDs makes all copies of the same VPN prefix received from d= ifferent PEs unique so RRs will select all as best path and distribute them= accordingly, which solves this and many other issues. > > In other words if someone tries to shoot himself in the foot I wouldn't d= evelop bulletproof boots for him. > > adam >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) >> Sent: Friday, June 20, 2014 4:55 AM >> To: idr@ietf.org >> Subject: [Idr] FW: New Version Notification for draft-dong-idr-rtc- >> hierarchical-rr-00.txt >> >> Hi all, >> >> This is a short draft to make RTC applicable in hierarchical RR scenario= . >> >> Comments are welcome. >> >> Best regards, >> Jie >> >> > -----Original Message----- >> > >> > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt >> > has been successfully submitted by Jie Dong and posted to the IETF >> repository. >> > >> > Name: draft-dong-idr-rtc-hierarchical-rr >> > Revision: 00 >> > Title: Extensions to RT-Constrain in Hierarchical Route R= eflection >> > Scenarios >> > Document date: 2014-06-19 >> > Group: Individual Submission >> > Pages: 5 >> > URL: >> > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-rr >> > -00.txt >> > Status: >> > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ >> > Htmlized: >> > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 >> > >> > >> > Abstract: >> > The Route Target (RT) Constrain mechanism specified in RFC 4684 is >> > used to build a route distribution graph in order to restrict the >> > propagation of Virtual Private Network (VPN) routes. In network >> > scenarios where hierarchical route reflection (RR) is used, the >> > existing RT-Constrain mechanism cannot build a correct route >> > distribution graph. This document refines the route distribution >> > rules of RT-Constrain to address the hierarchical RR scenarios. >> > >> > >> > >> > >> > >> > Please note that it may take a couple of minutes from the time of >> > submission until the htmlized version and diff are available at tools.= ietf.org. >> > >> > The IETF Secretariat >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sat Jun 21 11:56:49 2014 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 1D3551A03BB for ; Sat, 21 Jun 2014 11:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 k1UxYv5oV2i1 for ; Sat, 21 Jun 2014 11:56:47 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F101A01BA for ; Sat, 21 Jun 2014 11:56:47 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id f65d5a35.2ba843431940.7068273.00-2496.18154221.nbfkord-smmo07.seg.att.com (envelope-from ); Sat, 21 Jun 2014 18:56:47 +0000 (UTC) X-MXL-Hash: 53a5d56f62164ccb-22caf9af2e4aeaa4e975ce8c2ab2cd2dbf969bb0 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 765d5a35.0.7068254.00-2308.18154169.nbfkord-smmo07.seg.att.com (envelope-from ); Sat, 21 Jun 2014 18:56:45 +0000 (UTC) X-MXL-Hash: 53a5d56d63cbdf45-3d7e26d7a3a745685ddfcc9ec268271f4439abe3 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5LIud4Q000493; Sat, 21 Jun 2014 14:56:39 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5LIuXcJ000443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jun 2014 14:56:36 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sat, 21 Jun 2014 18:56:15 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.4]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0174.001; Sat, 21 Jun 2014 14:56:15 -0400 From: "UTTARO, JAMES" To: =?iso-8859-1?Q?=27Vitkovsk=FD_Adam=27?= , "'Dongjie (Jimmy)'" , "'idr@ietf.org'" Thread-Topic: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASACAAB/+0A== Date: Sat, 21 Jun 2014 18:56:14 +0000 Message-ID: References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.61.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Ro1y2laK c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=BbnZtKN_HuwA:10 a=ofMgfj31e3cA:10 a=toga8A-dhOgA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=iERoxZfJHEpWjggApXAA:9 a=wPNLvfG] X-AnalysisOut: [TeEIA:10 a=lZB815dzVvQA:10 a=Fy1i25vPcBhUNuLv:21 a=0QdIuh4] X-AnalysisOut: [6bc3fBlHz:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Fu0MjUHNLlvNHWthN9zIM16210Q Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 18:56:49 -0000 +1 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Vitkovsk=FD Adam Sent: Saturday, June 21, 2014 1:19 PM To: Dongjie (Jimmy); idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarch= ical-rr-00.txt Hi Jie, Well the correctly designed MPLS networks use unique per PE per VRF RDs in = form of RID:xxxxx.=20 Unique per PE RDs makes all copies of the same VPN prefix received from dif= ferent PEs unique so RRs will select all as best path and distribute them a= ccordingly, which solves this and many other issues.=20 In other words if someone tries to shoot himself in the foot I wouldn't dev= elop bulletproof boots for him.=20 adam > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) > Sent: Friday, June 20, 2014 4:55 AM > To: idr@ietf.org > Subject: [Idr] FW: New Version Notification for draft-dong-idr-rtc- > hierarchical-rr-00.txt >=20 > Hi all, >=20 > This is a short draft to make RTC applicable in hierarchical RR scenario. >=20 > Comments are welcome. >=20 > Best regards, > Jie >=20 > > -----Original Message----- > > > > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > > has been successfully submitted by Jie Dong and posted to the IETF > repository. > > > > Name: draft-dong-idr-rtc-hierarchical-rr > > Revision: 00 > > Title: Extensions to RT-Constrain in Hierarchical Route Reflection > > Scenarios > > Document date: 2014-06-19 > > Group: Individual Submission > > Pages: 5 > > URL: > > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-rr > > -00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ > > Htmlized: > > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 > > > > > > Abstract: > > The Route Target (RT) Constrain mechanism specified in RFC 4684 is > > used to build a route distribution graph in order to restrict the > > propagation of Virtual Private Network (VPN) routes. In network > > scenarios where hierarchical route reflection (RR) is used, the > > existing RT-Constrain mechanism cannot build a correct route > > distribution graph. This document refines the route distribution > > rules of RT-Constrain to address the hierarchical RR scenarios. > > > > > > > > > > > > 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.i= etf.org. > > > > The IETF Secretariat >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Sat Jun 21 12:19:43 2014 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 1C04D1A016B for ; Sat, 21 Jun 2014 12:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmtw2WZBSO1g for ; Sat, 21 Jun 2014 12:19:39 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC301A03A3 for ; Sat, 21 Jun 2014 12:19:38 -0700 (PDT) From: =?utf-8?B?Vml0a292c2vDvSBBZGFt?= To: Robert Raszuk Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//+xkgIAAOCmw Date: Sat, 21 Jun 2014 19:19:36 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> In-Reply-To: Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.44.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/K-kEBIu2rJga-N6adYb7u_4Om40 Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 19:19:42 -0000 QWFoIEkgc2VlIDopDQpXZWxsIHdlIGNvdWxkIGhhdmUgdGhhdCBvbmUgc29sdmVkIGlmIFJEIHdv dWxkIGJlIHBhcnQgb2YgdGhlIFJUQyByb3V0ZXMgOikgKHRob3VnaCBJIHVuZGVyc3RhbmQgb25l IGNvdWxkIHVzZSBSVEMgZm9yIG5vbiBWUE4gcm91dGVzIGFzIHdlbGwgc28uLi4pDQpBbnl3YXlz IHNvIHRoYW4gYXMgeW91IG1lbnRpb25lZCBhZGQtcGF0aCBvbiB0aGUgUlRDIEFGIHNlZW1zIGFz IHRoZSBiZXN0IG9wdGlvbiB0aGVuLg0KDQphZGFtDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21d IE9uIEJlaGFsZiBPZiBSb2JlcnQNCj4gUmFzenVrDQo+IFNlbnQ6IFNhdHVyZGF5LCBKdW5lIDIx LCAyMDE0IDc6NTIgUE0NCj4gVG86IFZpdGtvdnNrw70gQWRhbQ0KPiBDYzogRG9uZ2ppZSAoSmlt bXkpOyBpZHJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC0NCj4gcnItMDAudHh0 DQo+IA0KPiBIaSBBZGFtLA0KPiANCj4gSmllIGlzIGRlc2NyaWJpbmcgUlQgcm91dGVzIG5vdCBW UE4gcm91dGVzLiBZb3VyIHN0b3J5IGRvZXMgbm90IGFwcGx5IHRvIFJUDQo+IHJvdXRlcyBhcyBm b3JtYXQgb2YgUlQgTkxSSSBpcyB3ZWxsIGRlZmluZWQgYnkgUkZDIDspDQo+IA0KPiBCZXNpZGVz IE1QTFMgbmV0d29yayBvciBub3QgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBpdCAuLi4uDQo+IA0K PiBCZXN0LA0KPiBSLg0KPiANCj4gT24gU2F0LCBKdW4gMjEsIDIwMTQgYXQgNzoxOSBQTSwgVml0 a292c2vDvSBBZGFtIDxhZGFtLnZpdGtvdnNreUBzd2FuLnNrPg0KPiB3cm90ZToNCj4gPiBIaSBK aWUsDQo+ID4gV2VsbCB0aGUgY29ycmVjdGx5IGRlc2lnbmVkIE1QTFMgbmV0d29ya3MgdXNlIHVu aXF1ZSBwZXIgUEUgcGVyIFZSRiBSRHMNCj4gaW4gZm9ybSBvZiBSSUQ6eHh4eHguDQo+ID4gVW5p cXVlIHBlciBQRSBSRHMgbWFrZXMgYWxsIGNvcGllcyBvZiB0aGUgc2FtZSBWUE4gcHJlZml4IHJl Y2VpdmVkIGZyb20NCj4gZGlmZmVyZW50IFBFcyB1bmlxdWUgc28gUlJzIHdpbGwgc2VsZWN0IGFs bCBhcyBiZXN0IHBhdGggYW5kIGRpc3RyaWJ1dGUgdGhlbQ0KPiBhY2NvcmRpbmdseSwgd2hpY2gg c29sdmVzIHRoaXMgYW5kIG1hbnkgb3RoZXIgaXNzdWVzLg0KPiA+DQo+ID4gSW4gb3RoZXIgd29y ZHMgaWYgc29tZW9uZSB0cmllcyB0byBzaG9vdCBoaW1zZWxmIGluIHRoZSBmb290IEkgd291bGRu J3QNCj4gZGV2ZWxvcCBidWxsZXRwcm9vZiBib290cyBmb3IgaGltLg0KPiA+DQo+ID4gYWRhbQ0K PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBJZHIgW21haWx0bzpp ZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERvbmdqaWUgKEppbW15KQ0KPiA+PiBT ZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMTQgNDo1NSBBTQ0KPiA+PiBUbzogaWRyQGlldGYub3Jn DQo+ID4+IFN1YmplY3Q6IFtJZHJdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWRvbmctaWRyLXJ0Yy0NCj4gPj4gaGllcmFyY2hpY2FsLXJyLTAwLnR4dA0KPiA+Pg0KPiA+ PiBIaSBhbGwsDQo+ID4+DQo+ID4+IFRoaXMgaXMgYSBzaG9ydCBkcmFmdCB0byBtYWtlIFJUQyBh cHBsaWNhYmxlIGluIGhpZXJhcmNoaWNhbCBSUiBzY2VuYXJpby4NCj4gPj4NCj4gPj4gQ29tbWVu dHMgYXJlIHdlbGNvbWUuDQo+ID4+DQo+ID4+IEJlc3QgcmVnYXJkcywNCj4gPj4gSmllDQo+ID4+ DQo+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPg0KPiA+PiA+IEEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTAwLnR4 dA0KPiA+PiA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmllIERvbmcgYW5k IHBvc3RlZCB0byB0aGUgSUVURg0KPiA+PiByZXBvc2l0b3J5Lg0KPiA+PiA+DQo+ID4+ID4gTmFt ZTogICAgICAgICAgICAgICBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyDQo+ID4+ ID4gUmV2aXNpb246ICAgMDANCj4gPj4gPiBUaXRsZTogICAgICAgICAgICAgIEV4dGVuc2lvbnMg dG8gUlQtQ29uc3RyYWluIGluIEhpZXJhcmNoaWNhbCBSb3V0ZSBSZWZsZWN0aW9uDQo+ID4+ID4g U2NlbmFyaW9zDQo+ID4+ID4gRG9jdW1lbnQgZGF0ZTogICAgICAyMDE0LTA2LTE5DQo+ID4+ID4g R3JvdXA6ICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPj4gPiBQYWdlczog ICAgICAgICAgICAgIDUNCj4gPj4gPiBVUkw6DQo+ID4+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbA0KPiA+PiA+IC1y cg0KPiA+PiA+IC0wMC50eHQNCj4gPj4gPiBTdGF0dXM6DQo+ID4+ID4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1ycg0KPiA+ PiA+IC8NCj4gPj4gPiBIdG1saXplZDoNCj4gPj4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTAwDQo+ID4+ID4NCj4gPj4gPg0K PiA+PiA+IEFic3RyYWN0Og0KPiA+PiA+ICAgIFRoZSBSb3V0ZSBUYXJnZXQgKFJUKSBDb25zdHJh aW4gbWVjaGFuaXNtIHNwZWNpZmllZCBpbiBSRkMgNDY4NCBpcw0KPiA+PiA+ICAgIHVzZWQgdG8g YnVpbGQgYSByb3V0ZSBkaXN0cmlidXRpb24gZ3JhcGggaW4gb3JkZXIgdG8gcmVzdHJpY3QgdGhl DQo+ID4+ID4gICAgcHJvcGFnYXRpb24gb2YgVmlydHVhbCBQcml2YXRlIE5ldHdvcmsgKFZQTikg cm91dGVzLiAgSW4gbmV0d29yaw0KPiA+PiA+ICAgIHNjZW5hcmlvcyB3aGVyZSBoaWVyYXJjaGlj YWwgcm91dGUgcmVmbGVjdGlvbiAoUlIpIGlzIHVzZWQsIHRoZQ0KPiA+PiA+ICAgIGV4aXN0aW5n IFJULUNvbnN0cmFpbiBtZWNoYW5pc20gY2Fubm90IGJ1aWxkIGEgY29ycmVjdCByb3V0ZQ0KPiA+ PiA+ICAgIGRpc3RyaWJ1dGlvbiBncmFwaC4gIFRoaXMgZG9jdW1lbnQgcmVmaW5lcyB0aGUgcm91 dGUgZGlzdHJpYnV0aW9uDQo+ID4+ID4gICAgcnVsZXMgb2YgUlQtQ29uc3RyYWluIHRvIGFkZHJl c3MgdGhlIGhpZXJhcmNoaWNhbCBSUiBzY2VuYXJpb3MuDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+ DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+ID4gc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+IHRvb2xz LmlldGYub3JnLg0KPiA+PiA+DQo+ID4+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPj4NCj4g Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4g SWRyIG1haWxpbmcgbGlzdA0KPiA+PiBJZHJAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gSWRyIG1haWxpbmcgbGlzdA0KPiA+IElk ckBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy DQo= From nobody Sun Jun 22 19:02:05 2014 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 6C5C21B2845 for ; Sun, 22 Jun 2014 19:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 9gXv0HEj6jt3 for ; Sun, 22 Jun 2014 19:02:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED631B2841 for ; Sun, 22 Jun 2014 19:02:00 -0700 (PDT) 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 BJA31995; Mon, 23 Jun 2014 02:01:58 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Jun 2014 03:01:58 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 23 Jun 2014 10:01:52 +0800 From: "Dongjie (Jimmy)" To: Robert Raszuk Thread-Topic: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPA///oxICABLh84A== Date: Mon, 23 Jun 2014 02:01:51 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273369965F@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/bMnIghO1pxscuqVNoijda1U7f-c Cc: "idr@ietf.org" Subject: Re: [Idr] FW: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 02:02:04 -0000 SGkgUm9iZXJ0LCANCg0KU29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5Lg0KDQpGaXJzdCBvZiBhbGws IHRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBwcm9ibGVtIG9mIFJUQyBpbiBoaWVyYXJjaGljYWwg UlIgc2NlbmFyaW8sIGFuZCBJIHRoaW5rIHRoaXMgcHJvYmxlbSBpcyBBQ0tlZC4NCg0KUmVnYXJk aW5nIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiwgdG8gYmUgaG9uZXN0IHRoZSBjby1hdXRob3JzIGRp c2N1c3NlZCBzZXZlcmFsIGFsdGVybmF0ZSBzb2x1dGlvbnMgYW5kIGFkZC1wYXRoIHdhcyBvbmUg b2YgdGhlbS4gVGhlIGNvbmNlcm4gd2FzIHRoYXQgd2l0aCBhZGQtcGF0aD0yLCBpbiBzb21lIHRy aWNreSB0b3BvbG9neSBib3RoIHRoZSAyIHBhdGhzIGFkdmVydGlzZWQgbWF5IGluY2x1ZGUgdGhl IHNhbWUgQ0xVU1RFUl9JRCBvciBPUklHSU5BVE9SX0lEIHRoYXQgbWF5IHJlc3VsdCBpbiBib3Ro IHBhdGhzIGJlaW5nIGRpc2NhcmRlZCBkdWUgdG8gbG9vcCBkZXRlY3Rpb24uIA0KDQpJIHRvdGFs bHkgYWdyZWUgdGhhdCB1c2luZyBleGlzdGluZyBtZWNoYW5pc21zIGlzIGFsd2F5cyBwcmVmZXJy ZWQsIHdoaWxlIGxpa2UgU3RlcGhhbmUgc2FpZCB3ZSdkIGFsc28gZXhwZWN0IFJUQyB0byB3b3Jr IGluIGJhc2ljIGhpZXJhcmNoaWNhbCBSUiBjYXNlIHdpdGhvdXQgYXNzaXN0YW5jZSBvZiBvdGhl ciBCR1AgbWVjaGFuaXNtcy4gQW5kIHNpbmNlIHJlY2VudGx5IHdlIGFyZSBtYWtpbmcgc2V2ZXJh bCB1cGRhdGVzIHRvIFJUQywgaXQgbWF5IGJlIHRoZSByaWdodCB0aW1lIHRvIGFkZHJlc3MgdGhp cyBwcm9ibGVtIHRvZ2V0aGVyLg0KDQpCZXN0IHJlZ2FyZHMsDQpKaWUNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6 dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0DQo+IFJhc3p1aw0KPiBTZW50OiBGcmlk YXksIEp1bmUgMjAsIDIwMTQgNToyOCBQTQ0KPiBUbzogRG9uZ2ppZSAoSmltbXkpDQo+IENjOiBp ZHJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtJZHJdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yDQo+IGRyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAudHh0DQo+ IA0KPiBIZWxsbyBKaWUsDQo+IA0KPiBQbGVhc2UgbGV0IG1lIHVuZGVyc3RhbmQgd2h5IGluc3Rl YWQgb2YgZGVmaW5pbmcgbmV3IEJHUCB0ZXJtIG9mICJ0aGUgbW9zdA0KPiBkaXNqb2ludCBhbHRl cm5hdGl2ZSByb3V0ZSIgYmV0d2VlbiBSUi0xIGFuZCBSUi0yIGFuZCBiZXR3ZWVuDQo+IFJSLTEg YW5kIFJSLTMgeW91IHdvdWxkIG5vdCBzaW1wbHkgcnVuIGFkZC1wYXRocyBvbiB0aGUgUlRDIGFk ZHJlc3MgZmFtaWx5ID8NCj4gDQo+IEkgYmVsaWV2ZSB0aGF0IGV2ZW4gYWRkLXBhdGhzID0gMiB3 aGVyZSBuZXh0IGhvcCBpcyBkaWZmZXJlbnQgb24gdGhlIHNldCBvZg0KPiBhZHZlcnRpc2VkIHBh dGhzIHdpbGwgc29sdmUgeW91ciBpc3N1ZS4NCj4gDQo+IExpa2V3aXNlIGlmIGFkZC1wYXRocyBp cyBub3Qgc3VwcG9ydGVkIG9uIGFueSBvZiB0aG9zZSBSUnMgaW4gcXVlc3Rpb24gb25lIGNhbg0K PiBhbHNvIGZpeCB0aGUgc2NlbmFyaW8gYnkgdXNpbmcgY29uY2VwdCBvZiBkaXZlcnNlLXBhdGgg KFJGQw0KPiA2Nzc0KSB3aXRob3V0IGFueSBhZGRpdGlvbmFsIGNoYW5nZXMgdG8gQkdQIGFkdmVy dGlzZW1lbnQgbWFjaGluZXJ5IG9uIEJHUA0KPiByb3V0ZSByZWZsZWN0b3JzLg0KPiANCj4gSXNu J3QgaXQgYWx3YXlzIGFuIGFkdmFudGFnZSB0byB1c2UgZXhpc3RpbmcgbWVjaGFuaXNtIHRvIHNv bHZlIHBvdGVudGlhbA0KPiBkZXBsb3ltZW50IHByb2JsZW1zID8NCj4gDQo+IENvbW1lbnRzID8N Cj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gUi4NCj4gDQo+IA0KPiBPbiBGcmksIEp1biAyMCwgMjAx NCBhdCA0OjU0IEFNLCBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5jb20+DQo+IHdy b3RlOg0KPiA+IEhpIGFsbCwNCj4gPg0KPiA+IFRoaXMgaXMgYSBzaG9ydCBkcmFmdCB0byBtYWtl IFJUQyBhcHBsaWNhYmxlIGluIGhpZXJhcmNoaWNhbCBSUiBzY2VuYXJpby4NCj4gPg0KPiA+IENv bW1lbnRzIGFyZSB3ZWxjb21lLg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IEppZQ0KPiA+ DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+DQo+ID4+IEEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTAwLnR4dA0KPiA+ PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppZSBEb25nIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYNCj4gcmVwb3NpdG9yeS4NCj4gPj4NCj4gPj4gTmFtZTogICAgICAgICBkcmFm dC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyDQo+ID4+IFJldmlzaW9uOiAgICAgMDANCj4g Pj4gVGl0bGU6ICAgICAgICAgICAgICAgIEV4dGVuc2lvbnMgdG8gUlQtQ29uc3RyYWluIGluIEhp ZXJhcmNoaWNhbCBSb3V0ZQ0KPiBSZWZsZWN0aW9uDQo+ID4+IFNjZW5hcmlvcw0KPiA+PiBEb2N1 bWVudCBkYXRlOiAgICAgICAgMjAxNC0wNi0xOQ0KPiA+PiBHcm91cDogICAgICAgICAgICAgICAg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4+IFBhZ2VzOiAgICAgICAgICAgICAgICA1DQo+ID4+ IFVSTDoNCj4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZG9u Zy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yDQo+ID4+IHItMDAudHh0DQo+ID4+IFN0YXR1czoNCj4g Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZG9uZy1pZHItcnRjLWhp ZXJhcmNoaWNhbC1yci8NCj4gPj4gSHRtbGl6ZWQ6DQo+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDANCj4gPj4NCj4gPj4N Cj4gPj4gQWJzdHJhY3Q6DQo+ID4+ICAgIFRoZSBSb3V0ZSBUYXJnZXQgKFJUKSBDb25zdHJhaW4g bWVjaGFuaXNtIHNwZWNpZmllZCBpbiBSRkMgNDY4NCBpcw0KPiA+PiAgICB1c2VkIHRvIGJ1aWxk IGEgcm91dGUgZGlzdHJpYnV0aW9uIGdyYXBoIGluIG9yZGVyIHRvIHJlc3RyaWN0IHRoZQ0KPiA+ PiAgICBwcm9wYWdhdGlvbiBvZiBWaXJ0dWFsIFByaXZhdGUgTmV0d29yayAoVlBOKSByb3V0ZXMu ICBJbiBuZXR3b3JrDQo+ID4+ICAgIHNjZW5hcmlvcyB3aGVyZSBoaWVyYXJjaGljYWwgcm91dGUg cmVmbGVjdGlvbiAoUlIpIGlzIHVzZWQsIHRoZQ0KPiA+PiAgICBleGlzdGluZyBSVC1Db25zdHJh aW4gbWVjaGFuaXNtIGNhbm5vdCBidWlsZCBhIGNvcnJlY3Qgcm91dGUNCj4gPj4gICAgZGlzdHJp YnV0aW9uIGdyYXBoLiAgVGhpcyBkb2N1bWVudCByZWZpbmVzIHRoZSByb3V0ZSBkaXN0cmlidXRp b24NCj4gPj4gICAgcnVsZXMgb2YgUlQtQ29uc3RyYWluIHRvIGFkZHJlc3MgdGhlIGhpZXJhcmNo aWNhbCBSUiBzY2VuYXJpb3MuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mDQo+ID4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPj4NCj4gPj4gVGhlIElFVEYg U2VjcmV0YXJpYXQNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gSWRyIG1haWxpbmcgbGlzdA0KPiA+IElkckBpZXRmLm9yZw0KPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo= From nobody Sun Jun 22 19:16:20 2014 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 D666D1B2851 for ; Sun, 22 Jun 2014 19:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 WP-JPuqQRvUx for ; Sun, 22 Jun 2014 19:16:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2A21B2849 for ; Sun, 22 Jun 2014 19:16:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFZ17924; Mon, 23 Jun 2014 02:16:13 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Jun 2014 03:16:12 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 23 Jun 2014 10:16:07 +0800 From: "Dongjie (Jimmy)" To: "stephane.litkowski@orange.com" , "idr@ietf.org" Thread-Topic: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgACZ1UCABBAogA== Date: Mon, 23 Jun 2014 02:16:07 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273369A674@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rs0WZ7T1Mc5HlU3gy2G4nbUtfmA Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 02:16:17 -0000 Hi Stephane,=20 Sorry for the late reply. I think Robert has pointed out the potential risk of erasing the cluster li= st information, which is also our concern. And IMO the rule defined in this= draft can also work for the ORIGINATOR_ID manipulation, which makes it gen= eric for the RTC route advertisement... We are open to the discussion of the best solution for this problem. Many thanks, Jie > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of > stephane.litkowski@orange.com > Sent: Friday, June 20, 2014 8:04 PM > To: Dongjie (Jimmy); idr@ietf.org > Subject: Re: [Idr] New Version Notification for > draft-dong-idr-rtc-hierarchical-rr-00.txt >=20 > Hi Jie, >=20 > Why not just applying the same behavior as for Originator ID for cluster = list ? So > erasing it, and putting RR Cluster ID only in Clist ... > Is there some concern about update loop between RRs in RTC scenario that = I > missed ? >=20 >=20 > Stephane >=20 > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) > Sent: Friday, June 20, 2014 04:55 > To: idr@ietf.org > Subject: [Idr] FW: New Version Notification for > draft-dong-idr-rtc-hierarchical-rr-00.txt >=20 > Hi all, >=20 > This is a short draft to make RTC applicable in hierarchical RR scenario. >=20 > Comments are welcome. >=20 > Best regards, > Jie >=20 > > -----Original Message----- > > > > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > > has been successfully submitted by Jie Dong and posted to the IETF repo= sitory. > > > > Name: draft-dong-idr-rtc-hierarchical-rr > > Revision: 00 > > Title: Extensions to RT-Constrain in Hierarchical Route Reflection > > Scenarios > > Document date: 2014-06-19 > > Group: Individual Submission > > Pages: 5 > > URL: > > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-rr > > -00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ > > Htmlized: > > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 > > > > > > Abstract: > > The Route Target (RT) Constrain mechanism specified in RFC 4684 is > > used to build a route distribution graph in order to restrict the > > propagation of Virtual Private Network (VPN) routes. In network > > scenarios where hierarchical route reflection (RR) is used, the > > existing RT-Constrain mechanism cannot build a correct route > > distribution graph. This document refines the route distribution > > rules of RT-Constrain to address the hierarchical RR scenarios. > > > > > > > > > > > > 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.i= etf.org. > > > > The IETF Secretariat >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > ________________________________________________________________ > _________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used > or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sun Jun 22 19:41:53 2014 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 319671B2978 for ; Sun, 22 Jun 2014 19:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 o7cTDnWUhF_u for ; Sun, 22 Jun 2014 19:41:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7F91B2985 for ; Sun, 22 Jun 2014 19:41:46 -0700 (PDT) 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 BJA34118; Mon, 23 Jun 2014 02:41:45 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Jun 2014 03:41:44 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 23 Jun 2014 10:41:40 +0800 From: "Dongjie (Jimmy)" To: "UTTARO, JAMES" , "'idr@ietf.org'" Thread-Topic: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAEPJ1CAA6L2EA== Date: Mon, 23 Jun 2014 02:41:39 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273369B6A5@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/qrv3P597dBcQ14EDA9NmSN_yIxY Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 02:41:51 -0000 Hi Jim, Here is the example I previously sent to the list:=20 PE1---RR2 \ \ =20 PE2- RR1 \ / \ / RR3 / / PE3- RR1 is level-1 RR, and RR2 and RR3 are level-2 RRs. 1. All the PEs advertise RTC route of RT-X to their connecting RRs. 2. RR2 and RR3 select the best RTC route, add their cluster_id to the clust= er_list and advertise the RTC route to RR1 respectively.=20 3. RR1 selects one RTC route as best (let's say RTC route from RR2), adds i= ts cluster_id into the cluster_list and advertises it to RR2 and RR3.=20 4. Then RR2 would receive the RTC route from RR1 with its own cluster_id in= the cluster_list and will drop this RTC route. 5. As a result, RR2 will not advertise VPN routes with RT-X to RR1. For a network with hierarchical RR, RTC can also be useful to control the V= PN routes being distributed only to PEs which have the corresponding custom= ers connected. I'm not quite clear about your comments about RTC and SDN controller, do yo= u mean RTC mechanism can be used to distribute routes to SDN controller? I'= d agree that is another possible use case of RTC. Best regards, Jie > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Saturday, June 21, 2014 3:02 AM > To: Dongjie (Jimmy); 'idr@ietf.org' > Subject: RE: New Version Notification for > draft-dong-idr-rtc-hierarchical-rr-00.txt >=20 > Why? A picture would be quite useful here. I am struggling to understand = a > hierarcacal design that then needs RT-C?? Maybe if the VPNs are highly > localized.. BTW isn't RT-C a good candidate to off net to an SDN controll= er? > IMO that should be the future. >=20 > Jim Uttaro >=20 > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) > Sent: Thursday, June 19, 2014 10:55 PM > To: idr@ietf.org > Subject: [Idr] FW: New Version Notification for > draft-dong-idr-rtc-hierarchical-rr-00.txt >=20 > Hi all, >=20 > This is a short draft to make RTC applicable in hierarchical RR scenario. >=20 > Comments are welcome. >=20 > Best regards, > Jie >=20 > > -----Original Message----- > > > > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > > has been successfully submitted by Jie Dong and posted to the IETF repo= sitory. > > > > Name: draft-dong-idr-rtc-hierarchical-rr > > Revision: 00 > > Title: Extensions to RT-Constrain in Hierarchical Route Reflection > > Scenarios > > Document date: 2014-06-19 > > Group: Individual Submission > > Pages: 5 > > URL: > > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-rr > > -00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ > > Htmlized: > > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 > > > > > > Abstract: > > The Route Target (RT) Constrain mechanism specified in RFC 4684 is > > used to build a route distribution graph in order to restrict the > > propagation of Virtual Private Network (VPN) routes. In network > > scenarios where hierarchical route reflection (RR) is used, the > > existing RT-Constrain mechanism cannot build a correct route > > distribution graph. This document refines the route distribution > > rules of RT-Constrain to address the hierarchical RR scenarios. > > > > > > > > > > > > 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.i= etf.org. > > > > The IETF Secretariat >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sun Jun 22 19:59:38 2014 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 BE3381B2978 for ; Sun, 22 Jun 2014 19:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 sHVsqJrYZrTE for ; Sun, 22 Jun 2014 19:59:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C6A1B2865 for ; Sun, 22 Jun 2014 19:59:33 -0700 (PDT) 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 BFZ20257; Mon, 23 Jun 2014 02:59:32 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Jun 2014 03:59:31 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 23 Jun 2014 10:59:25 +0800 From: "Dongjie (Jimmy)" To: =?utf-8?B?Vml0a292c2vDvSBBZGFt?= , Robert Raszuk Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//4fPgIAAGG8AgAKT/sA= Date: Mon, 23 Jun 2014 02:59:24 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/KDAYOhH6WsNy0h30BYHXVbqoSEU Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 02:59:37 -0000 SGkgQWRhbSwNCg0KSWYgUkQgaXMgcGFydCBvZiB0aGUgUlRDIHJvdXRlcywgdGhpcyBwcm9ibGVt IHdpbGwgbm90IG9jY3VyOikgV2hpbGUgYXMgYW5hbHl6ZWQgaW4gcmZjIDQ2ODQsIHRoaXMgcmVx dWlyZXMgbW9yZSBSVEMgcm91dGVzIGJlaW5nIGV4Y2hhbmdlZCBhbmQga2VwdCBpbiB0aGUgbG9j YWwgQVMuDQoNCkkgYWdyZWUgdGhhdCBhZGQtcGF0aCBpcyBhIGNhbmRpZGF0ZSBzb2x1dGlvbiB0 byB0aGlzIHByb2JsZW0sIHdoaWxlIHdoZW4gZW5hYmxpbmcgYWRkLXBhdGggb24gUlRDIEFGSS9T QUZJLCB3ZSBzdGlsbCBuZWVkIHRvIHNwZWNpZnkgdGhlIHJ1bGVzIG9mIHdoaWNoIFJUQyByb3V0 ZXMgc2hvdWxkIGJlIGFkdmVydGlzZWQgdG8gc29sdmUgdGhpcyBwcm9ibGVtLiBPciB3ZSBqdXN0 IHVwZGF0ZSB0aGUgcnVsZXMgb2YgUlRDIGFkdmVydGlzZW1lbnQgYXMgdGhlIG90aGVyIFJUQyBy ZWxhdGVkIG5ldyBkcmFmdHM/IA0KDQpNYW55IHRoYW5rcywNCkppZQ0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFZpdGtvdnNrw70gQWRhbSBbbWFpbHRvOmFkYW0udml0 a292c2t5QHN3YW4uc2tdDQo+IFNlbnQ6IFN1bmRheSwgSnVuZSAyMiwgMjAxNCAzOjIwIEFNDQo+ IFRvOiBSb2JlcnQgUmFzenVrDQo+IENjOiBEb25namllIChKaW1teSk7IGlkckBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSRTogW0lkcl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFm dC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTAwLnR4dA0KPiANCj4gQWFoIEkgc2VlIDop DQo+IFdlbGwgd2UgY291bGQgaGF2ZSB0aGF0IG9uZSBzb2x2ZWQgaWYgUkQgd291bGQgYmUgcGFy dCBvZiB0aGUgUlRDIHJvdXRlcyA6KQ0KPiAodGhvdWdoIEkgdW5kZXJzdGFuZCBvbmUgY291bGQg dXNlIFJUQyBmb3Igbm9uIFZQTiByb3V0ZXMgYXMgd2VsbCBzby4uLikNCj4gQW55d2F5cyBzbyB0 aGFuIGFzIHlvdSBtZW50aW9uZWQgYWRkLXBhdGggb24gdGhlIFJUQyBBRiBzZWVtcyBhcyB0aGUg YmVzdA0KPiBvcHRpb24gdGhlbi4NCj4gDQo+IGFkYW0NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFp bC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQNCj4gPiBSYXN6dWsNCj4gPiBTZW50OiBTYXR1cmRh eSwgSnVuZSAyMSwgMjAxNCA3OjUyIFBNDQo+ID4gVG86IFZpdGtvdnNrw70gQWRhbQ0KPiA+IENj OiBEb25namllIChKaW1teSk7IGlkckBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbSWRyXSBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJh cmNoaWNhbC0gcnItMDAudHh0DQo+ID4NCj4gPiBIaSBBZGFtLA0KPiA+DQo+ID4gSmllIGlzIGRl c2NyaWJpbmcgUlQgcm91dGVzIG5vdCBWUE4gcm91dGVzLiBZb3VyIHN0b3J5IGRvZXMgbm90IGFw cGx5DQo+ID4gdG8gUlQgcm91dGVzIGFzIGZvcm1hdCBvZiBSVCBOTFJJIGlzIHdlbGwgZGVmaW5l ZCBieSBSRkMgOykNCj4gPg0KPiA+IEJlc2lkZXMgTVBMUyBuZXR3b3JrIG9yIG5vdCBoYXMgbm90 aGluZyB0byBkbyB3aXRoIGl0IC4uLi4NCj4gPg0KPiA+IEJlc3QsDQo+ID4gUi4NCj4gPg0KPiA+ IE9uIFNhdCwgSnVuIDIxLCAyMDE0IGF0IDc6MTkgUE0sIFZpdGtvdnNrw70gQWRhbQ0KPiA+IDxh ZGFtLnZpdGtvdnNreUBzd2FuLnNrPg0KPiA+IHdyb3RlOg0KPiA+ID4gSGkgSmllLA0KPiA+ID4g V2VsbCB0aGUgY29ycmVjdGx5IGRlc2lnbmVkIE1QTFMgbmV0d29ya3MgdXNlIHVuaXF1ZSBwZXIg UEUgcGVyIFZSRg0KPiA+ID4gUkRzDQo+ID4gaW4gZm9ybSBvZiBSSUQ6eHh4eHguDQo+ID4gPiBV bmlxdWUgcGVyIFBFIFJEcyBtYWtlcyBhbGwgY29waWVzIG9mIHRoZSBzYW1lIFZQTiBwcmVmaXgg cmVjZWl2ZWQNCj4gPiA+IGZyb20NCj4gPiBkaWZmZXJlbnQgUEVzIHVuaXF1ZSBzbyBSUnMgd2ls bCBzZWxlY3QgYWxsIGFzIGJlc3QgcGF0aCBhbmQNCj4gPiBkaXN0cmlidXRlIHRoZW0gYWNjb3Jk aW5nbHksIHdoaWNoIHNvbHZlcyB0aGlzIGFuZCBtYW55IG90aGVyIGlzc3Vlcy4NCj4gPiA+DQo+ ID4gPiBJbiBvdGhlciB3b3JkcyBpZiBzb21lb25lIHRyaWVzIHRvIHNob290IGhpbXNlbGYgaW4g dGhlIGZvb3QgSQ0KPiA+ID4gd291bGRuJ3QNCj4gPiBkZXZlbG9wIGJ1bGxldHByb29mIGJvb3Rz IGZvciBoaW0uDQo+ID4gPg0KPiA+ID4gYWRhbQ0KPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPj4gRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBEb25namllDQo+ID4gPj4gKEppbW15KQ0KPiA+ID4+IFNlbnQ6IEZyaWRheSwg SnVuZSAyMCwgMjAxNCA0OjU1IEFNDQo+ID4gPj4gVG86IGlkckBpZXRmLm9yZw0KPiA+ID4+IFN1 YmplY3Q6IFtJZHJdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbmct aWRyLXJ0Yy0NCj4gPiA+PiBoaWVyYXJjaGljYWwtcnItMDAudHh0DQo+ID4gPj4NCj4gPiA+PiBI aSBhbGwsDQo+ID4gPj4NCj4gPiA+PiBUaGlzIGlzIGEgc2hvcnQgZHJhZnQgdG8gbWFrZSBSVEMg YXBwbGljYWJsZSBpbiBoaWVyYXJjaGljYWwgUlIgc2NlbmFyaW8uDQo+ID4gPj4NCj4gPiA+PiBD b21tZW50cyBhcmUgd2VsY29tZS4NCj4gPiA+Pg0KPiA+ID4+IEJlc3QgcmVnYXJkcywNCj4gPiA+ PiBKaWUNCj4gPiA+Pg0KPiA+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ PiA+DQo+ID4gPj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZG9uZy1pZHItcnRjLWhp ZXJhcmNoaWNhbC1yci0wMC50eHQNCj4gPiA+PiA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgSmllIERvbmcgYW5kIHBvc3RlZCB0byB0aGUNCj4gPiA+PiA+IElFVEYNCj4gPiA+ PiByZXBvc2l0b3J5Lg0KPiA+ID4+ID4NCj4gPiA+PiA+IE5hbWU6ICAgICAgICAgICAgICAgZHJh ZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1ycg0KPiA+ID4+ID4gUmV2aXNpb246ICAgMDAN Cj4gPiA+PiA+IFRpdGxlOiAgICAgICAgICAgICAgRXh0ZW5zaW9ucyB0byBSVC1Db25zdHJhaW4g aW4gSGllcmFyY2hpY2FsIFJvdXRlDQo+IFJlZmxlY3Rpb24NCj4gPiA+PiA+IFNjZW5hcmlvcw0K PiA+ID4+ID4gRG9jdW1lbnQgZGF0ZTogICAgICAyMDE0LTA2LTE5DQo+ID4gPj4gPiBHcm91cDog ICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+ID4+ID4gUGFnZXM6ICAgICAg ICAgICAgICA1DQo+ID4gPj4gPiBVUkw6DQo+ID4gPj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpYw0KPiA+ID4+ID4gYWwN Cj4gPiA+PiA+IC1ycg0KPiA+ID4+ID4gLTAwLnR4dA0KPiA+ID4+ID4gU3RhdHVzOg0KPiA+ID4+ ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZG9uZy1pZHItcnRjLWhp ZXJhcmNoaWNhbC0NCj4gPiA+PiA+IHJyDQo+ID4gPj4gPiAvDQo+ID4gPj4gPiBIdG1saXplZDoN Cj4gPiA+PiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbmctaWRyLXJ0Yy1o aWVyYXJjaGljYWwtcnItMDANCj4gPiA+PiA+DQo+ID4gPj4gPg0KPiA+ID4+ID4gQWJzdHJhY3Q6 DQo+ID4gPj4gPiAgICBUaGUgUm91dGUgVGFyZ2V0IChSVCkgQ29uc3RyYWluIG1lY2hhbmlzbSBz cGVjaWZpZWQgaW4gUkZDIDQ2ODQgaXMNCj4gPiA+PiA+ICAgIHVzZWQgdG8gYnVpbGQgYSByb3V0 ZSBkaXN0cmlidXRpb24gZ3JhcGggaW4gb3JkZXIgdG8gcmVzdHJpY3QgdGhlDQo+ID4gPj4gPiAg ICBwcm9wYWdhdGlvbiBvZiBWaXJ0dWFsIFByaXZhdGUgTmV0d29yayAoVlBOKSByb3V0ZXMuICBJ biBuZXR3b3JrDQo+ID4gPj4gPiAgICBzY2VuYXJpb3Mgd2hlcmUgaGllcmFyY2hpY2FsIHJvdXRl IHJlZmxlY3Rpb24gKFJSKSBpcyB1c2VkLCB0aGUNCj4gPiA+PiA+ICAgIGV4aXN0aW5nIFJULUNv bnN0cmFpbiBtZWNoYW5pc20gY2Fubm90IGJ1aWxkIGEgY29ycmVjdCByb3V0ZQ0KPiA+ID4+ID4g ICAgZGlzdHJpYnV0aW9uIGdyYXBoLiAgVGhpcyBkb2N1bWVudCByZWZpbmVzIHRoZSByb3V0ZSBk aXN0cmlidXRpb24NCj4gPiA+PiA+ICAgIHJ1bGVzIG9mIFJULUNvbnN0cmFpbiB0byBhZGRyZXNz IHRoZSBoaWVyYXJjaGljYWwgUlIgc2NlbmFyaW9zLg0KPiA+ID4+ID4NCj4gPiA+PiA+DQo+ID4g Pj4gPg0KPiA+ID4+ID4NCj4gPiA+PiA+DQo+ID4gPj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+ID4+ID4gc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0DQo+ID4gdG9vbHMuaWV0Zi5vcmcuDQo+ID4gPj4gPg0KPiA+ID4+ID4gVGhlIElFVEYgU2Vj cmV0YXJpYXQNCj4gPiA+Pg0KPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gPj4gSWRyIG1haWxpbmcgbGlzdA0KPiA+ID4+IElkckBpZXRm Lm9yZw0KPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+ ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiA+IElkciBtYWlsaW5nIGxpc3QNCj4gPiA+IElkckBpZXRmLm9yZw0KPiA+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg== From nobody Sun Jun 22 23:08:35 2014 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 EE39A1B2991 for ; Sun, 22 Jun 2014 23:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO27VNsDkKbM for ; Sun, 22 Jun 2014 23:08:08 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6F01A01A5 for ; Sun, 22 Jun 2014 23:08:01 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id x19so5421803ier.2 for ; Sun, 22 Jun 2014 23:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZQZZUGZT7ZPWIox0nBf2GI42YwsyzgULnj4qm808gxs=; b=mZQ97x/urXe6p/TMJqVJIYtkEs11lKsBVsETGu+D34SjWDdcFWrXtiWk+bVu81amIk Nbf1tJr8JrHdcyuroFfEEkqOmr4Zr1Y4knCq5N7D8Y7t5oDMDwZGT12tt4oZoNU+oxe2 iokv5NQC77Xxm+fYAyo/YGVGCIrNdDgoyDe/IMuIB5h0l65vZGGRCFkA3nHUW6S7ysge rOpa9sh79UTx403b5y1EXtHWfopMqmhaniIa+4lswHKP8KGcumlpGOaq9Xzn4+oufYK4 WRtDQqcqciW9JMmQi6US9m1f3+smNpEy97PLZzDPmCq7/BcG26G1MB1djINt6Rk6BQPp 4Vqg== MIME-Version: 1.0 X-Received: by 10.43.53.73 with SMTP id vp9mr19405578icb.61.1403503681216; Sun, 22 Jun 2014 23:08:01 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Sun, 22 Jun 2014 23:08:00 -0700 (PDT) In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> Date: Mon, 23 Jun 2014 08:08:00 +0200 X-Google-Sender-Auth: u_tldj54h-KqgLgPflCcwonWm34 Message-ID: From: Robert Raszuk To: "Dongjie (Jimmy)" Content-Type: multipart/alternative; boundary=bcaec5299be35c258604fc7aaa5e Archived-At: http://mailarchive.ietf.org/arch/msg/idr/LC6AuiGTqm_X4xpDMjKM2YSqNb4 Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 06:08:11 -0000 X-List-Received-Date: Mon, 23 Jun 2014 06:08:11 -0000 --bcaec5299be35c258604fc7aaa5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jie, > we still need to specify the rules of which RTC routes should be advertised to > solve this problem. Not really, Just use add-paths option "all" and your scenarios will work just fine ;) =E2=80=8BCheers, R.=E2=80=8B =E2=80=8B> =E2=80=8B On Mon, Jun 23, 2014 at 4:59 AM, Dongjie (Jimmy) wrote: > Hi Adam, > > If RD is part of the RTC routes, this problem will not occur:) While as > analyzed in rfc 4684, this requires more RTC routes being exchanged and > kept in the local AS. > > I agree that add-path is a candidate solution to this problem, while when > enabling add-path on RTC AFI/SAFI, we still need to specify the rules of > which RTC routes should be advertised to solve this problem. Or we just > update the rules of RTC advertisement as the other RTC related new drafts= ? > > Many thanks, > Jie > > > -----Original Message----- > > From: Vitkovsk=C3=BD Adam [mailto:adam.vitkovsky@swan.sk] > > Sent: Sunday, June 22, 2014 3:20 AM > > To: Robert Raszuk > > Cc: Dongjie (Jimmy); idr@ietf.org > > Subject: RE: [Idr] New Version Notification for > > draft-dong-idr-rtc-hierarchical-rr-00.txt > > > > Aah I see :) > > Well we could have that one solved if RD would be part of the RTC route= s > :) > > (though I understand one could use RTC for non VPN routes as well so...= ) > > Anyways so than as you mentioned add-path on the RTC AF seems as the be= st > > option then. > > > > adam > > > -----Original Message----- > > > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Rober= t > > > Raszuk > > > Sent: Saturday, June 21, 2014 7:52 PM > > > To: Vitkovsk=C3=BD Adam > > > Cc: Dongjie (Jimmy); idr@ietf.org > > > Subject: Re: [Idr] New Version Notification for > > > draft-dong-idr-rtc-hierarchical- rr-00.txt > > > > > > Hi Adam, > > > > > > Jie is describing RT routes not VPN routes. Your story does not apply > > > to RT routes as format of RT NLRI is well defined by RFC ;) > > > > > > Besides MPLS network or not has nothing to do with it .... > > > > > > Best, > > > R. > > > > > > On Sat, Jun 21, 2014 at 7:19 PM, Vitkovsk=C3=BD Adam > > > > > > wrote: > > > > Hi Jie, > > > > Well the correctly designed MPLS networks use unique per PE per VRF > > > > RDs > > > in form of RID:xxxxx. > > > > Unique per PE RDs makes all copies of the same VPN prefix received > > > > from > > > different PEs unique so RRs will select all as best path and > > > distribute them accordingly, which solves this and many other issues. > > > > > > > > In other words if someone tries to shoot himself in the foot I > > > > wouldn't > > > develop bulletproof boots for him. > > > > > > > > adam > > > >> -----Original Message----- > > > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie > > > >> (Jimmy) > > > >> Sent: Friday, June 20, 2014 4:55 AM > > > >> To: idr@ietf.org > > > >> Subject: [Idr] FW: New Version Notification for draft-dong-idr-rtc= - > > > >> hierarchical-rr-00.txt > > > >> > > > >> Hi all, > > > >> > > > >> This is a short draft to make RTC applicable in hierarchical RR > scenario. > > > >> > > > >> Comments are welcome. > > > >> > > > >> Best regards, > > > >> Jie > > > >> > > > >> > -----Original Message----- > > > >> > > > > >> > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > > > >> > has been successfully submitted by Jie Dong and posted to the > > > >> > IETF > > > >> repository. > > > >> > > > > >> > Name: draft-dong-idr-rtc-hierarchical-rr > > > >> > Revision: 00 > > > >> > Title: Extensions to RT-Constrain in Hierarchical > Route > > Reflection > > > >> > Scenarios > > > >> > Document date: 2014-06-19 > > > >> > Group: Individual Submission > > > >> > Pages: 5 > > > >> > URL: > > > >> > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchi= c > > > >> > al > > > >> > -rr > > > >> > -00.txt > > > >> > Status: > > > >> > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical= - > > > >> > rr > > > >> > / > > > >> > Htmlized: > > > >> > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 > > > >> > > > > >> > > > > >> > Abstract: > > > >> > The Route Target (RT) Constrain mechanism specified in RFC > 4684 is > > > >> > used to build a route distribution graph in order to restrict > the > > > >> > propagation of Virtual Private Network (VPN) routes. In > network > > > >> > scenarios where hierarchical route reflection (RR) is used, t= he > > > >> > existing RT-Constrain mechanism cannot build a correct route > > > >> > distribution graph. This document refines the route > distribution > > > >> > rules of RT-Constrain to address the hierarchical RR scenario= s. > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > Please note that it may take a couple of minutes from the time o= f > > > >> > submission until the htmlized version and diff are available at > > > tools.ietf.org. > > > >> > > > > >> > The IETF Secretariat > > > >> > > > >> _______________________________________________ > > > >> Idr mailing list > > > >> Idr@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/idr > > > > > > > > _______________________________________________ > > > > Idr mailing list > > > > Idr@ietf.org > > > > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --bcaec5299be35c258604fc7aaa5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jie,

> we sti= ll need to specify the rules of which RTC routes should be advertised to=C2= =A0
> solve this p= roblem.

= Not really, =C2=A0Just use add-paths option "all" and your scenar= ios will work just fine ;)

=E2=80=8BCheers,
R.=E2=80=8B


=E2=80=8B> =E2=80=8B
On Mon,= Jun 23, 2014 at 4:59 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:
Hi Adam,

If RD is part of the RTC routes, this problem will not occur:) While as ana= lyzed in rfc 4684, this requires more RTC routes being exchanged and kept i= n the local AS.

I agree that add-path is a candidate solution to this problem, while when e= nabling add-path on RTC AFI/SAFI, we still need to specify the rules of whi= ch RTC routes should be advertised to solve this problem. Or we just update= the rules of RTC advertisement as the other RTC related new drafts?

Many thanks,
Jie

> -----Original Message-----
> From: Vitkovsk=C3=BD Adam [mailto:adam.vitkovsky@swan.sk]
> Sent: Sunday, June 22, 2014 3:20 AM
> To: Robert Raszuk
> Cc: Dongjie (Jimmy); idr@ietf.org<= br>
> Subject: RE: [Idr] New Version= Notification for
> draft-dong-idr-rtc-hierarchical-rr-00.txt
>
> Aah I see :)
> Well we could have that one solved if RD would be part of the RTC rout= es :)
> (though I understand one could use RTC for non VPN routes as well so..= .)
> Anyways so than as you mentioned add-path on the RTC AF seems as the b= est
> option then.
>
> adam
> > -----Original Message-----
> > From: rraszuk@gmail.com = [mailto:rraszuk@gmail.com] On Beha= lf Of Robert
> > Raszuk
> > Sent: Saturday, June 21, 2014 7:52 PM
> > To: Vitkovsk=C3=BD Adam
> > Cc: Dongjie (Jimmy); idr@ietf.org=
> > Subject: Re: [Idr] New Version Notification for
> > draft-dong-idr-rtc-hierarchical- rr-00.txt
> >
> > Hi Adam,
> >
> > Jie is describing RT routes not VPN routes. Your story does not a= pply
> > to RT routes as format of RT NLRI is well defined by RFC ;)
> >
> > Besides MPLS network or not has nothing to do with it ....
> >
> > Best,
> > R.
> >
> > On Sat, Jun 21, 2014 at 7:19 PM, Vitkovsk=C3=BD Adam
> > <adam.vitkovsky@swan= .sk>
> > wrote:
> > > Hi Jie,
> > > Well the correctly designed MPLS networks use unique per PE = per VRF
> > > RDs
> > in form of RID:xxxxx.
> > > Unique per PE RDs makes all copies of the same VPN prefix re= ceived
> > > from
> > different PEs unique so RRs will select all as best path and
> > distribute them accordingly, which solves this and many other iss= ues.
> > >
> > > In other words if someone tries to shoot himself in the foot= I
> > > wouldn't
> > develop bulletproof boots for him.
> > >
> > > adam
> > >> -----Original Message-----
> > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie
> > >> (Jimmy)
> > >> Sent: Friday, June 20, 2014 4:55 AM
> > >> To: idr@ietf.org
> > >> Subject: [Idr] FW: New Version Notification for draft-do= ng-idr-rtc-
> > >> hierarchical-rr-00.txt
> > >>
> > >> Hi all,
> > >>
> > >> This is a short draft to make RTC applicable in hierarch= ical RR scenario.
> > >>
> > >> Comments are welcome.
> > >>
> > >> Best regards,
> > >> Jie
> > >>
> > >> > -----Original Message-----
> > >> >
> > >> > A new version of I-D, draft-dong-idr-rtc-hierarchic= al-rr-00.txt
> > >> > has been successfully submitted by Jie Dong and pos= ted to the
> > >> > IETF
> > >> repository.
> > >> >
> > >> > Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 draft-dong-idr-rtc-hierarchical-rr
> > >> > Revision: =C2=A0 00
> > >> > Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Extensions to RT-Constrain in Hierarchical Route
> Reflection
> > >> > Scenarios
> > >> > Document date: =C2=A0 =C2=A0 =C2=A02014-06-19
> > >> > Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Individual Submission
> > >> > Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A05
> > >> > URL:
> > >> > = http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchic
> > >> > al
> > >> > -rr
> > >> > -00.txt
> > >> > Status:
> > >> > https://datatracker.ietf.org/d= oc/draft-dong-idr-rtc-hierarchical-
> > >> > rr
> > >> > /
> > >> > Htmlized:
> > >> > http://tools.ietf.org/html/draf= t-dong-idr-rtc-hierarchical-rr-00
> > >> >
> > >> >
> > >> > Abstract:
> > >> > =C2=A0 =C2=A0The Route Target (RT) Constrain mechan= ism specified in RFC 4684 is
> > >> > =C2=A0 =C2=A0used to build a route distribution gra= ph in order to restrict the
> > >> > =C2=A0 =C2=A0propagation of Virtual Private Network= (VPN) routes. =C2=A0In network
> > >> > =C2=A0 =C2=A0scenarios where hierarchical route ref= lection (RR) is used, the
> > >> > =C2=A0 =C2=A0existing RT-Constrain mechanism cannot= build a correct route
> > >> > =C2=A0 =C2=A0distribution graph. =C2=A0This documen= t refines the route distribution
> > >> > =C2=A0 =C2=A0rules of RT-Constrain to address the h= ierarchical RR scenarios.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > Please note that it may take a couple of minutes fr= om the time of
> > >> > submission until the htmlized version and diff are = available at
> > tools.ietf.or= g.
> > >> >
> > >> > The IETF Secretariat
> > >>
> > >> _______________________________________________
> > >> Idr mailing list
> > >> Idr@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/idr
> > >
> > > _______________________________________________
> > > Idr mailing list
> > > Idr@ietf.org
> > > https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--bcaec5299be35c258604fc7aaa5e-- From nobody Mon Jun 23 00:31:46 2014 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 EE03B1B29D8 for ; Mon, 23 Jun 2014 00:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11DpfMAmc1JA for ; Mon, 23 Jun 2014 00:31:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12171B29D2 for ; Mon, 23 Jun 2014 00:31:39 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 35CA2C0841; Mon, 23 Jun 2014 09:31:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 1209CC805D; Mon, 23 Jun 2014 09:31:37 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Mon, 23 Jun 2014 09:31:37 +0200 From: To: Robert Raszuk , "Dongjie (Jimmy)" Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//+xkgIAAOCmwgAHzEgCAADSyAIAAOJpw Date: Mon, 23 Jun 2014 07:31:36 +0000 Message-ID: <20475_1403508697_53A7D7D9_20475_15506_1_9E32478DFA9976438E7A22F69B08FF92023229@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92023229OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.23.13921 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/P_7BQh2igL0-IdQ6Ricpl6TDgkA Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 07:31:44 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92023229OPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjYW4gcmVtZW1iZXIgc29tZSBwZW9wbGUgdGhhdCBkb2VzIG5vdCB3YW50IHRvIGltcGxlbWVu dCDigJxhZGQtcGF0aCBhbGzigJ0g4pi6DQoNCg0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBNb25kYXksIEp1 bmUgMjMsIDIwMTQgMDg6MDgNClRvOiBEb25namllIChKaW1teSkNCkNjOiBpZHJAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbSWRyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRv bmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAudHh0DQoNCkhpIEppZSwNCg0KPiB3ZSBzdGls bCBuZWVkIHRvIHNwZWNpZnkgdGhlIHJ1bGVzIG9mIHdoaWNoIFJUQyByb3V0ZXMgc2hvdWxkIGJl IGFkdmVydGlzZWQgdG8NCj4gc29sdmUgdGhpcyBwcm9ibGVtLg0KDQpOb3QgcmVhbGx5LCAgSnVz dCB1c2UgYWRkLXBhdGhzIG9wdGlvbiAiYWxsIiBhbmQgeW91ciBzY2VuYXJpb3Mgd2lsbCB3b3Jr IGp1c3QgZmluZSA7KQ0KDQrigItDaGVlcnMsDQpSLuKAiw0KDQoNCuKAiz4g4oCLDQpPbiBNb24s IEp1biAyMywgMjAxNCBhdCA0OjU5IEFNLCBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdl aS5jb208bWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIEFkYW0sDQoNCklm IFJEIGlzIHBhcnQgb2YgdGhlIFJUQyByb3V0ZXMsIHRoaXMgcHJvYmxlbSB3aWxsIG5vdCBvY2N1 cjopIFdoaWxlIGFzIGFuYWx5emVkIGluIHJmYyA0Njg0LCB0aGlzIHJlcXVpcmVzIG1vcmUgUlRD IHJvdXRlcyBiZWluZyBleGNoYW5nZWQgYW5kIGtlcHQgaW4gdGhlIGxvY2FsIEFTLg0KDQpJIGFn cmVlIHRoYXQgYWRkLXBhdGggaXMgYSBjYW5kaWRhdGUgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVt LCB3aGlsZSB3aGVuIGVuYWJsaW5nIGFkZC1wYXRoIG9uIFJUQyBBRkkvU0FGSSwgd2Ugc3RpbGwg bmVlZCB0byBzcGVjaWZ5IHRoZSBydWxlcyBvZiB3aGljaCBSVEMgcm91dGVzIHNob3VsZCBiZSBh ZHZlcnRpc2VkIHRvIHNvbHZlIHRoaXMgcHJvYmxlbS4gT3Igd2UganVzdCB1cGRhdGUgdGhlIHJ1 bGVzIG9mIFJUQyBhZHZlcnRpc2VtZW50IGFzIHRoZSBvdGhlciBSVEMgcmVsYXRlZCBuZXcgZHJh ZnRzPw0KDQpNYW55IHRoYW5rcywNCkppZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFZpdGtvdnNrw70gQWRhbSBbbWFpbHRvOmFkYW0udml0a292c2t5QHN3YW4uc2s8 bWFpbHRvOmFkYW0udml0a292c2t5QHN3YW4uc2s+XQ0KPiBTZW50OiBTdW5kYXksIEp1bmUgMjIs IDIwMTQgMzoyMCBBTQ0KPiBUbzogUm9iZXJ0IFJhc3p1aw0KPiBDYzogRG9uZ2ppZSAoSmltbXkp OyBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IFtJZHJd IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJh cmNoaWNhbC1yci0wMC50eHQNCj4NCj4gQWFoIEkgc2VlIDopDQo+IFdlbGwgd2UgY291bGQgaGF2 ZSB0aGF0IG9uZSBzb2x2ZWQgaWYgUkQgd291bGQgYmUgcGFydCBvZiB0aGUgUlRDIHJvdXRlcyA6 KQ0KPiAodGhvdWdoIEkgdW5kZXJzdGFuZCBvbmUgY291bGQgdXNlIFJUQyBmb3Igbm9uIFZQTiBy b3V0ZXMgYXMgd2VsbCBzby4uLikNCj4gQW55d2F5cyBzbyB0aGFuIGFzIHlvdSBtZW50aW9uZWQg YWRkLXBhdGggb24gdGhlIFJUQyBBRiBzZWVtcyBhcyB0aGUgYmVzdA0KPiBvcHRpb24gdGhlbi4N Cj4NCj4gYWRhbQ0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogcnJh c3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPiBbbWFpbHRvOnJyYXN6dWtA Z21haWwuY29tPG1haWx0bzpycmFzenVrQGdtYWlsLmNvbT5dIE9uIEJlaGFsZiBPZiBSb2JlcnQN Cj4gPiBSYXN6dWsNCj4gPiBTZW50OiBTYXR1cmRheSwgSnVuZSAyMSwgMjAxNCA3OjUyIFBNDQo+ ID4gVG86IFZpdGtvdnNrw70gQWRhbQ0KPiA+IENjOiBEb25namllIChKaW1teSk7IGlkckBpZXRm Lm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJlOiBbSWRyXSBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNh bC0gcnItMDAudHh0DQo+ID4NCj4gPiBIaSBBZGFtLA0KPiA+DQo+ID4gSmllIGlzIGRlc2NyaWJp bmcgUlQgcm91dGVzIG5vdCBWUE4gcm91dGVzLiBZb3VyIHN0b3J5IGRvZXMgbm90IGFwcGx5DQo+ ID4gdG8gUlQgcm91dGVzIGFzIGZvcm1hdCBvZiBSVCBOTFJJIGlzIHdlbGwgZGVmaW5lZCBieSBS RkMgOykNCj4gPg0KPiA+IEJlc2lkZXMgTVBMUyBuZXR3b3JrIG9yIG5vdCBoYXMgbm90aGluZyB0 byBkbyB3aXRoIGl0IC4uLi4NCj4gPg0KPiA+IEJlc3QsDQo+ID4gUi4NCj4gPg0KPiA+IE9uIFNh dCwgSnVuIDIxLCAyMDE0IGF0IDc6MTkgUE0sIFZpdGtvdnNrw70gQWRhbQ0KPiA+IDxhZGFtLnZp dGtvdnNreUBzd2FuLnNrPG1haWx0bzphZGFtLnZpdGtvdnNreUBzd2FuLnNrPj4NCj4gPiB3cm90 ZToNCj4gPiA+IEhpIEppZSwNCj4gPiA+IFdlbGwgdGhlIGNvcnJlY3RseSBkZXNpZ25lZCBNUExT IG5ldHdvcmtzIHVzZSB1bmlxdWUgcGVyIFBFIHBlciBWUkYNCj4gPiA+IFJEcw0KPiA+IGluIGZv cm0gb2YgUklEOnh4eHh4Lg0KPiA+ID4gVW5pcXVlIHBlciBQRSBSRHMgbWFrZXMgYWxsIGNvcGll cyBvZiB0aGUgc2FtZSBWUE4gcHJlZml4IHJlY2VpdmVkDQo+ID4gPiBmcm9tDQo+ID4gZGlmZmVy ZW50IFBFcyB1bmlxdWUgc28gUlJzIHdpbGwgc2VsZWN0IGFsbCBhcyBiZXN0IHBhdGggYW5kDQo+ ID4gZGlzdHJpYnV0ZSB0aGVtIGFjY29yZGluZ2x5LCB3aGljaCBzb2x2ZXMgdGhpcyBhbmQgbWFu eSBvdGhlciBpc3N1ZXMuDQo+ID4gPg0KPiA+ID4gSW4gb3RoZXIgd29yZHMgaWYgc29tZW9uZSB0 cmllcyB0byBzaG9vdCBoaW1zZWxmIGluIHRoZSBmb290IEkNCj4gPiA+IHdvdWxkbid0DQo+ID4g ZGV2ZWxvcCBidWxsZXRwcm9vZiBib290cyBmb3IgaGltLg0KPiA+ID4NCj4gPiA+IGFkYW0NCj4g PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IElkciBbbWFpbHRv Omlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJl aGFsZiBPZiBEb25namllDQo+ID4gPj4gKEppbW15KQ0KPiA+ID4+IFNlbnQ6IEZyaWRheSwgSnVu ZSAyMCwgMjAxNCA0OjU1IEFNDQo+ID4gPj4gVG86IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGll dGYub3JnPg0KPiA+ID4+IFN1YmplY3Q6IFtJZHJdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWRvbmctaWRyLXJ0Yy0NCj4gPiA+PiBoaWVyYXJjaGljYWwtcnItMDAudHh0 DQo+ID4gPj4NCj4gPiA+PiBIaSBhbGwsDQo+ID4gPj4NCj4gPiA+PiBUaGlzIGlzIGEgc2hvcnQg ZHJhZnQgdG8gbWFrZSBSVEMgYXBwbGljYWJsZSBpbiBoaWVyYXJjaGljYWwgUlIgc2NlbmFyaW8u DQo+ID4gPj4NCj4gPiA+PiBDb21tZW50cyBhcmUgd2VsY29tZS4NCj4gPiA+Pg0KPiA+ID4+IEJl c3QgcmVnYXJkcywNCj4gPiA+PiBKaWUNCj4gPiA+Pg0KPiA+ID4+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+PiA+DQo+ID4gPj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQNCj4gPiA+PiA+IGhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmllIERvbmcgYW5kIHBvc3RlZCB0byB0aGUNCj4g PiA+PiA+IElFVEYNCj4gPiA+PiByZXBvc2l0b3J5Lg0KPiA+ID4+ID4NCj4gPiA+PiA+IE5hbWU6 ICAgICAgICAgICAgICAgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1ycg0KPiA+ID4+ ID4gUmV2aXNpb246ICAgMDANCj4gPiA+PiA+IFRpdGxlOiAgICAgICAgICAgICAgRXh0ZW5zaW9u cyB0byBSVC1Db25zdHJhaW4gaW4gSGllcmFyY2hpY2FsIFJvdXRlDQo+IFJlZmxlY3Rpb24NCj4g PiA+PiA+IFNjZW5hcmlvcw0KPiA+ID4+ID4gRG9jdW1lbnQgZGF0ZTogICAgICAyMDE0LTA2LTE5 DQo+ID4gPj4gPiBHcm91cDogICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+ ID4+ID4gUGFnZXM6ICAgICAgICAgICAgICA1DQo+ID4gPj4gPiBVUkw6DQo+ID4gPj4gPiBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFy Y2hpYw0KPiA+ID4+ID4gYWwNCj4gPiA+PiA+IC1ycg0KPiA+ID4+ID4gLTAwLnR4dA0KPiA+ID4+ ID4gU3RhdHVzOg0KPiA+ID4+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC0NCj4gPiA+PiA+IHJyDQo+ID4gPj4gPiAvDQo+ ID4gPj4gPiBIdG1saXplZDoNCj4gPiA+PiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDANCj4gPiA+PiA+DQo+ID4gPj4gPg0K PiA+ID4+ID4gQWJzdHJhY3Q6DQo+ID4gPj4gPiAgICBUaGUgUm91dGUgVGFyZ2V0IChSVCkgQ29u c3RyYWluIG1lY2hhbmlzbSBzcGVjaWZpZWQgaW4gUkZDIDQ2ODQgaXMNCj4gPiA+PiA+ICAgIHVz ZWQgdG8gYnVpbGQgYSByb3V0ZSBkaXN0cmlidXRpb24gZ3JhcGggaW4gb3JkZXIgdG8gcmVzdHJp Y3QgdGhlDQo+ID4gPj4gPiAgICBwcm9wYWdhdGlvbiBvZiBWaXJ0dWFsIFByaXZhdGUgTmV0d29y ayAoVlBOKSByb3V0ZXMuICBJbiBuZXR3b3JrDQo+ID4gPj4gPiAgICBzY2VuYXJpb3Mgd2hlcmUg aGllcmFyY2hpY2FsIHJvdXRlIHJlZmxlY3Rpb24gKFJSKSBpcyB1c2VkLCB0aGUNCj4gPiA+PiA+ ICAgIGV4aXN0aW5nIFJULUNvbnN0cmFpbiBtZWNoYW5pc20gY2Fubm90IGJ1aWxkIGEgY29ycmVj dCByb3V0ZQ0KPiA+ID4+ID4gICAgZGlzdHJpYnV0aW9uIGdyYXBoLiAgVGhpcyBkb2N1bWVudCBy ZWZpbmVzIHRoZSByb3V0ZSBkaXN0cmlidXRpb24NCj4gPiA+PiA+ICAgIHJ1bGVzIG9mIFJULUNv bnN0cmFpbiB0byBhZGRyZXNzIHRoZSBoaWVyYXJjaGljYWwgUlIgc2NlbmFyaW9zLg0KPiA+ID4+ ID4NCj4gPiA+PiA+DQo+ID4gPj4gPg0KPiA+ID4+ID4NCj4gPiA+PiA+DQo+ID4gPj4gPiBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZg0KPiA+ID4+ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+ID4gdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmll dGYub3JnPi4NCj4gPiA+PiA+DQo+ID4gPj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+ID4+ DQo+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+PiBJZHIgbWFpbGluZyBsaXN0DQo+ID4gPj4gSWRyQGlldGYub3JnPG1haWx0bzpJZHJA aWV0Zi5vcmc+DQo+ID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZHINCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+ID4gSWRyIG1haWxpbmcgbGlzdA0KPiA+ID4gSWRyQGlldGYub3JnPG1haWx0 bzpJZHJAaWV0Zi5vcmc+DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0KCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91LgoK --_000_9E32478DFA9976438E7A22F69B08FF92023229OPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHls ZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGNhbiByZW1lbWJlciBzb21l IHBlb3BsZSB0aGF0IGRvZXMgbm90IHdhbnQgdG8gaW1wbGVtZW50IOKAnGFkZC1wYXRoIGFsbOKA nQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldpbmdk aW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJZHIgW21haWx0bzppZHItYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMjMsIDIwMTQgMDg6MDg8YnI+DQo8Yj5Ubzo8L2I+IERv bmdqaWUgKEppbW15KTxicj4NCjxiPkNjOjwvYj4gaWRyQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbSWRyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbmct aWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+SGkgSmllLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgd2Ugc3RpbGwgbmVlZCB0byBz cGVjaWZ5IHRoZSBydWxlcyBvZiB3aGljaCBSVEMgcm91dGVzIHNob3VsZCBiZSBhZHZlcnRpc2Vk IHRvJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgc29sdmUgdGhpcyBwcm9ibGVtLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPk5vdCByZWFsbHksICZuYnNwO0p1c3QgdXNlIGFkZC1wYXRocyBvcHRpb24gJnF1b3Q7YWxs JnF1b3Q7IGFuZCB5b3VyIHNjZW5hcmlvcyB3aWxsIHdvcmsganVzdCBmaW5lIDspPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+4oCLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Q2hlZXJzLDxicj4NClIuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPuKAizwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+4oCLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jmd0Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YW1icmlhIE1hdGgmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdW4gMjMsIDIwMTQg YXQgNDo1OSBBTSwgRG9uZ2ppZSAoSmltbXkpICZsdDs8YSBocmVmPSJtYWlsdG86amllLmRvbmdA aHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmppZS5kb25nQGh1YXdlaS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFkYW0sPGJyPg0K PGJyPg0KSWYgUkQgaXMgcGFydCBvZiB0aGUgUlRDIHJvdXRlcywgdGhpcyBwcm9ibGVtIHdpbGwg bm90IG9jY3VyOikgV2hpbGUgYXMgYW5hbHl6ZWQgaW4gcmZjIDQ2ODQsIHRoaXMgcmVxdWlyZXMg bW9yZSBSVEMgcm91dGVzIGJlaW5nIGV4Y2hhbmdlZCBhbmQga2VwdCBpbiB0aGUgbG9jYWwgQVMu PGJyPg0KPGJyPg0KSSBhZ3JlZSB0aGF0IGFkZC1wYXRoIGlzIGEgY2FuZGlkYXRlIHNvbHV0aW9u IHRvIHRoaXMgcHJvYmxlbSwgd2hpbGUgd2hlbiBlbmFibGluZyBhZGQtcGF0aCBvbiBSVEMgQUZJ L1NBRkksIHdlIHN0aWxsIG5lZWQgdG8gc3BlY2lmeSB0aGUgcnVsZXMgb2Ygd2hpY2ggUlRDIHJv dXRlcyBzaG91bGQgYmUgYWR2ZXJ0aXNlZCB0byBzb2x2ZSB0aGlzIHByb2JsZW0uIE9yIHdlIGp1 c3QgdXBkYXRlIHRoZSBydWxlcyBvZiBSVEMgYWR2ZXJ0aXNlbWVudA0KIGFzIHRoZSBvdGhlciBS VEMgcmVsYXRlZCBuZXcgZHJhZnRzPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCk1hbnkgdGhhbmtzLDxicj4NCkppZTxicj4NCjxicj4NCiZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgRnJvbTogVml0a292c2vDvSBBZGFtIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmFkYW0udml0a292c2t5QHN3YW4uc2siPmFkYW0udml0a292c2t5QHN3YW4u c2s8L2E+XTxicj4NCiZndDsgU2VudDogU3VuZGF5LCBKdW5lIDIyLCAyMDE0IDM6MjAgQU08YnI+ DQomZ3Q7IFRvOiBSb2JlcnQgUmFzenVrPGJyPg0KJmd0OyBDYzogRG9uZ2ppZSAoSmltbXkpOyA8 YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBTdWJq ZWN0OiBSRTogW0lkcl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcjxicj4NCiZndDsgZHJh ZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBBYWggSSBzZWUgOik8YnI+DQomZ3Q7IFdlbGwgd2UgY291bGQgaGF2ZSB0aGF0IG9uZSBzb2x2 ZWQgaWYgUkQgd291bGQgYmUgcGFydCBvZiB0aGUgUlRDIHJvdXRlcyA6KTxicj4NCiZndDsgKHRo b3VnaCBJIHVuZGVyc3RhbmQgb25lIGNvdWxkIHVzZSBSVEMgZm9yIG5vbiBWUE4gcm91dGVzIGFz IHdlbGwgc28uLi4pPGJyPg0KJmd0OyBBbnl3YXlzIHNvIHRoYW4gYXMgeW91IG1lbnRpb25lZCBh ZGQtcGF0aCBvbiB0aGUgUlRDIEFGIHNlZW1zIGFzIHRoZSBiZXN0PGJyPg0KJmd0OyBvcHRpb24g dGhlbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBhZGFtPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzpycmFz enVrQGdtYWlsLmNvbSI+cnJhc3p1a0BnbWFpbC5jb208L2E+IFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnJyYXN6dWtAZ21haWwuY29tIj5ycmFzenVrQGdtYWlsLmNvbTwvYT5dIE9uIEJlaGFsZiBP ZiBSb2JlcnQ8YnI+DQomZ3Q7ICZndDsgUmFzenVrPGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFNhdHVy ZGF5LCBKdW5lIDIxLCAyMDE0IDc6NTIgUE08YnI+DQomZ3Q7ICZndDsgVG86IFZpdGtvdnNrw70g QWRhbTxicj4NCiZndDsgJmd0OyBDYzogRG9uZ2ppZSAoSmltbXkpOyA8YSBocmVmPSJtYWlsdG86 aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJl OiBbSWRyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yPGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0 LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtIHJyLTAwLnR4dDxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyBIaSBBZGFtLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBKaWUgaXMg ZGVzY3JpYmluZyBSVCByb3V0ZXMgbm90IFZQTiByb3V0ZXMuIFlvdXIgc3RvcnkgZG9lcyBub3Qg YXBwbHk8YnI+DQomZ3Q7ICZndDsgdG8gUlQgcm91dGVzIGFzIGZvcm1hdCBvZiBSVCBOTFJJIGlz IHdlbGwgZGVmaW5lZCBieSBSRkMgOyk8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQmVz aWRlcyBNUExTIG5ldHdvcmsgb3Igbm90IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggaXQgLi4uLjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBCZXN0LDxicj4NCiZndDsgJmd0OyBSLjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPbiBTYXQsIEp1biAyMSwgMjAxNCBhdCA3OjE5IFBN LCBWaXRrb3Zza8O9IEFkYW08YnI+DQomZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzphZGFt LnZpdGtvdnNreUBzd2FuLnNrIj5hZGFtLnZpdGtvdnNreUBzd2FuLnNrPC9hPiZndDs8YnI+DQom Z3Q7ICZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSGkgSmllLDxicj4NCiZndDsgJmd0 OyAmZ3Q7IFdlbGwgdGhlIGNvcnJlY3RseSBkZXNpZ25lZCBNUExTIG5ldHdvcmtzIHVzZSB1bmlx dWUgcGVyIFBFIHBlciBWUkY8YnI+DQomZ3Q7ICZndDsgJmd0OyBSRHM8YnI+DQomZ3Q7ICZndDsg aW4gZm9ybSBvZiBSSUQ6eHh4eHguPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVW5pcXVlIHBlciBQRSBS RHMgbWFrZXMgYWxsIGNvcGllcyBvZiB0aGUgc2FtZSBWUE4gcHJlZml4IHJlY2VpdmVkPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgZnJvbTxicj4NCiZndDsgJmd0OyBkaWZmZXJlbnQgUEVzIHVuaXF1ZSBz byBSUnMgd2lsbCBzZWxlY3QgYWxsIGFzIGJlc3QgcGF0aCBhbmQ8YnI+DQomZ3Q7ICZndDsgZGlz dHJpYnV0ZSB0aGVtIGFjY29yZGluZ2x5LCB3aGljaCBzb2x2ZXMgdGhpcyBhbmQgbWFueSBvdGhl ciBpc3N1ZXMuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBJbiBvdGhl ciB3b3JkcyBpZiBzb21lb25lIHRyaWVzIHRvIHNob290IGhpbXNlbGYgaW4gdGhlIGZvb3QgSTxi cj4NCiZndDsgJmd0OyAmZ3Q7IHdvdWxkbid0PGJyPg0KJmd0OyAmZ3Q7IGRldmVsb3AgYnVsbGV0 cHJvb2YgYm9vdHMgZm9yIGhpbS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7IGFkYW08YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgRnJvbTogSWRyIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl aGFsZiBPZiBEb25namllPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IChKaW1teSk8YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsgU2VudDogRnJpZGF5LCBKdW5lIDIwLCAyMDE0IDQ6NTUgQU08YnI+DQom Z3Q7ICZndDsgJmd0OyZndDsgVG86IDxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgU3ViamVjdDogW0lkcl0gRlc6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZG9uZy1pZHItcnRjLTxicj4NCiZndDsg Jmd0OyAmZ3Q7Jmd0OyBoaWVyYXJjaGljYWwtcnItMDAudHh0PGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7ICZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgVGhpcyBpcyBhIHNob3J0IGRyYWZ0IHRvIG1ha2Ug UlRDIGFwcGxpY2FibGUgaW4gaGllcmFyY2hpY2FsIFJSIHNjZW5hcmlvLjxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBDb21tZW50cyBhcmUgd2VsY29tZS48 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgQmVzdCByZWdh cmRzLDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBKaWU8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsg QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnIt MDAudHh0PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBKaWUgRG9uZyBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyAmZ3Q7IElFVEY8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgcmVwb3NpdG9yeS48YnI+ DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IE5h bWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkcmFm dC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZn dDsgUmV2aXNpb246ICZuYnNwOyAwMDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFRpdGxl OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtFeHRlbnNp b25zIHRvIFJULUNvbnN0cmFpbiBpbiBIaWVyYXJjaGljYWwgUm91dGU8YnI+DQomZ3Q7IFJlZmxl Y3Rpb248YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBTY2VuYXJpb3M8YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDsgJmd0OyBEb2N1bWVudCBkYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOzIwMTQt MDYtMTk8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBHcm91cDogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgUGFnZXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzU8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBV Ukw6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kb25n LWlkci1ydGMtaGllcmFyY2hpYzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBhbDxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IC1ycjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAm Z3Q7IC0wMC50eHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBTdGF0dXM6PGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC0iIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVy YXJjaGljYWwtPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHJyPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmZ3Q7 ICZndDsmZ3Q7ICZndDsgLzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEh0bWxpemVkOjxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVy YXJjaGljYWwtcnItMDA8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEFic3RyYWN0 Ojxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtUaGUgUm91dGUgVGFy Z2V0IChSVCkgQ29uc3RyYWluIG1lY2hhbmlzbSBzcGVjaWZpZWQgaW4gUkZDIDQ2ODQgaXM8YnI+ DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7dXNlZCB0byBidWlsZCBhIHJv dXRlIGRpc3RyaWJ1dGlvbiBncmFwaCBpbiBvcmRlciB0byByZXN0cmljdCB0aGU8YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7cHJvcGFnYXRpb24gb2YgVmlydHVhbCBQ cml2YXRlIE5ldHdvcmsgKFZQTikgcm91dGVzLiAmbmJzcDtJbiBuZXR3b3JrPGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3NjZW5hcmlvcyB3aGVyZSBoaWVyYXJjaGlj YWwgcm91dGUgcmVmbGVjdGlvbiAoUlIpIGlzIHVzZWQsIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtleGlzdGluZyBSVC1Db25zdHJhaW4gbWVjaGFuaXNtIGNh bm5vdCBidWlsZCBhIGNvcnJlY3Qgcm91dGU8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ZGlzdHJpYnV0aW9uIGdyYXBoLiAmbmJzcDtUaGlzIGRvY3VtZW50IHJlZmlu ZXMgdGhlIHJvdXRlIGRpc3RyaWJ1dGlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDtydWxlcyBvZiBSVC1Db25zdHJhaW4gdG8gYWRkcmVzcyB0aGUgaGllcmFyY2hp Y2FsIFJSIHNjZW5hcmlvcy48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0 OyBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQ8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgVGhlIElFVEYgU2VjcmV0YXJpYXQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0 OyZndDsgSWRyIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJt YWlsdG86SWRyQGlldGYub3JnIj5JZHJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHI8 L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7IElk ciBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86SWRyQGll dGYub3JnIj5JZHJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcjwvYT48YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkciBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWRyQGlldGYub3JnIj5JZHJAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk cjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_9E32478DFA9976438E7A22F69B08FF92023229OPEXCLILM34corpor_-- From nobody Mon Jun 23 00:47:56 2014 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 1EF0A1B29E7 for ; Mon, 23 Jun 2014 00:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 60yFtr3zgdWL for ; Mon, 23 Jun 2014 00:47:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41671B29D8 for ; Mon, 23 Jun 2014 00:47:45 -0700 (PDT) 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 BFZ41848; Mon, 23 Jun 2014 07:47:44 +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.158.1; Mon, 23 Jun 2014 08:47:42 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 23 Jun 2014 15:47:36 +0800 From: "Dongjie (Jimmy)" To: Robert Raszuk Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//4fPgIAAGG8AgAKT/sD//7OAAIAAoKmg Date: Mon, 23 Jun 2014 07:47:35 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273369E78B@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C9273369E78Bnkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/zT5yQ0fWdJXSC5-0IHxvlWrAO0M Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 07:47:55 -0000 --_000_76CD132C3ADEF848BD84D028D243C9273369E78Bnkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpNYXliZSBhZGQtcGF0aHMgb3B0aW9uIOKAnGFsbOKAnSBpcyBzb21ld2hh dCBvdmVya2lsbCBmb3Igc29sdmluZyB0aGlzIHNjZW5hcmlvPyA6KQ0KDQpCZXN0IHJlZ2FyZHMs DQpKaWUNCg0KRnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNv bV0gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IE1vbmRheSwgSnVuZSAyMywgMjAx NCAyOjA4IFBNDQpUbzogRG9uZ2ppZSAoSmltbXkpDQpDYzogVml0a292c2vDvSBBZGFtOyBpZHJA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAudHh0DQoNCkhpIEppZSwNCg0K PiB3ZSBzdGlsbCBuZWVkIHRvIHNwZWNpZnkgdGhlIHJ1bGVzIG9mIHdoaWNoIFJUQyByb3V0ZXMg c2hvdWxkIGJlIGFkdmVydGlzZWQgdG8NCj4gc29sdmUgdGhpcyBwcm9ibGVtLg0KDQpOb3QgcmVh bGx5LCAgSnVzdCB1c2UgYWRkLXBhdGhzIG9wdGlvbiAiYWxsIiBhbmQgeW91ciBzY2VuYXJpb3Mg d2lsbCB3b3JrIGp1c3QgZmluZSA7KQ0KDQrigItDaGVlcnMsDQpSLuKAiw0KDQoNCuKAiz4g4oCL DQpPbiBNb24sIEp1biAyMywgMjAxNCBhdCA0OjU5IEFNLCBEb25namllIChKaW1teSkgPGppZS5k b25nQGh1YXdlaS5jb208bWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIEFk YW0sDQoNCklmIFJEIGlzIHBhcnQgb2YgdGhlIFJUQyByb3V0ZXMsIHRoaXMgcHJvYmxlbSB3aWxs IG5vdCBvY2N1cjopIFdoaWxlIGFzIGFuYWx5emVkIGluIHJmYyA0Njg0LCB0aGlzIHJlcXVpcmVz IG1vcmUgUlRDIHJvdXRlcyBiZWluZyBleGNoYW5nZWQgYW5kIGtlcHQgaW4gdGhlIGxvY2FsIEFT Lg0KDQpJIGFncmVlIHRoYXQgYWRkLXBhdGggaXMgYSBjYW5kaWRhdGUgc29sdXRpb24gdG8gdGhp cyBwcm9ibGVtLCB3aGlsZSB3aGVuIGVuYWJsaW5nIGFkZC1wYXRoIG9uIFJUQyBBRkkvU0FGSSwg d2Ugc3RpbGwgbmVlZCB0byBzcGVjaWZ5IHRoZSBydWxlcyBvZiB3aGljaCBSVEMgcm91dGVzIHNo b3VsZCBiZSBhZHZlcnRpc2VkIHRvIHNvbHZlIHRoaXMgcHJvYmxlbS4gT3Igd2UganVzdCB1cGRh dGUgdGhlIHJ1bGVzIG9mIFJUQyBhZHZlcnRpc2VtZW50IGFzIHRoZSBvdGhlciBSVEMgcmVsYXRl ZCBuZXcgZHJhZnRzPw0KDQpNYW55IHRoYW5rcywNCkppZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFZpdGtvdnNrw70gQWRhbSBbbWFpbHRvOmFkYW0udml0a292c2t5 QHN3YW4uc2s8bWFpbHRvOmFkYW0udml0a292c2t5QHN3YW4uc2s+XQ0KPiBTZW50OiBTdW5kYXks IEp1bmUgMjIsIDIwMTQgMzoyMCBBTQ0KPiBUbzogUm9iZXJ0IFJhc3p1aw0KPiBDYzogRG9uZ2pp ZSAoSmltbXkpOyBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4NCj4gU3ViamVjdDog UkU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtZG9uZy1pZHIt cnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQNCj4NCj4gQWFoIEkgc2VlIDopDQo+IFdlbGwgd2Ug Y291bGQgaGF2ZSB0aGF0IG9uZSBzb2x2ZWQgaWYgUkQgd291bGQgYmUgcGFydCBvZiB0aGUgUlRD IHJvdXRlcyA6KQ0KPiAodGhvdWdoIEkgdW5kZXJzdGFuZCBvbmUgY291bGQgdXNlIFJUQyBmb3Ig bm9uIFZQTiByb3V0ZXMgYXMgd2VsbCBzby4uLikNCj4gQW55d2F5cyBzbyB0aGFuIGFzIHlvdSBt ZW50aW9uZWQgYWRkLXBhdGggb24gdGhlIFJUQyBBRiBzZWVtcyBhcyB0aGUgYmVzdA0KPiBvcHRp b24gdGhlbi4NCj4NCj4gYWRhbQ0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogcnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPiBbbWFpbHRv OnJyYXN6dWtAZ21haWwuY29tPG1haWx0bzpycmFzenVrQGdtYWlsLmNvbT5dIE9uIEJlaGFsZiBP ZiBSb2JlcnQNCj4gPiBSYXN6dWsNCj4gPiBTZW50OiBTYXR1cmRheSwgSnVuZSAyMSwgMjAxNCA3 OjUyIFBNDQo+ID4gVG86IFZpdGtvdnNrw70gQWRhbQ0KPiA+IENjOiBEb25namllIChKaW1teSk7 IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJlOiBbSWRy XSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gZHJhZnQtZG9uZy1pZHItcnRjLWhp ZXJhcmNoaWNhbC0gcnItMDAudHh0DQo+ID4NCj4gPiBIaSBBZGFtLA0KPiA+DQo+ID4gSmllIGlz IGRlc2NyaWJpbmcgUlQgcm91dGVzIG5vdCBWUE4gcm91dGVzLiBZb3VyIHN0b3J5IGRvZXMgbm90 IGFwcGx5DQo+ID4gdG8gUlQgcm91dGVzIGFzIGZvcm1hdCBvZiBSVCBOTFJJIGlzIHdlbGwgZGVm aW5lZCBieSBSRkMgOykNCj4gPg0KPiA+IEJlc2lkZXMgTVBMUyBuZXR3b3JrIG9yIG5vdCBoYXMg bm90aGluZyB0byBkbyB3aXRoIGl0IC4uLi4NCj4gPg0KPiA+IEJlc3QsDQo+ID4gUi4NCj4gPg0K PiA+IE9uIFNhdCwgSnVuIDIxLCAyMDE0IGF0IDc6MTkgUE0sIFZpdGtvdnNrw70gQWRhbQ0KPiA+ IDxhZGFtLnZpdGtvdnNreUBzd2FuLnNrPG1haWx0bzphZGFtLnZpdGtvdnNreUBzd2FuLnNrPj4N Cj4gPiB3cm90ZToNCj4gPiA+IEhpIEppZSwNCj4gPiA+IFdlbGwgdGhlIGNvcnJlY3RseSBkZXNp Z25lZCBNUExTIG5ldHdvcmtzIHVzZSB1bmlxdWUgcGVyIFBFIHBlciBWUkYNCj4gPiA+IFJEcw0K PiA+IGluIGZvcm0gb2YgUklEOnh4eHh4Lg0KPiA+ID4gVW5pcXVlIHBlciBQRSBSRHMgbWFrZXMg YWxsIGNvcGllcyBvZiB0aGUgc2FtZSBWUE4gcHJlZml4IHJlY2VpdmVkDQo+ID4gPiBmcm9tDQo+ ID4gZGlmZmVyZW50IFBFcyB1bmlxdWUgc28gUlJzIHdpbGwgc2VsZWN0IGFsbCBhcyBiZXN0IHBh dGggYW5kDQo+ID4gZGlzdHJpYnV0ZSB0aGVtIGFjY29yZGluZ2x5LCB3aGljaCBzb2x2ZXMgdGhp cyBhbmQgbWFueSBvdGhlciBpc3N1ZXMuDQo+ID4gPg0KPiA+ID4gSW4gb3RoZXIgd29yZHMgaWYg c29tZW9uZSB0cmllcyB0byBzaG9vdCBoaW1zZWxmIGluIHRoZSBmb290IEkNCj4gPiA+IHdvdWxk bid0DQo+ID4gZGV2ZWxvcCBidWxsZXRwcm9vZiBib290cyBmb3IgaGltLg0KPiA+ID4NCj4gPiA+ IGFkYW0NCj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IElk ciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNlc0BpZXRmLm9y Zz5dIE9uIEJlaGFsZiBPZiBEb25namllDQo+ID4gPj4gKEppbW15KQ0KPiA+ID4+IFNlbnQ6IEZy aWRheSwgSnVuZSAyMCwgMjAxNCA0OjU1IEFNDQo+ID4gPj4gVG86IGlkckBpZXRmLm9yZzxtYWls dG86aWRyQGlldGYub3JnPg0KPiA+ID4+IFN1YmplY3Q6IFtJZHJdIEZXOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbmctaWRyLXJ0Yy0NCj4gPiA+PiBoaWVyYXJjaGljYWwt cnItMDAudHh0DQo+ID4gPj4NCj4gPiA+PiBIaSBhbGwsDQo+ID4gPj4NCj4gPiA+PiBUaGlzIGlz IGEgc2hvcnQgZHJhZnQgdG8gbWFrZSBSVEMgYXBwbGljYWJsZSBpbiBoaWVyYXJjaGljYWwgUlIg c2NlbmFyaW8uDQo+ID4gPj4NCj4gPiA+PiBDb21tZW50cyBhcmUgd2VsY29tZS4NCj4gPiA+Pg0K PiA+ID4+IEJlc3QgcmVnYXJkcywNCj4gPiA+PiBKaWUNCj4gPiA+Pg0KPiA+ID4+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+PiA+DQo+ID4gPj4gPiBBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQNCj4gPiA+PiA+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmllIERvbmcgYW5kIHBvc3RlZCB0 byB0aGUNCj4gPiA+PiA+IElFVEYNCj4gPiA+PiByZXBvc2l0b3J5Lg0KPiA+ID4+ID4NCj4gPiA+ PiA+IE5hbWU6ICAgICAgICAgICAgICAgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1y cg0KPiA+ID4+ID4gUmV2aXNpb246ICAgMDANCj4gPiA+PiA+IFRpdGxlOiAgICAgICAgICAgICAg RXh0ZW5zaW9ucyB0byBSVC1Db25zdHJhaW4gaW4gSGllcmFyY2hpY2FsIFJvdXRlDQo+IFJlZmxl Y3Rpb24NCj4gPiA+PiA+IFNjZW5hcmlvcw0KPiA+ID4+ID4gRG9jdW1lbnQgZGF0ZTogICAgICAy MDE0LTA2LTE5DQo+ID4gPj4gPiBHcm91cDogICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KPiA+ID4+ID4gUGFnZXM6ICAgICAgICAgICAgICA1DQo+ID4gPj4gPiBVUkw6DQo+ID4g Pj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kb25nLWlkci1y dGMtaGllcmFyY2hpYw0KPiA+ID4+ID4gYWwNCj4gPiA+PiA+IC1ycg0KPiA+ID4+ID4gLTAwLnR4 dA0KPiA+ID4+ID4gU3RhdHVzOg0KPiA+ID4+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC0NCj4gPiA+PiA+IHJyDQo+ID4g Pj4gPiAvDQo+ID4gPj4gPiBIdG1saXplZDoNCj4gPiA+PiA+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDANCj4gPiA+PiA+DQo+ ID4gPj4gPg0KPiA+ID4+ID4gQWJzdHJhY3Q6DQo+ID4gPj4gPiAgICBUaGUgUm91dGUgVGFyZ2V0 IChSVCkgQ29uc3RyYWluIG1lY2hhbmlzbSBzcGVjaWZpZWQgaW4gUkZDIDQ2ODQgaXMNCj4gPiA+ PiA+ICAgIHVzZWQgdG8gYnVpbGQgYSByb3V0ZSBkaXN0cmlidXRpb24gZ3JhcGggaW4gb3JkZXIg dG8gcmVzdHJpY3QgdGhlDQo+ID4gPj4gPiAgICBwcm9wYWdhdGlvbiBvZiBWaXJ0dWFsIFByaXZh dGUgTmV0d29yayAoVlBOKSByb3V0ZXMuICBJbiBuZXR3b3JrDQo+ID4gPj4gPiAgICBzY2VuYXJp b3Mgd2hlcmUgaGllcmFyY2hpY2FsIHJvdXRlIHJlZmxlY3Rpb24gKFJSKSBpcyB1c2VkLCB0aGUN Cj4gPiA+PiA+ICAgIGV4aXN0aW5nIFJULUNvbnN0cmFpbiBtZWNoYW5pc20gY2Fubm90IGJ1aWxk IGEgY29ycmVjdCByb3V0ZQ0KPiA+ID4+ID4gICAgZGlzdHJpYnV0aW9uIGdyYXBoLiAgVGhpcyBk b2N1bWVudCByZWZpbmVzIHRoZSByb3V0ZSBkaXN0cmlidXRpb24NCj4gPiA+PiA+ICAgIHJ1bGVz IG9mIFJULUNvbnN0cmFpbiB0byBhZGRyZXNzIHRoZSBoaWVyYXJjaGljYWwgUlIgc2NlbmFyaW9z Lg0KPiA+ID4+ID4NCj4gPiA+PiA+DQo+ID4gPj4gPg0KPiA+ID4+ID4NCj4gPiA+PiA+DQo+ID4g Pj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZg0KPiA+ID4+ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+ID4gdG9vbHMuaWV0Zi5vcmc8aHR0cDov L3Rvb2xzLmlldGYub3JnPi4NCj4gPiA+PiA+DQo+ID4gPj4gPiBUaGUgSUVURiBTZWNyZXRhcmlh dA0KPiA+ID4+DQo+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiA+PiBJZHIgbWFpbGluZyBsaXN0DQo+ID4gPj4gSWRyQGlldGYub3JnPG1h aWx0bzpJZHJAaWV0Zi5vcmc+DQo+ID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pZHINCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gSWRyIG1haWxpbmcgbGlzdA0KPiA+ID4gSWRyQGlldGYu b3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0K --_000_76CD132C3ADEF848BD84D028D243C9273369E78Bnkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsN Cglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG 5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrm ibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUm9iZXJ0LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXliZSBhZGQtcGF0aHMgb3B0aW9uIOKAnGFsbOKA nSBpcyBzb21ld2hhdCBvdmVya2lsbCBmb3Igc29sdmluZyB0aGlzIHNjZW5hcmlvPyA6KQ0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkppZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg SnVuZSAyMywgMjAxNCAyOjA4IFBNPGJyPg0KPGI+VG86PC9iPiBEb25namllIChKaW1teSk8YnI+ DQo8Yj5DYzo8L2I+IFZpdGtvdnNrw70gQWRhbTsgaWRyQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbSWRyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbmct aWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPkhpIEppZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZndDsgd2Ugc3RpbGwgbmVlZCB0byBzcGVjaWZ5IHRoZSBydWxlcyBvZiB3aGljaCBSVEMgcm91 dGVzIHNob3VsZCBiZSBhZHZlcnRpc2VkIHRvJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jmd0OyBzb2x2ZSB0aGlzIHByb2JsZW0uPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Tm90IHJlYWxseSwgJm5ic3A7SnVz dCB1c2UgYWRkLXBhdGhzIG9wdGlvbiAmcXVvdDthbGwmcXVvdDsgYW5kIHlvdXIgc2NlbmFyaW9z IHdpbGwgd29yayBqdXN0IGZpbmUgOyk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oCLPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PkNoZWVycyw8YnI+DQpSLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oCLPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSBNYXRo JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0Ow0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSBNYXRoJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24g TW9uLCBKdW4gMjMsIDIwMTQgYXQgNDo1OSBBTSwgRG9uZ2ppZSAoSmltbXkpICZsdDs8YSBocmVm PSJtYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmppZS5kb25nQGh1 YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgQWRhbSw8YnI+DQo8YnI+DQpJZiBSRCBp cyBwYXJ0IG9mIHRoZSBSVEMgcm91dGVzLCB0aGlzIHByb2JsZW0gd2lsbCBub3Qgb2NjdXI6KSBX aGlsZSBhcyBhbmFseXplZCBpbiByZmMgNDY4NCwgdGhpcyByZXF1aXJlcyBtb3JlIFJUQyByb3V0 ZXMgYmVpbmcgZXhjaGFuZ2VkIGFuZCBrZXB0IGluIHRoZSBsb2NhbCBBUy48YnI+DQo8YnI+DQpJ IGFncmVlIHRoYXQgYWRkLXBhdGggaXMgYSBjYW5kaWRhdGUgc29sdXRpb24gdG8gdGhpcyBwcm9i bGVtLCB3aGlsZSB3aGVuIGVuYWJsaW5nIGFkZC1wYXRoIG9uIFJUQyBBRkkvU0FGSSwgd2Ugc3Rp bGwgbmVlZCB0byBzcGVjaWZ5IHRoZSBydWxlcyBvZiB3aGljaCBSVEMgcm91dGVzIHNob3VsZCBi ZSBhZHZlcnRpc2VkIHRvIHNvbHZlIHRoaXMgcHJvYmxlbS4gT3Igd2UganVzdCB1cGRhdGUgdGhl IHJ1bGVzIG9mIFJUQyBhZHZlcnRpc2VtZW50DQogYXMgdGhlIG90aGVyIFJUQyByZWxhdGVkIG5l dyBkcmFmdHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpNYW55IHRoYW5rcyw8YnI+DQpKaWU8YnI+DQo8 YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgRnJvbTogVml0a292c2vDvSBBZGFtIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFkYW0u dml0a292c2t5QHN3YW4uc2siPmFkYW0udml0a292c2t5QHN3YW4uc2s8L2E+XTxicj4NCiZndDsg U2VudDogU3VuZGF5LCBKdW5lIDIyLCAyMDE0IDM6MjAgQU08YnI+DQomZ3Q7IFRvOiBSb2JlcnQg UmFzenVrPGJyPg0KJmd0OyBDYzogRG9uZ2ppZSAoSmltbXkpOyA8YSBocmVmPSJtYWlsdG86aWRy QGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7IFN1YmplY3Q6IFJFOiBbSWRyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yPGJyPg0K Jmd0OyBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTAwLnR4dDxicj4NCiZndDs8 YnI+DQomZ3Q7IEFhaCBJIHNlZSA6KTxicj4NCiZndDsgV2VsbCB3ZSBjb3VsZCBoYXZlIHRoYXQg b25lIHNvbHZlZCBpZiBSRCB3b3VsZCBiZSBwYXJ0IG9mIHRoZSBSVEMgcm91dGVzIDopPGJyPg0K Jmd0OyAodGhvdWdoIEkgdW5kZXJzdGFuZCBvbmUgY291bGQgdXNlIFJUQyBmb3Igbm9uIFZQTiBy b3V0ZXMgYXMgd2VsbCBzby4uLik8YnI+DQomZ3Q7IEFueXdheXMgc28gdGhhbiBhcyB5b3UgbWVu dGlvbmVkIGFkZC1wYXRoIG9uIHRoZSBSVEMgQUYgc2VlbXMgYXMgdGhlIGJlc3Q8YnI+DQomZ3Q7 IG9wdGlvbiB0aGVuLjxicj4NCiZndDs8YnI+DQomZ3Q7IGFkYW08YnI+DQomZ3Q7ICZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTogPGEgaHJlZj0ibWFp bHRvOnJyYXN6dWtAZ21haWwuY29tIj5ycmFzenVrQGdtYWlsLmNvbTwvYT4gW21haWx0bzo8YSBo cmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iPnJyYXN6dWtAZ21haWwuY29tPC9hPl0gT24g QmVoYWxmIE9mIFJvYmVydDxicj4NCiZndDsgJmd0OyBSYXN6dWs8YnI+DQomZ3Q7ICZndDsgU2Vu dDogU2F0dXJkYXksIEp1bmUgMjEsIDIwMTQgNzo1MiBQTTxicj4NCiZndDsgJmd0OyBUbzogVml0 a292c2vDvSBBZGFtPGJyPg0KJmd0OyAmZ3Q7IENjOiBEb25namllIChKaW1teSk7IDxhIGhyZWY9 Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgU3Vi amVjdDogUmU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I8YnI+DQomZ3Q7ICZn dDsgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC0gcnItMDAudHh0PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IEhpIEFkYW0sPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IEppZSBpcyBkZXNjcmliaW5nIFJUIHJvdXRlcyBub3QgVlBOIHJvdXRlcy4gWW91ciBzdG9yeSBk b2VzIG5vdCBhcHBseTxicj4NCiZndDsgJmd0OyB0byBSVCByb3V0ZXMgYXMgZm9ybWF0IG9mIFJU IE5MUkkgaXMgd2VsbCBkZWZpbmVkIGJ5IFJGQyA7KTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBCZXNpZGVzIE1QTFMgbmV0d29yayBvciBub3QgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBp dCAuLi4uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEJlc3QsPGJyPg0KJmd0OyAmZ3Q7 IFIuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIFNhdCwgSnVuIDIxLCAyMDE0IGF0 IDc6MTkgUE0sIFZpdGtvdnNrw70gQWRhbTxicj4NCiZndDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFkYW0udml0a292c2t5QHN3YW4uc2siPmFkYW0udml0a292c2t5QHN3YW4uc2s8L2E+Jmd0 Ozxicj4NCiZndDsgJmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyBIaSBKaWUsPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgV2VsbCB0aGUgY29ycmVjdGx5IGRlc2lnbmVkIE1QTFMgbmV0d29ya3Mg dXNlIHVuaXF1ZSBwZXIgUEUgcGVyIFZSRjxicj4NCiZndDsgJmd0OyAmZ3Q7IFJEczxicj4NCiZn dDsgJmd0OyBpbiBmb3JtIG9mIFJJRDp4eHh4eC48YnI+DQomZ3Q7ICZndDsgJmd0OyBVbmlxdWUg cGVyIFBFIFJEcyBtYWtlcyBhbGwgY29waWVzIG9mIHRoZSBzYW1lIFZQTiBwcmVmaXggcmVjZWl2 ZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBmcm9tPGJyPg0KJmd0OyAmZ3Q7IGRpZmZlcmVudCBQRXMg dW5pcXVlIHNvIFJScyB3aWxsIHNlbGVjdCBhbGwgYXMgYmVzdCBwYXRoIGFuZDxicj4NCiZndDsg Jmd0OyBkaXN0cmlidXRlIHRoZW0gYWNjb3JkaW5nbHksIHdoaWNoIHNvbHZlcyB0aGlzIGFuZCBt YW55IG90aGVyIGlzc3Vlcy48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 IEluIG90aGVyIHdvcmRzIGlmIHNvbWVvbmUgdHJpZXMgdG8gc2hvb3QgaGltc2VsZiBpbiB0aGUg Zm9vdCBJPGJyPg0KJmd0OyAmZ3Q7ICZndDsgd291bGRuJ3Q8YnI+DQomZ3Q7ICZndDsgZGV2ZWxv cCBidWxsZXRwcm9vZiBib290cyBmb3IgaGltLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgYWRhbTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBGcm9tOiBJZHIgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmciPmlkci1ib3VuY2VzQGlldGYub3JnPC9h Pl0gT24gQmVoYWxmIE9mIERvbmdqaWU8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgKEppbW15KTxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMTQgNDo1NSBB TTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9y ZyI+aWRyQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBbSWRy XSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kb25nLWlkci1ydGMtPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IGhpZXJhcmNoaWNhbC1yci0wMC50eHQ8YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgSGkgYWxsLDxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBUaGlzIGlzIGEgc2hvcnQgZHJhZnQg dG8gbWFrZSBSVEMgYXBwbGljYWJsZSBpbiBoaWVyYXJjaGljYWwgUlIgc2NlbmFyaW8uPGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IENvbW1lbnRzIGFyZSB3 ZWxjb21lLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBC ZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IEppZTxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZn dDsgJmd0OyBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNo aWNhbC1yci0wMC50eHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppZSBEb25nIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgSUVURjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyByZXBvc2l0 b3J5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 ICZndDsgTmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGRyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnI8YnI+DQomZ3Q7ICZndDsgJmd0 OyZndDsgJmd0OyBSZXZpc2lvbjogJm5ic3A7IDAwPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZn dDsgVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0V4dGVuc2lvbnMgdG8gUlQtQ29uc3RyYWluIGluIEhpZXJhcmNoaWNhbCBSb3V0ZTxicj4NCiZn dDsgUmVmbGVjdGlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFNjZW5hcmlvczxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IERvY3VtZW50IGRhdGU6ICZuYnNwOyAmbmJzcDsgJm5i c3A7MjAxNC0wNi0xOTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEdyb3VwOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1p c3Npb248YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBQYWdlczogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7NTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7IFVSTDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsgJmd0OyZn dDsgJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1kb25nLWlkci1ydGMtaGllcmFyY2hpYyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWM8L2E+ PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgYWw8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsg Jmd0OyAtcnI8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAtMDAudHh0PGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7ICZndDsgU3RhdHVzOjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRvbmctaWRyLXJ0 Yy1oaWVyYXJjaGljYWwtIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLTwvYT48YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsgJmd0OyBycjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAm Z3Q7ICZndDsmZ3Q7ICZndDsgLzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEh0bWxpemVk Ojxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbmctaWRyLXJ0Yy1o aWVyYXJjaGljYWwtcnItMDA8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEFic3Ry YWN0Ojxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtUaGUgUm91dGUg VGFyZ2V0IChSVCkgQ29uc3RyYWluIG1lY2hhbmlzbSBzcGVjaWZpZWQgaW4gUkZDIDQ2ODQgaXM8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7dXNlZCB0byBidWlsZCBh IHJvdXRlIGRpc3RyaWJ1dGlvbiBncmFwaCBpbiBvcmRlciB0byByZXN0cmljdCB0aGU8YnI+DQom Z3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7cHJvcGFnYXRpb24gb2YgVmlydHVh bCBQcml2YXRlIE5ldHdvcmsgKFZQTikgcm91dGVzLiAmbmJzcDtJbiBuZXR3b3JrPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3NjZW5hcmlvcyB3aGVyZSBoaWVyYXJj aGljYWwgcm91dGUgcmVmbGVjdGlvbiAoUlIpIGlzIHVzZWQsIHRoZTxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtleGlzdGluZyBSVC1Db25zdHJhaW4gbWVjaGFuaXNt IGNhbm5vdCBidWlsZCBhIGNvcnJlY3Qgcm91dGU8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ZGlzdHJpYnV0aW9uIGdyYXBoLiAmbmJzcDtUaGlzIGRvY3VtZW50IHJl ZmluZXMgdGhlIHJvdXRlIGRpc3RyaWJ1dGlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDtydWxlcyBvZiBSVC1Db25zdHJhaW4gdG8gYWRkcmVzcyB0aGUgaGllcmFy Y2hpY2FsIFJSIHNjZW5hcmlvcy48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsg Jmd0OyBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQ8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgVGhlIElFVEYgU2VjcmV0YXJp YXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsg Jmd0OyZndDsgSWRyIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVm PSJtYWlsdG86SWRyQGlldGYub3JnIj5JZHJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZn dDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZHI8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7 IElkciBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86SWRy QGlldGYub3JnIj5JZHJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcjwvYT48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkciBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWRyQGlldGYub3JnIj5JZHJAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZHIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkcjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_76CD132C3ADEF848BD84D028D243C9273369E78Bnkgeml512mbxchi_-- From nobody Mon Jun 23 03:08:33 2014 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 E3A351B2A94 for ; Mon, 23 Jun 2014 03:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K30GhojF9jCN for ; Mon, 23 Jun 2014 03:08:25 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520E11B28FC for ; Mon, 23 Jun 2014 03:06:52 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h15so2755262igd.14 for ; Mon, 23 Jun 2014 03:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=o9V2/uq51MC+v63KDSExs2zEKcYtPZ0rU4QEVBwKfJA=; b=Xp+FtfJQjmwwdLMUTBPxwrVITyBQ/DeZ9YVy06yD1pwMVcDTE7Tsp2DzpdvafBuxN4 r66eDKq2DtlJ8bG5c0QxV1KfRPR3zU7kKT4+bja0f4Ljr2Ra7dfeHxvkncB8LBtbIcK+ 2aLWSlFlX+7ttlqpWPQZz52FUleOwTqcbEqtDqCfH80PVrfpufo20kGQzRwZN8bc4Dxv zUOubD7eGhvPwZOmwK6kDd7ljAE6Y8CEQheHC26Y7+Z75ZkCw+eRBFvaw5OkaEPhgErU E6OKOl6gHanxVhj4vx/an0fOZ4DFpc0qkWOhoAr6ZwhZFqmq+PpD3fFrYUEFHPbgpZxW YjKw== MIME-Version: 1.0 X-Received: by 10.50.98.100 with SMTP id eh4mr25833703igb.9.1403518011533; Mon, 23 Jun 2014 03:06:51 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 23 Jun 2014 03:06:51 -0700 (PDT) In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273369E78B@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273369E78B@nkgeml512-mbx.china.huawei.com> Date: Mon, 23 Jun 2014 12:06:51 +0200 X-Google-Sender-Auth: yguE8qesIRukD29cNBFG2w4CjJg Message-ID: From: Robert Raszuk To: "Dongjie (Jimmy)" Content-Type: multipart/alternative; boundary=047d7b2e15df83719c04fc7e00db Archived-At: http://mailarchive.ietf.org/arch/msg/idr/LKOEd-DOEhQngshuKSYcO_2RNmE Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 10:08:28 -0000 --047d7b2e15df83719c04fc7e00db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well I don't think this is overkill. Keep in mind that this is only localized to your RR1-RR2 and RR1-RR3 sessions ... R. On Mon, Jun 23, 2014 at 9:47 AM, Dongjie (Jimmy) wrote: > Hi Robert, > > > > Maybe add-paths option =E2=80=9Call=E2=80=9D is somewhat overkill for sol= ving this > scenario? :) > > > > Best regards, > > Jie > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Monday, June 23, 2014 2:08 PM > *To:* Dongjie (Jimmy) > *Cc:* Vitkovsk=C3=BD Adam; idr@ietf.org > > *Subject:* Re: [Idr] New Version Notification for > draft-dong-idr-rtc-hierarchical-rr-00.txt > > > > Hi Jie, > > > > > we still need to specify the rules of which RTC routes should be > advertised to > > > solve this problem. > > > > Not really, Just use add-paths option "all" and your scenarios will work > just fine ;) > > > > =E2=80=8BCheers, > R.=E2=80=8B > > > > > > =E2=80=8B> =E2=80=8B > > On Mon, Jun 23, 2014 at 4:59 AM, Dongjie (Jimmy) > wrote: > > Hi Adam, > > If RD is part of the RTC routes, this problem will not occur:) While as > analyzed in rfc 4684, this requires more RTC routes being exchanged and > kept in the local AS. > > I agree that add-path is a candidate solution to this problem, while when > enabling add-path on RTC AFI/SAFI, we still need to specify the rules of > which RTC routes should be advertised to solve this problem. Or we just > update the rules of RTC advertisement as the other RTC related new drafts= ? > > > Many thanks, > Jie > > > -----Original Message----- > > > From: Vitkovsk=C3=BD Adam [mailto:adam.vitkovsky@swan.sk] > > Sent: Sunday, June 22, 2014 3:20 AM > > To: Robert Raszuk > > Cc: Dongjie (Jimmy); idr@ietf.org > > > Subject: RE: [Idr] New Version Notification for > > draft-dong-idr-rtc-hierarchical-rr-00.txt > > > > Aah I see :) > > Well we could have that one solved if RD would be part of the RTC route= s > :) > > (though I understand one could use RTC for non VPN routes as well so...= ) > > Anyways so than as you mentioned add-path on the RTC AF seems as the be= st > > option then. > > > > adam > > > -----Original Message----- > > > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Rober= t > > > Raszuk > > > Sent: Saturday, June 21, 2014 7:52 PM > > > To: Vitkovsk=C3=BD Adam > > > Cc: Dongjie (Jimmy); idr@ietf.org > > > Subject: Re: [Idr] New Version Notification for > > > draft-dong-idr-rtc-hierarchical- rr-00.txt > > > > > > Hi Adam, > > > > > > Jie is describing RT routes not VPN routes. Your story does not apply > > > to RT routes as format of RT NLRI is well defined by RFC ;) > > > > > > Besides MPLS network or not has nothing to do with it .... > > > > > > Best, > > > R. > > > > > > On Sat, Jun 21, 2014 at 7:19 PM, Vitkovsk=C3=BD Adam > > > > > > wrote: > > > > Hi Jie, > > > > Well the correctly designed MPLS networks use unique per PE per VRF > > > > RDs > > > in form of RID:xxxxx. > > > > Unique per PE RDs makes all copies of the same VPN prefix received > > > > from > > > different PEs unique so RRs will select all as best path and > > > distribute them accordingly, which solves this and many other issues. > > > > > > > > In other words if someone tries to shoot himself in the foot I > > > > wouldn't > > > develop bulletproof boots for him. > > > > > > > > adam > > > >> -----Original Message----- > > > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie > > > >> (Jimmy) > > > >> Sent: Friday, June 20, 2014 4:55 AM > > > >> To: idr@ietf.org > > > >> Subject: [Idr] FW: New Version Notification for draft-dong-idr-rtc= - > > > >> hierarchical-rr-00.txt > > > >> > > > >> Hi all, > > > >> > > > >> This is a short draft to make RTC applicable in hierarchical RR > scenario. > > > >> > > > >> Comments are welcome. > > > >> > > > >> Best regards, > > > >> Jie > > > >> > > > >> > -----Original Message----- > > > >> > > > > >> > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > > > >> > has been successfully submitted by Jie Dong and posted to the > > > >> > IETF > > > >> repository. > > > >> > > > > >> > Name: draft-dong-idr-rtc-hierarchical-rr > > > >> > Revision: 00 > > > >> > Title: Extensions to RT-Constrain in Hierarchical > Route > > Reflection > > > >> > Scenarios > > > >> > Document date: 2014-06-19 > > > >> > Group: Individual Submission > > > >> > Pages: 5 > > > >> > URL: > > > > >> > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchi= c > > > >> > al > > > >> > -rr > > > >> > -00.txt > > > >> > Status: > > > >> > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical= - > > > >> > rr > > > > >> > / > > > >> > Htmlized: > > > >> > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 > > > >> > > > > >> > > > > >> > Abstract: > > > >> > The Route Target (RT) Constrain mechanism specified in RFC > 4684 is > > > >> > used to build a route distribution graph in order to restrict > the > > > >> > propagation of Virtual Private Network (VPN) routes. In > network > > > >> > scenarios where hierarchical route reflection (RR) is used, t= he > > > >> > existing RT-Constrain mechanism cannot build a correct route > > > >> > distribution graph. This document refines the route > distribution > > > >> > rules of RT-Constrain to address the hierarchical RR scenario= s. > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > Please note that it may take a couple of minutes from the time o= f > > > >> > submission until the htmlized version and diff are available at > > > tools.ietf.org. > > > >> > > > > >> > The IETF Secretariat > > > >> > > > >> _______________________________________________ > > > >> Idr mailing list > > > >> Idr@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/idr > > > > > > > > _______________________________________________ > > > > Idr mailing list > > > > Idr@ietf.org > > > > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > --047d7b2e15df83719c04fc7e00db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Well I don't thi= nk this is overkill. Keep in mind that this is only localized to your RR1-R= R2 and RR1-RR3 sessions ...

R.


On Mon, Jun 23, 2014 at 9:47 AM, Dongjie (Ji= mmy) <jie.dong@huawei.com> wrote:

Hi Robert,=

=C2= =A0

Maybe add-= paths option =E2=80=9Call=E2=80=9D is somewhat overkill for solving this sc= enario? :)

=C2= =A0

Best regar= ds,

Jie=

=C2= =A0

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Monday, June 23, 2014 2:08 PM
To: Dongjie (Jimmy)
Cc: Vitkovsk=C3=BD Adam; idr@ietf.org


Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-h= ierarchical-rr-00.txt

=C2=A0

Hi Jie,

=C2=A0

> we still need to specify the rules of = which RTC routes should be advertised to=C2=A0

> solve this problem.

=C2=A0

Not really, =C2=A0Just use add-paths option= "all" and your scenarios will work just fine ;)

=C2=A0

=E2=80=8BCheers,
R.=E2=80=8B

=C2=A0

=C2=A0

=E2=80=8B> =E2=80=8B

On Mon, Jun 23, 2014 at 4:59 AM= , Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Adam,

If RD is part of the RTC routes, this problem will not occur:) While as ana= lyzed in rfc 4684, this requires more RTC routes being exchanged and kept i= n the local AS.

I agree that add-path is a candidate solution to this problem, while when e= nabling add-path on RTC AFI/SAFI, we still need to specify the rules of whi= ch RTC routes should be advertised to solve this problem. Or we just update= the rules of RTC advertisement as the other RTC related new drafts?


Many thanks,
Jie

> -----Original Message-----

> From: Vitkovsk=C3=BD Adam = [mailto:adam.vi= tkovsky@swan.sk]
> Sent: Sunday, June 22, 2014 3:20 AM
> To: Robert Raszuk
> Cc: Dongjie (Jimmy); idr@ietf.org

> Subject: RE: [Idr] New Ver= sion Notification for
> draft-dong-idr-rtc-hierarchical-rr-00.txt
>
> Aah I see :)
> Well we could have that one solved if RD would be part of the RTC rout= es :)
> (though I understand one could use RTC for non VPN routes as well so..= .)
> Anyways so than as you mentioned add-path on the RTC AF seems as the b= est
> option then.
>
> adam
> > -----Original Message-----
> > From: rras= zuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert
> > Raszuk
> > Sent: Saturday, June 21, 2014 7:52 PM
> > To: Vitkovsk=C3=BD Adam
> > Cc: Dongjie (Jimmy); idr@ietf.org
> > Subject: Re: [Idr] New Version Notification for
> > draft-dong-idr-rtc-hierarchical- rr-00.txt
> >
> > Hi Adam,
> >
> > Jie is describing RT routes not VPN routes. Your story does not a= pply
> > to RT routes as format of RT NLRI is well defined by RFC ;)
> >
> > Besides MPLS network or not has nothing to do with it ....
> >
> > Best,
> > R.
> >
> > On Sat, Jun 21, 2014 at 7:19 PM, Vitkovsk=C3=BD Adam
> > <a= dam.vitkovsky@swan.sk>
> > wrote:
> > > Hi Jie,
> > > Well the correctly designed MPLS networks use unique per PE = per VRF
> > > RDs
> > in form of RID:xxxxx.
> > > Unique per PE RDs makes all copies of the same VPN prefix re= ceived
> > > from
> > different PEs unique so RRs will select all as best path and
> > distribute them accordingly, which solves this and many other iss= ues.
> > >
> > > In other words if someone tries to shoot himself in the foot= I
> > > wouldn't
> > develop bulletproof boots for him.
> > >
> > > adam
> > >> -----Original Message-----
> > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie
> > >> (Jimmy)
> > >> Sent: Friday, June 20, 2014 4:55 AM
> > >> To: id= r@ietf.org
> > >> Subject: [Idr] FW: New Version Notification for draft-do= ng-idr-rtc-
> > >> hierarchical-rr-00.txt
> > >>
> > >> Hi all,
> > >>
> > >> This is a short draft to make RTC applicable in hierarch= ical RR scenario.
> > >>
> > >> Comments are welcome.
> > >>
> > >> Best regards,
> > >> Jie
> > >>
> > >> > -----Original Message-----
> > >> >
> > >> > A new version of I-D, draft-dong-idr-rtc-hierarchic= al-rr-00.txt
> > >> > has been successfully submitted by Jie Dong and pos= ted to the
> > >> > IETF
> > >> repository.
> > >> >
> > >> > Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 draft-dong-idr-rtc-hierarchical-rr
> > >> > Revision: =C2=A0 00
> > >> > Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Extensions to RT-Constrain in Hierarchical Route
> Reflection
> > >> > Scenarios
> > >> > Document date: =C2=A0 =C2=A0 =C2=A02014-06-19
> > >> > Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Individual Submission
> > >> > Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A05
> > >> > URL:

> > >> > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchic
> > >> > al
> > >> > -rr
> > >> > -00.txt
> > >> > Status:
> > >> > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-
> > >> > rr

> > >> > /
> > >> > Htmlized:
> > >> > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00
> > >> >
> > >> >
> > >> > Abstract:
> > >> > =C2=A0 =C2=A0The Route Target (RT) Constrain mechan= ism specified in RFC 4684 is
> > >> > =C2=A0 =C2=A0used to build a route distribution gra= ph in order to restrict the
> > >> > =C2=A0 =C2=A0propagation of Virtual Private Network= (VPN) routes. =C2=A0In network
> > >> > =C2=A0 =C2=A0scenarios where hierarchical route ref= lection (RR) is used, the
> > >> > =C2=A0 =C2=A0existing RT-Constrain mechanism cannot= build a correct route
> > >> > =C2=A0 =C2=A0distribution graph. =C2=A0This documen= t refines the route distribution
> > >> > =C2=A0 =C2=A0rules of RT-Constrain to address the h= ierarchical RR scenarios.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > Please note that it may take a couple of minutes fr= om the time of
> > >> > submission until the htmlized version and diff are = available at
> > tools.ietf.or= g.
> > >> >
> > >> > The IETF Secretariat
> > >>
> > >> _______________________________________________
> > >> Idr mailing list
> > >> Idr@ie= tf.org
> > >> https://www.ietf.org/mailman/listinfo/idr
> > >
> > > _______________________________________________
> > > Idr mailing list
> > > Idr@ietf.o= rg
> > > https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

=C2=A0


--047d7b2e15df83719c04fc7e00db-- From nobody Mon Jun 23 04:25:01 2014 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 A847D1B28EF for ; Mon, 23 Jun 2014 04:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 M-DmddesHOtK for ; Mon, 23 Jun 2014 04:24:56 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193CD1A0396 for ; Mon, 23 Jun 2014 04:24:56 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 88e08a35.2b13c786b940.2256673.00-2443.6287540.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 23 Jun 2014 11:24:56 +0000 (UTC) X-MXL-Hash: 53a80e8813607149-b4667d61ceb9c47472cc12b85ba9ac8240e0bc7e Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 18e08a35.0.2256647.00-2164.6287477.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 23 Jun 2014 11:24:51 +0000 (UTC) X-MXL-Hash: 53a80e830274474f-b23ef92da1e037100681ed9d537fbd09138f1726 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5NBOmh5025217; Mon, 23 Jun 2014 07:24:48 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5NBOaT5025088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 07:24:41 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 23 Jun 2014 11:24:16 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.4]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.03.0174.001; Mon, 23 Jun 2014 07:24:16 -0400 From: "UTTARO, JAMES" To: "'Dongjie (Jimmy)'" , "'idr@ietf.org'" Thread-Topic: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAEPJ1CAA6L2EIAAkJHA Date: Mon, 23 Jun 2014 11:24:15 +0000 Message-ID: References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273369B6A5@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273369B6A5@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.29.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=LbmLHEji c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=BbnZtKN_HuwA:10 a=ofMgfj31e3cA:10 a=jCseFCKhyQgA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=wU694w7oiLkxcuM] X-AnalysisOut: [3aCIA:9 a=CjuIK1q_8ugA:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=sOrNxPZTiQSEd-3b:21 a=5SmKLnrEmdYd] X-AnalysisOut: [qGgJ:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ZZjT0KKhsBLMNoIGomaaC9AjKtw Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 11:24:58 -0000 Jie, I still do not understand the architecture of hierarcacal RRs for the VPNV= 4 AF. As evidenced by your diagram and associated text probably not a good = idea. Regardless of that here are my thoughts, concerns and the where RT-C= may have utility. RT-C Premise.. The reason articulated in the original RT-C draft was based on the notion t= hat VPNs would be highly localized in nature and where there associated rou= ting state could also be contained in a sub-graph of the topology. My exper= ience is that this is not the case. The major advertisers of routing state = are big organizations that have footprint spanning multiple continents acro= ss the globe.=20 A benefit of RT-C may be to limit the amount of routing state sent to a PE = when a soft refresh, VRF add or re-boot occurs. The savings here is CPU cyc= les, ease of HOL blocking for those implementations that do not discriminat= e between routes incrementally added and a new VRF and reducing reboot time= . For these limited benefits full blown RT-C is not something I would deploy = as I risk fate sharing, disconnected VPNs ( Based on Topology ), etc... For= all of the business needs competing for cycles/windows it is difficult to = understand the cost/benefit.. SDN Control RT-C like filter deployed from an SDN controller may be the way to go. As = the RR/Route Server topology can easily scale to millions of routes we can = focus our energy on reducing the flood of routing state to an individual PE= , between providers or even between RRs although the last one holds little = interest for me. Jim Uttaro -----Original Message----- From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com]=20 Sent: Sunday, June 22, 2014 10:42 PM To: UTTARO, JAMES; 'idr@ietf.org' Subject: RE: New Version Notification for draft-dong-idr-rtc-hierarchical-r= r-00.txt Hi Jim, Here is the example I previously sent to the list:=20 PE1---RR2 \ \ =20 PE2- RR1 \ / \ / RR3 / / PE3- RR1 is level-1 RR, and RR2 and RR3 are level-2 RRs. 1. All the PEs advertise RTC route of RT-X to their connecting RRs. 2. RR2 and RR3 select the best RTC route, add their cluster_id to the clust= er_list and advertise the RTC route to RR1 respectively.=20 3. RR1 selects one RTC route as best (let's say RTC route from RR2), adds i= ts cluster_id into the cluster_list and advertises it to RR2 and RR3.=20 4. Then RR2 would receive the RTC route from RR1 with its own cluster_id in= the cluster_list and will drop this RTC route. 5. As a result, RR2 will not advertise VPN routes with RT-X to RR1. For a network with hierarchical RR, RTC can also be useful to control the V= PN routes being distributed only to PEs which have the corresponding custom= ers connected. I'm not quite clear about your comments about RTC and SDN controller, do yo= u mean RTC mechanism can be used to distribute routes to SDN controller? I'= d agree that is another possible use case of RTC. Best regards, Jie > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Saturday, June 21, 2014 3:02 AM > To: Dongjie (Jimmy); 'idr@ietf.org' > Subject: RE: New Version Notification for > draft-dong-idr-rtc-hierarchical-rr-00.txt >=20 > Why? A picture would be quite useful here. I am struggling to understand = a > hierarcacal design that then needs RT-C?? Maybe if the VPNs are highly > localized.. BTW isn't RT-C a good candidate to off net to an SDN controll= er? > IMO that should be the future. >=20 > Jim Uttaro >=20 > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) > Sent: Thursday, June 19, 2014 10:55 PM > To: idr@ietf.org > Subject: [Idr] FW: New Version Notification for > draft-dong-idr-rtc-hierarchical-rr-00.txt >=20 > Hi all, >=20 > This is a short draft to make RTC applicable in hierarchical RR scenario. >=20 > Comments are welcome. >=20 > Best regards, > Jie >=20 > > -----Original Message----- > > > > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > > has been successfully submitted by Jie Dong and posted to the IETF repo= sitory. > > > > Name: draft-dong-idr-rtc-hierarchical-rr > > Revision: 00 > > Title: Extensions to RT-Constrain in Hierarchical Route Reflection > > Scenarios > > Document date: 2014-06-19 > > Group: Individual Submission > > Pages: 5 > > URL: > > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical-rr > > -00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ > > Htmlized: > > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 > > > > > > Abstract: > > The Route Target (RT) Constrain mechanism specified in RFC 4684 is > > used to build a route distribution graph in order to restrict the > > propagation of Virtual Private Network (VPN) routes. In network > > scenarios where hierarchical route reflection (RR) is used, the > > existing RT-Constrain mechanism cannot build a correct route > > distribution graph. This document refines the route distribution > > rules of RT-Constrain to address the hierarchical RR scenarios. > > > > > > > > > > > > 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.i= etf.org. > > > > The IETF Secretariat >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jun 23 07:15:04 2014 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 80DFE1B2AF5 for ; Mon, 23 Jun 2014 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3Bat9Mpx-DY for ; Mon, 23 Jun 2014 07:15:00 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9727C1B295C for ; Mon, 23 Jun 2014 07:14:59 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: "UTTARO, JAMES" , "'Dongjie (Jimmy)'" , "'idr@ietf.org'" Thread-Topic: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAEPJ1CAA6L2EIAAkJHAgAAtGcA= Date: Mon, 23 Jun 2014 14:14:53 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B019C816D@EX01.swan.local> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273369B6A5@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.40.93] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/qATJalCkGnkiGVQuQ23_gUfo0_o Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:15:02 -0000 James, Think of the filters between inter-as-RRs and PEs for example used to limit= the exposure of MNCs prefixes versus the local corporations prefixes to ot= her regions. These could be replaced by the RT-C not requiring "manual" mai= ntenance.=20 But I agree that the risk of discontinuous VPNs based on some arbitrary top= ology between RRs is an unacceptable burden for full blown RT-C deployment,= though my understanding is that this could only happen in hierarchical RR = topologies. However I see no need to alleviate the number of iBGP sessions between intr= a-as-RRs with yet another level of hierarchy.=20 adam > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of UTTARO, JAMES > Sent: Monday, June 23, 2014 1:24 PM > To: 'Dongjie (Jimmy)'; 'idr@ietf.org' > Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierar= chical- > rr-00.txt >=20 > Jie, >=20 > I still do not understand the architecture of hierarcacal RRs for the > VPNV4 AF. As evidenced by your diagram and associated text probably not a > good idea. Regardless of that here are my thoughts, concerns and the whe= re > RT-C may have utility. >=20 > RT-C Premise.. >=20 > The reason articulated in the original RT-C draft was based on the notion= that > VPNs would be highly localized in nature and where there associated routi= ng > state could also be contained in a sub-graph of the topology. My experien= ce > is that this is not the case. The major advertisers of routing state are = big > organizations that have footprint spanning multiple continents across the > globe. >=20 > A benefit of RT-C may be to limit the amount of routing state sent to a P= E > when a soft refresh, VRF add or re-boot occurs. The savings here is CPU > cycles, ease of HOL blocking for those implementations that do not > discriminate between routes incrementally added and a new VRF and > reducing reboot time. >=20 > For these limited benefits full blown RT-C is not something I would deplo= y as > I risk fate sharing, disconnected VPNs ( Based on Topology ), etc... For = all of > the business needs competing for cycles/windows it is difficult to unders= tand > the cost/benefit.. >=20 > SDN Control >=20 > RT-C like filter deployed from an SDN controller may be the way to go. A= s the > RR/Route Server topology can easily scale to millions of routes we can fo= cus > our energy on reducing the flood of routing state to an individual PE, > between providers or even between RRs although the last one holds little > interest for me. >=20 > Jim Uttaro >=20 > -----Original Message----- > From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com] > Sent: Sunday, June 22, 2014 10:42 PM > To: UTTARO, JAMES; 'idr@ietf.org' > Subject: RE: New Version Notification for draft-dong-idr-rtc-hierarchical= -rr- > 00.txt >=20 > Hi Jim, >=20 > Here is the example I previously sent to the list: >=20 > PE1---RR2 > \ > \ > PE2- RR1 > \ / > \ / > RR3 > / > / > PE3- >=20 > RR1 is level-1 RR, and RR2 and RR3 are level-2 RRs. >=20 > 1. All the PEs advertise RTC route of RT-X to their connecting RRs. > 2. RR2 and RR3 select the best RTC route, add their cluster_id to the > cluster_list and advertise the RTC route to RR1 respectively. > 3. RR1 selects one RTC route as best (let's say RTC route from RR2), adds= its > cluster_id into the cluster_list and advertises it to RR2 and RR3. > 4. Then RR2 would receive the RTC route from RR1 with its own cluster_id = in > the cluster_list and will drop this RTC route. > 5. As a result, RR2 will not advertise VPN routes with RT-X to RR1. >=20 > For a network with hierarchical RR, RTC can also be useful to control the= VPN > routes being distributed only to PEs which have the corresponding custome= rs > connected. >=20 > I'm not quite clear about your comments about RTC and SDN controller, do > you mean RTC mechanism can be used to distribute routes to SDN > controller? I'd agree that is another possible use case of RTC. >=20 > Best regards, > Jie >=20 > > -----Original Message----- > > From: UTTARO, JAMES [mailto:ju1738@att.com] > > Sent: Saturday, June 21, 2014 3:02 AM > > To: Dongjie (Jimmy); 'idr@ietf.org' > > Subject: RE: New Version Notification for > > draft-dong-idr-rtc-hierarchical-rr-00.txt > > > > Why? A picture would be quite useful here. I am struggling to > > understand a hierarcacal design that then needs RT-C?? Maybe if the > > VPNs are highly localized.. BTW isn't RT-C a good candidate to off net = to an > SDN controller? > > IMO that should be the future. > > > > Jim Uttaro > > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) > > Sent: Thursday, June 19, 2014 10:55 PM > > To: idr@ietf.org > > Subject: [Idr] FW: New Version Notification for > > draft-dong-idr-rtc-hierarchical-rr-00.txt > > > > Hi all, > > > > This is a short draft to make RTC applicable in hierarchical RR scenari= o. > > > > Comments are welcome. > > > > Best regards, > > Jie > > > > > -----Original Message----- > > > > > > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > > > has been successfully submitted by Jie Dong and posted to the IETF > repository. > > > > > > Name: draft-dong-idr-rtc-hierarchical-rr > > > Revision: 00 > > > Title: Extensions to RT-Constrain in Hierarchical Route > Reflection > > > Scenarios > > > Document date: 2014-06-19 > > > Group: Individual Submission > > > Pages: 5 > > > URL: > > > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical- > > > rr > > > -00.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ > > > Htmlized: > > > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 > > > > > > > > > Abstract: > > > The Route Target (RT) Constrain mechanism specified in RFC 4684 is > > > used to build a route distribution graph in order to restrict the > > > propagation of Virtual Private Network (VPN) routes. In network > > > scenarios where hierarchical route reflection (RR) is used, the > > > existing RT-Constrain mechanism cannot build a correct route > > > distribution graph. This document refines the route distribution > > > rules of RT-Constrain to address the hierarchical RR scenarios. > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > The IETF Secretariat > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jun 23 11:25:21 2014 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 E54AE1B28C7 for ; Mon, 23 Jun 2014 11:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 FqRuVT-agROK for ; Mon, 23 Jun 2014 11:25:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 38D151B2B3C for ; Mon, 23 Jun 2014 11:24:58 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BFEDBC22C; Mon, 23 Jun 2014 14:24:57 -0400 (EDT) Date: Mon, 23 Jun 2014 14:24:57 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140623182457.GO11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15043_1403268251_53A42C9B_15043_2147_1_9E32478DFA9976438E7A22F69B08FF92022DEA@OPEXCLILM34.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/XgfKwKM4hQnAWdyPNgxwdIo9nmE Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 18:25:17 -0000 On Fri, Jun 20, 2014 at 02:57:28PM +0200, Robert Raszuk wrote: > I am not worried about efficiency here. I am. :-) I've been quiet on the thread partially because I don't have any better observations on the nature of the fix to contribute. But I do have an observation about the shape of the solution. Solutions that rely on meddling with the existing route reflection semantics in the cluster list will have to deal with the fact that there can be significant "noise" in convergence events as part of a hierarchical RR environment. The sort of "ping pong" that happens is certainly one negative thing that discourages such deployments. Where this is particularly messy for VPN environments is that if the full set of VPN routes is prevented from being flooded across RRs in the hierarchy with whatever solution we come up with, then a RT-C reconvergence event could result in a massive thrashing of routes among the reflectors. Except in very strict hierarchies, RT-C is probably not beneficial to VPN route distribution. -- Jeff From nobody Mon Jun 23 11:26:30 2014 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 B07931B2BF6 for ; Mon, 23 Jun 2014 11:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 djmINahcPm-8 for ; Mon, 23 Jun 2014 11:26:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DA4281B2BF0 for ; Mon, 23 Jun 2014 11:26:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id ADFDDC22C; Mon, 23 Jun 2014 14:26:19 -0400 (EDT) Date: Mon, 23 Jun 2014 14:26:19 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140623182619.GP11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/wSkMzv3ZYWHIx9RtX92uTSQzMR8 Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 18:26:26 -0000 On Mon, Jun 23, 2014 at 08:08:00AM +0200, Robert Raszuk wrote: > Hi Jie, > > > we still need to specify the rules of which RTC routes should be > advertised to > > solve this problem. > > Not really, Just use add-paths option "all" and your scenarios will work > just fine ;) Add-paths are local between pairs of routers. We'd really need distinct RD-type identifiers to cover the problem. -- Jeff From nobody Mon Jun 23 12:00:16 2014 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 898AF1B2C42 for ; Mon, 23 Jun 2014 12:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVFeUzEJg8iY for ; Mon, 23 Jun 2014 12:00:10 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7477A1B2C07 for ; Mon, 23 Jun 2014 11:56:40 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id l13so3414593iga.7 for ; Mon, 23 Jun 2014 11:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rQ5QJOgaCncp+94jmQNzKsOpyBv9xTmW2/s9HhwHg2U=; b=CJMobgoYdrgaPe9BLwsljDbXhQCcnTAyDwyYvHecBMhNJ8G8egI5/gb/DJ4WYNhPl1 ZBgsDAeMUKe60IcqvdZYTfEUKy9t2o5FajJSvh8hE5MGryLe/w1POoBb8dQp4IZSyhfo /aoHF7HI7hXRo2Gb2FndpJmBcpm52fsQ/4cbMk45NhyPo1emgtaUChkOSjxiE0Nd4Bah 4BDs5V0jm6XtRfVJfOZWbJqweytxSNw14qZODMRvQAxu1kUPgft5SplcUY4x7d6Tzv3E R5JINo12kkRV9A9VJs362pscvdiYhqkC/nvtrMTpgOgNjAKNdw/mSZOTlWA6WcytYyXL Kuhw== MIME-Version: 1.0 X-Received: by 10.43.160.137 with SMTP id mc9mr24471500icc.4.1403549799856; Mon, 23 Jun 2014 11:56:39 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 23 Jun 2014 11:56:39 -0700 (PDT) In-Reply-To: <20140623182619.GP11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <20140623182619.GP11842@pfrc> Date: Mon, 23 Jun 2014 20:56:39 +0200 X-Google-Sender-Auth: _LAWAYBVJSsGfwO6Xb9Gp7QLBZg Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c326283ec1de04fc856713 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/iDq0giBRd50UU8hOGYkUQpbyTK8 Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:00:11 -0000 --001a11c326283ec1de04fc856713 Content-Type: text/plain; charset=UTF-8 Hi Jeff, I don't think so. Notice that the issue is not that we are suppressing presence of RTC routes due to selection of some other paths. That is the only case which unique RD for RTC NLRI could help with. The issue here is with filtered distribution vector betwen top hierarchy and lower layer for one RR peer which happen to be the src of the best path of such RTC NLRI. Also while digesting the problem keep in mind that operation of RTC is session oriented and results in suppression of real VPN route distribution to top level RR via such node. In fact while thinking about your mail I think there is even simpler alternative to use of add-paths as the solution ... Just use at least three lower layer RRs - that way top hierarchy will always have at least two VPN paths and that should be sufficient :) Operationally that would be additional IBGP session from each PE. Best, R. On Mon, Jun 23, 2014 at 8:26 PM, Jeffrey Haas wrote: > On Mon, Jun 23, 2014 at 08:08:00AM +0200, Robert Raszuk wrote: > > Hi Jie, > > > > > we still need to specify the rules of which RTC routes should be > > advertised to > > > solve this problem. > > > > Not really, Just use add-paths option "all" and your scenarios will work > > just fine ;) > > Add-paths are local between pairs of routers. We'd really need distinct > RD-type identifiers to cover the problem. > > -- Jeff > --001a11c326283ec1de04fc856713 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jeff,

I don't think so.=C2=A0

Noti= ce that the issue is not that we are suppressing presence of RTC routes due= to selection of some other paths. That is the only case which unique RD fo= r RTC NLRI could help with.=C2=A0

The issue here is with filtered distr= ibution vector betwen top hierarchy and lower layer for one RR peer which h= appen to be the src of the best path of such RTC NLRI.

Also while digesting the problem keep= in mind that operation of RTC is session oriented and results in suppressi= on of real VPN route distribution to top level RR via such node.

In fact while thinking about your mai= l I think there is even simpler alternative to use of add-paths as the solu= tion ... Just use at least three lower layer RRs - that way top hierarchy w= ill always have at least two VPN paths and that should be sufficient :) Ope= rationally that would be additional IBGP session from each PE.

Best,
R.



On Mon, Jun 23, 2014 at 8:26 PM, Jeffrey Haas <jhaas= @pfrc.org> wrote:
On Mon, Jun 23, 2014 at 08:0= 8:00AM +0200, Robert Raszuk wrote:
> Hi Jie,
>
> > we still need to specify the rules of which RTC routes should be<= br> > advertised to
> > solve this problem.
>
> Not really, =C2=A0Just use add-paths option "all" and your s= cenarios will work
> just fine ;)

Add-paths are local between pairs of routers. =C2=A0We'd really n= eed distinct
RD-type identifiers to cover the problem.

-- Jeff

--001a11c326283ec1de04fc856713-- From nobody Mon Jun 23 12:07:24 2014 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 2B3421B2C5A for ; Mon, 23 Jun 2014 12:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.819 X-Spam-Level: X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 ZGe4wg57WWfQ for ; Mon, 23 Jun 2014 12:07:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 26C1B1B2CE2 for ; Mon, 23 Jun 2014 12:04:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CFD79C22C; Mon, 23 Jun 2014 15:04:20 -0400 (EDT) Date: Mon, 23 Jun 2014 15:04:20 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140623190420.GT11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <20140623182619.GP11842@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/2L7omPa0rPyJ_ys0Iy6cX5cg0ug Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:07:23 -0000 [reformatting to avoid the top-post] On Mon, Jun 23, 2014 at 08:56:39PM +0200, Robert Raszuk wrote: > > Add-paths are local between pairs of routers. We'd really need distinct > > RD-type identifiers to cover the problem. > > > > -- Jeff > I don't think so. > > Notice that the issue is not that we are suppressing presence of RTC routes > due to selection of some other paths. That is the only case which unique RD > for RTC NLRI could help with. The suppression is incidental to the problem: RT-C needs the route to bounce back from a RR-client when it's another RR. Cluster list is causing that filtering to happen. As I try to get a handle on possible solutions, one thought had been that the reflection was itself already that bounce-back. An implementation simply keeps the looped route (many discard such loops) and uses that for it's RT-C flooding state. However, the RR ping-pong due to inter-cluster/client changes may result in partial meshes of flooding forming among the various RRs with resultant thrashing of VPN routes. This is a Bad Thing. > The issue here is with filtered distribution vector betwen top hierarchy > and lower layer for one RR peer which happen to be the src of the best path > of such RTC NLRI. I agree with your observation from this perspective. I urge you to reframe this perspective to arbitrary meshes of reflectors, perhaps with multiple cluster members. That said, the simplest solution spaces will be easiest to see (I think) in the simple example Jie presented. > Also while digesting the problem keep in mind that operation of RTC is > session oriented and results in suppression of real VPN route distribution > to top level RR via such node. I'm always keeping this in mind. :-) -- Jeff From nobody Mon Jun 23 12:24:06 2014 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 CBD451B2C08 for ; Mon, 23 Jun 2014 12:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myA7x_x8PO0S for ; Mon, 23 Jun 2014 12:24:03 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372C11A02AA for ; Mon, 23 Jun 2014 12:24:03 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id x19so6182670ier.30 for ; Mon, 23 Jun 2014 12:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8erzHbGrZACLyOK1CbdNfJOnHeABp1ikx2EQRACepXQ=; b=q0rYKe8Q1jkvLBBVLtkymxu154TLLA5YtXQJ6g61kwNRB2v0YPyOCUaPZhXUsJltPL mIJJb0n8Y0royvO5zYUujZ+YbhQirq5HUO/YLOfkIcK1y02cOUgZzfWRLiQUnDgWJVJr 7IAgiV395S1tAdJutqXSq7olImdJDvG6KTvRy4twqiQweGy4s2PAioH/Q4CA5EOs8Rpc vipccB/za3rZYdYZU2i4PnTfIR7GyzStlK7dyKsHgdK/oRcZKJpqqLuKAHxHaS9xfUHW ENJPKBk5tK7gbveYTpo2T+mNwV/fTREIimGQCHUXx1MlHhqWJEE36yvbDBmA/nz7f890 rH3w== MIME-Version: 1.0 X-Received: by 10.50.36.106 with SMTP id p10mr29680353igj.9.1403551442669; Mon, 23 Jun 2014 12:24:02 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 23 Jun 2014 12:24:02 -0700 (PDT) In-Reply-To: <20140623190420.GT11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <20140623182619.GP11842@pfrc> <20140623190420.GT11842@pfrc> Date: Mon, 23 Jun 2014 21:24:02 +0200 X-Google-Sender-Auth: tmRhSzks9chyd8qAqnC7P3o81oI Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: multipart/alternative; boundary=089e0115ebd02a172704fc85c98e Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_S2ONEySDDlmxr71bP0bxGG63iE Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:24:05 -0000 --089e0115ebd02a172704fc85c98e Content-Type: text/plain; charset=UTF-8 Hi Jeff, Maybe I am missing something fundamental, but the lecture of your below note sort of shed a completely new light on this entire "issue". Let's step back for a second and ask ourselves why top level RR would not send default RT (send all) RTC NLRI to it's lower layer clients ? That way top level RR will learn all VPN routes and distribute them as seems fit to lower level RRs according to atomic RTC routes they will push to him. If so I would call this entire "issue" a misconfiguration and move on ;) best, r. On Mon, Jun 23, 2014 at 9:04 PM, Jeffrey Haas wrote: > [reformatting to avoid the top-post] > > On Mon, Jun 23, 2014 at 08:56:39PM +0200, Robert Raszuk wrote: > > > Add-paths are local between pairs of routers. We'd really need > distinct > > > RD-type identifiers to cover the problem. > > > > > > -- Jeff > > > I don't think so. > > > > Notice that the issue is not that we are suppressing presence of RTC > routes > > due to selection of some other paths. That is the only case which unique > RD > > for RTC NLRI could help with. > > The suppression is incidental to the problem: RT-C needs the route to > bounce > back from a RR-client when it's another RR. Cluster list is causing that > filtering to happen. > > As I try to get a handle on possible solutions, one thought had been that > the reflection was itself already that bounce-back. An implementation > simply keeps the looped route (many discard such loops) and uses that for > it's RT-C flooding state. > > However, the RR ping-pong due to inter-cluster/client changes may result in > partial meshes of flooding forming among the various RRs with resultant > thrashing of VPN routes. This is a Bad Thing. > > > The issue here is with filtered distribution vector betwen top hierarchy > > and lower layer for one RR peer which happen to be the src of the best > path > > of such RTC NLRI. > > I agree with your observation from this perspective. > > I urge you to reframe this perspective to arbitrary meshes of reflectors, > perhaps with multiple cluster members. > > That said, the simplest solution spaces will be easiest to see (I think) in > the simple example Jie presented. > > > Also while digesting the problem keep in mind that operation of RTC is > > session oriented and results in suppression of real VPN route > distribution > > to top level RR via such node. > > I'm always keeping this in mind. :-) > > -- Jeff > --089e0115ebd02a172704fc85c98e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jeff,

Maybe I am missing something fundamental, but the lecture of your below not= e sort of shed a completely new light on this entire "issue".=C2= =A0

Let's step back for a second and ask ourselves = why top level RR would not send default RT (send all) RTC NLRI to it's = lower layer clients ?=C2=A0

That way top level RR will learn all = VPN routes and distribute them as seems fit to lower level RRs according to= atomic RTC routes they will push to him.

If so I would call this entire "= issue" a misconfiguration and move on ;)

best,
r.


On Mon, Jun 23, 2014 at 9:04 PM, Jeffrey Haas <jhaas@pfrc.or= g> wrote:
[reformatting to avoid the top-post]

On Mon, Jun 23, 2014 at 08:56:39PM +0200, Robert Raszuk wrote:
> > Add-paths are local between pairs of routers. =C2=A0We'd real= ly need distinct
> > RD-type identifiers to cover the problem.
> >
> > -- Jeff

> I don't think so.
>
> Notice that the issue is not that we are suppressing presence of RTC r= outes
> due to selection of some other paths. That is the only case which uniq= ue RD
> for RTC NLRI could help with.

The suppression is incidental to the problem: RT-C needs the route to= bounce
back from a RR-client when it's another RR. =C2=A0Cluster list is causi= ng that
filtering to happen.

As I try to get a handle on possible solutions, one thought had been that the reflection was itself already that bounce-back. =C2=A0An implementation=
simply keeps the looped route (many discard such loops) and uses that for it's RT-C flooding state.

However, the RR ping-pong due to inter-cluster/client changes may result in=
partial meshes of flooding forming among the various RRs with resultant
thrashing of VPN routes. =C2=A0This is a Bad Thing.

> The issue here is with filtered distribution vector betwen top hierarc= hy
> and lower layer for one RR peer which happen to be the src of the best= path
> of such RTC NLRI.

I agree with your observation from this perspective.

I urge you to reframe this perspective to arbitrary meshes of reflectors, perhaps with multiple cluster members.

That said, the simplest solution spaces will be easiest to see (I think) in=
the simple example Jie presented.

> Also while digesting the problem keep in mind that operation of RTC is=
> session oriented and results in suppression of real VPN route distribu= tion
> to top level RR via such node.

I'm always keeping this in mind. :-)

-- Jeff

--089e0115ebd02a172704fc85c98e-- From nobody Mon Jun 23 15:41:57 2014 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 E97B01A03A4 for ; Mon, 23 Jun 2014 15:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 xxn4afOlCZZl for ; Mon, 23 Jun 2014 15:41:51 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE5D1A030C for ; Mon, 23 Jun 2014 15:41:51 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id f2da8a35.2ba85604f940.7981726.00-2494.20420683.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 23 Jun 2014 22:41:51 +0000 (UTC) X-MXL-Hash: 53a8ad2f6e5fa9eb-3be64521fd776835d6a755fdf16ada49913ea79c Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id a2da8a35.0.7981699.00-2285.20420599.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 23 Jun 2014 22:41:49 +0000 (UTC) X-MXL-Hash: 53a8ad2d7aebea70-d5158cd92feb7478a2089613d63df811986ec191 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5NMfk5E027646; Mon, 23 Jun 2014 18:41:46 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5NMfgJu027620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 18:41:43 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 23 Jun 2014 22:41:25 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.4]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0174.001; Mon, 23 Jun 2014 18:41:25 -0400 From: "UTTARO, JAMES" To: =?iso-8859-1?Q?=27Vitkovsk=FD_Adam=27?= , "'Dongjie (Jimmy)'" , "'idr@ietf.org'" Thread-Topic: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAEPJ1CAA6L2EIAAkJHAgAAtGcCAAJN+4A== Date: Mon, 23 Jun 2014 22:41:24 +0000 Message-ID: References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273369B6A5@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C816D@EX01.swan.local> In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B019C816D@EX01.swan.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.29.94] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Ro1y2laK c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=BbnZtKN_HuwA:10 a=ofMgfj31e3cA:10 a=jCseFCKhyQgA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=kv4WD4DG-wDGusb] X-AnalysisOut: [CG_gA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=hPjdaMEvmhQA] X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=Qk1jRifqmIA63Aqs:21 a=U37Q1SW_n97z] X-AnalysisOut: [jvtR:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ogCFdBBuxtS8dmXNWR_iRKfm02A Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:41:55 -0000 Adam, I am uncomfortable turning over route distribution to a protocol. IMO the = risk for a L3VPN network with sites that are geographically spread does not= warrant the gain. I would suggest the working group tee this up with the I= RS2 team as a use case. Jim Uttaro -----Original Message----- From: Vitkovsk=FD Adam [mailto:adam.vitkovsky@swan.sk]=20 Sent: Monday, June 23, 2014 10:15 AM To: UTTARO, JAMES; 'Dongjie (Jimmy)'; 'idr@ietf.org' Subject: RE: New Version Notification for draft-dong-idr-rtc-hierarchical-r= r-00.txt James, Think of the filters between inter-as-RRs and PEs for example used to limit= the exposure of MNCs prefixes versus the local corporations prefixes to ot= her regions. These could be replaced by the RT-C not requiring "manual" mai= ntenance.=20 But I agree that the risk of discontinuous VPNs based on some arbitrary top= ology between RRs is an unacceptable burden for full blown RT-C deployment,= though my understanding is that this could only happen in hierarchical RR = topologies. However I see no need to alleviate the number of iBGP sessions between intr= a-as-RRs with yet another level of hierarchy.=20 adam > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of UTTARO, JAMES > Sent: Monday, June 23, 2014 1:24 PM > To: 'Dongjie (Jimmy)'; 'idr@ietf.org' > Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierar= chical- > rr-00.txt >=20 > Jie, >=20 > I still do not understand the architecture of hierarcacal RRs for the > VPNV4 AF. As evidenced by your diagram and associated text probably not a > good idea. Regardless of that here are my thoughts, concerns and the whe= re > RT-C may have utility. >=20 > RT-C Premise.. >=20 > The reason articulated in the original RT-C draft was based on the notion= that > VPNs would be highly localized in nature and where there associated routi= ng > state could also be contained in a sub-graph of the topology. My experien= ce > is that this is not the case. The major advertisers of routing state are = big > organizations that have footprint spanning multiple continents across the > globe. >=20 > A benefit of RT-C may be to limit the amount of routing state sent to a P= E > when a soft refresh, VRF add or re-boot occurs. The savings here is CPU > cycles, ease of HOL blocking for those implementations that do not > discriminate between routes incrementally added and a new VRF and > reducing reboot time. >=20 > For these limited benefits full blown RT-C is not something I would deplo= y as > I risk fate sharing, disconnected VPNs ( Based on Topology ), etc... For = all of > the business needs competing for cycles/windows it is difficult to unders= tand > the cost/benefit.. >=20 > SDN Control >=20 > RT-C like filter deployed from an SDN controller may be the way to go. A= s the > RR/Route Server topology can easily scale to millions of routes we can fo= cus > our energy on reducing the flood of routing state to an individual PE, > between providers or even between RRs although the last one holds little > interest for me. >=20 > Jim Uttaro >=20 > -----Original Message----- > From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com] > Sent: Sunday, June 22, 2014 10:42 PM > To: UTTARO, JAMES; 'idr@ietf.org' > Subject: RE: New Version Notification for draft-dong-idr-rtc-hierarchical= -rr- > 00.txt >=20 > Hi Jim, >=20 > Here is the example I previously sent to the list: >=20 > PE1---RR2 > \ > \ > PE2- RR1 > \ / > \ / > RR3 > / > / > PE3- >=20 > RR1 is level-1 RR, and RR2 and RR3 are level-2 RRs. >=20 > 1. All the PEs advertise RTC route of RT-X to their connecting RRs. > 2. RR2 and RR3 select the best RTC route, add their cluster_id to the > cluster_list and advertise the RTC route to RR1 respectively. > 3. RR1 selects one RTC route as best (let's say RTC route from RR2), adds= its > cluster_id into the cluster_list and advertises it to RR2 and RR3. > 4. Then RR2 would receive the RTC route from RR1 with its own cluster_id = in > the cluster_list and will drop this RTC route. > 5. As a result, RR2 will not advertise VPN routes with RT-X to RR1. >=20 > For a network with hierarchical RR, RTC can also be useful to control the= VPN > routes being distributed only to PEs which have the corresponding custome= rs > connected. >=20 > I'm not quite clear about your comments about RTC and SDN controller, do > you mean RTC mechanism can be used to distribute routes to SDN > controller? I'd agree that is another possible use case of RTC. >=20 > Best regards, > Jie >=20 > > -----Original Message----- > > From: UTTARO, JAMES [mailto:ju1738@att.com] > > Sent: Saturday, June 21, 2014 3:02 AM > > To: Dongjie (Jimmy); 'idr@ietf.org' > > Subject: RE: New Version Notification for > > draft-dong-idr-rtc-hierarchical-rr-00.txt > > > > Why? A picture would be quite useful here. I am struggling to > > understand a hierarcacal design that then needs RT-C?? Maybe if the > > VPNs are highly localized.. BTW isn't RT-C a good candidate to off net = to an > SDN controller? > > IMO that should be the future. > > > > Jim Uttaro > > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) > > Sent: Thursday, June 19, 2014 10:55 PM > > To: idr@ietf.org > > Subject: [Idr] FW: New Version Notification for > > draft-dong-idr-rtc-hierarchical-rr-00.txt > > > > Hi all, > > > > This is a short draft to make RTC applicable in hierarchical RR scenari= o. > > > > Comments are welcome. > > > > Best regards, > > Jie > > > > > -----Original Message----- > > > > > > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > > > has been successfully submitted by Jie Dong and posted to the IETF > repository. > > > > > > Name: draft-dong-idr-rtc-hierarchical-rr > > > Revision: 00 > > > Title: Extensions to RT-Constrain in Hierarchical Route > Reflection > > > Scenarios > > > Document date: 2014-06-19 > > > Group: Individual Submission > > > Pages: 5 > > > URL: > > > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical- > > > rr > > > -00.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ > > > Htmlized: > > > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 > > > > > > > > > Abstract: > > > The Route Target (RT) Constrain mechanism specified in RFC 4684 is > > > used to build a route distribution graph in order to restrict the > > > propagation of Virtual Private Network (VPN) routes. In network > > > scenarios where hierarchical route reflection (RR) is used, the > > > existing RT-Constrain mechanism cannot build a correct route > > > distribution graph. This document refines the route distribution > > > rules of RT-Constrain to address the hierarchical RR scenarios. > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > The IETF Secretariat > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jun 23 18:34:09 2014 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 D8E611B2797 for ; Mon, 23 Jun 2014 18:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 egFa-5ffpMWV for ; Mon, 23 Jun 2014 18:34:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792701B27AB for ; Mon, 23 Jun 2014 18:33:59 -0700 (PDT) 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 BJC74848; Tue, 24 Jun 2014 01:33:58 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 02:33:57 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 09:33:54 +0800 From: Xuxiaohu To: Robert Raszuk , Jeffrey Haas Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//4fPgIAAGG8AgAKT/sD//7OAAIAAzkiAgAAIeoCAAAIlAIAABYEAgADnqBA= Date: Tue, 24 Jun 2014 01:33:54 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C645@NKGEML512-MBS.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <20140623182619.GP11842@pfrc> <20140623190420.GT11842@pfrc> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C645NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/xsi2HTGqIk5mu_k7dr048W1j4fU Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 01:34:07 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C645NKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHNpZGVlZmZlY3Qgb2Ygc2VuZGluZyBkZWZhdWx0IFJUICBieSB0aGUgdG9wLWxldmVsIFJS IGlzIHRoYXQgc29tZSBWUE4gcm91dGVzIHdvdWxkIGJlIHVubmVjZXNzYXJpbHkgc2VudCB0byB0 aGF0IHRvcC1sZXZlbCBSUi4gSG93IGFib3V0IGFkZGluZyBSRCB0byB0aGUgUlQgbWVtYmVyc2hp cCBOTFJJIChpLmUuLCB0aGUgUlQgbWVtYmVyc2hpcCBOTFJJcyBvcmlnaW5hdGVkIGZyb20gZGlm ZmVyZW50IFBFcyBhcmUgZGlzdGluZ3Vpc2hhYmxlKSB3aGlsZSBvbiBhIHNlc3Npb24gb25seSBh ZHZlcnRpc2luZyBvbmUgUlQgbWVtYmVyc2hpcCBOTFJJIGZvciBhIGdpdmVuIFJUIChpLmUuLCBh bGwgdGhlIG90aGVyIFJUIG1lbWJlcnNoaXAgTkxSSXMgY29udGFpbmluZyB0aGF0IFJUIHdvdWxk IGJlIHN1cHByZXNzZWQpPw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KRnJvbTogSWRyIFtt YWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpT ZW50OiBUdWVzZGF5LCBKdW5lIDI0LCAyMDE0IDM6MjQgQU0NClRvOiBKZWZmcmV5IEhhYXMNCkNj OiBpZHJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAudHh0DQoNCkhpIEpl ZmYsDQoNCk1heWJlIEkgYW0gbWlzc2luZyBzb21ldGhpbmcgZnVuZGFtZW50YWwsIGJ1dCB0aGUg bGVjdHVyZSBvZiB5b3VyIGJlbG93IG5vdGUgc29ydCBvZiBzaGVkIGEgY29tcGxldGVseSBuZXcg bGlnaHQgb24gdGhpcyBlbnRpcmUgImlzc3VlIi4NCg0KTGV0J3Mgc3RlcCBiYWNrIGZvciBhIHNl Y29uZCBhbmQgYXNrIG91cnNlbHZlcyB3aHkgdG9wIGxldmVsIFJSIHdvdWxkIG5vdCBzZW5kIGRl ZmF1bHQgUlQgKHNlbmQgYWxsKSBSVEMgTkxSSSB0byBpdCdzIGxvd2VyIGxheWVyIGNsaWVudHMg Pw0KDQpUaGF0IHdheSB0b3AgbGV2ZWwgUlIgd2lsbCBsZWFybiBhbGwgVlBOIHJvdXRlcyBhbmQg ZGlzdHJpYnV0ZSB0aGVtIGFzIHNlZW1zIGZpdCB0byBsb3dlciBsZXZlbCBSUnMgYWNjb3JkaW5n IHRvIGF0b21pYyBSVEMgcm91dGVzIHRoZXkgd2lsbCBwdXNoIHRvIGhpbS4NCg0KSWYgc28gSSB3 b3VsZCBjYWxsIHRoaXMgZW50aXJlICJpc3N1ZSIgYSBtaXNjb25maWd1cmF0aW9uIGFuZCBtb3Zl IG9uIDspDQoNCmJlc3QsDQpyLg0KDQoNCk9uIE1vbiwgSnVuIDIzLCAyMDE0IGF0IDk6MDQgUE0s IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc8bWFpbHRvOmpoYWFzQHBmcmMub3JnPj4gd3Jv dGU6DQpbcmVmb3JtYXR0aW5nIHRvIGF2b2lkIHRoZSB0b3AtcG9zdF0NCg0KT24gTW9uLCBKdW4g MjMsIDIwMTQgYXQgMDg6NTY6MzlQTSArMDIwMCwgUm9iZXJ0IFJhc3p1ayB3cm90ZToNCj4gPiBB ZGQtcGF0aHMgYXJlIGxvY2FsIGJldHdlZW4gcGFpcnMgb2Ygcm91dGVycy4gIFdlJ2QgcmVhbGx5 IG5lZWQgZGlzdGluY3QNCj4gPiBSRC10eXBlIGlkZW50aWZpZXJzIHRvIGNvdmVyIHRoZSBwcm9i bGVtLg0KPiA+DQo+ID4gLS0gSmVmZg0KPiBJIGRvbid0IHRoaW5rIHNvLg0KPg0KPiBOb3RpY2Ug dGhhdCB0aGUgaXNzdWUgaXMgbm90IHRoYXQgd2UgYXJlIHN1cHByZXNzaW5nIHByZXNlbmNlIG9m IFJUQyByb3V0ZXMNCj4gZHVlIHRvIHNlbGVjdGlvbiBvZiBzb21lIG90aGVyIHBhdGhzLiBUaGF0 IGlzIHRoZSBvbmx5IGNhc2Ugd2hpY2ggdW5pcXVlIFJEDQo+IGZvciBSVEMgTkxSSSBjb3VsZCBo ZWxwIHdpdGguDQpUaGUgc3VwcHJlc3Npb24gaXMgaW5jaWRlbnRhbCB0byB0aGUgcHJvYmxlbTog UlQtQyBuZWVkcyB0aGUgcm91dGUgdG8gYm91bmNlDQpiYWNrIGZyb20gYSBSUi1jbGllbnQgd2hl biBpdCdzIGFub3RoZXIgUlIuICBDbHVzdGVyIGxpc3QgaXMgY2F1c2luZyB0aGF0DQpmaWx0ZXJp bmcgdG8gaGFwcGVuLg0KDQpBcyBJIHRyeSB0byBnZXQgYSBoYW5kbGUgb24gcG9zc2libGUgc29s dXRpb25zLCBvbmUgdGhvdWdodCBoYWQgYmVlbiB0aGF0DQp0aGUgcmVmbGVjdGlvbiB3YXMgaXRz ZWxmIGFscmVhZHkgdGhhdCBib3VuY2UtYmFjay4gIEFuIGltcGxlbWVudGF0aW9uDQpzaW1wbHkg a2VlcHMgdGhlIGxvb3BlZCByb3V0ZSAobWFueSBkaXNjYXJkIHN1Y2ggbG9vcHMpIGFuZCB1c2Vz IHRoYXQgZm9yDQppdCdzIFJULUMgZmxvb2Rpbmcgc3RhdGUuDQoNCkhvd2V2ZXIsIHRoZSBSUiBw aW5nLXBvbmcgZHVlIHRvIGludGVyLWNsdXN0ZXIvY2xpZW50IGNoYW5nZXMgbWF5IHJlc3VsdCBp bg0KcGFydGlhbCBtZXNoZXMgb2YgZmxvb2RpbmcgZm9ybWluZyBhbW9uZyB0aGUgdmFyaW91cyBS UnMgd2l0aCByZXN1bHRhbnQNCnRocmFzaGluZyBvZiBWUE4gcm91dGVzLiAgVGhpcyBpcyBhIEJh ZCBUaGluZy4NCg0KPiBUaGUgaXNzdWUgaGVyZSBpcyB3aXRoIGZpbHRlcmVkIGRpc3RyaWJ1dGlv biB2ZWN0b3IgYmV0d2VuIHRvcCBoaWVyYXJjaHkNCj4gYW5kIGxvd2VyIGxheWVyIGZvciBvbmUg UlIgcGVlciB3aGljaCBoYXBwZW4gdG8gYmUgdGhlIHNyYyBvZiB0aGUgYmVzdCBwYXRoDQo+IG9m IHN1Y2ggUlRDIE5MUkkuDQpJIGFncmVlIHdpdGggeW91ciBvYnNlcnZhdGlvbiBmcm9tIHRoaXMg cGVyc3BlY3RpdmUuDQoNCkkgdXJnZSB5b3UgdG8gcmVmcmFtZSB0aGlzIHBlcnNwZWN0aXZlIHRv IGFyYml0cmFyeSBtZXNoZXMgb2YgcmVmbGVjdG9ycywNCnBlcmhhcHMgd2l0aCBtdWx0aXBsZSBj bHVzdGVyIG1lbWJlcnMuDQoNClRoYXQgc2FpZCwgdGhlIHNpbXBsZXN0IHNvbHV0aW9uIHNwYWNl cyB3aWxsIGJlIGVhc2llc3QgdG8gc2VlIChJIHRoaW5rKSBpbg0KdGhlIHNpbXBsZSBleGFtcGxl IEppZSBwcmVzZW50ZWQuDQoNCj4gQWxzbyB3aGlsZSBkaWdlc3RpbmcgdGhlIHByb2JsZW0ga2Vl cCBpbiBtaW5kIHRoYXQgb3BlcmF0aW9uIG9mIFJUQyBpcw0KPiBzZXNzaW9uIG9yaWVudGVkIGFu ZCByZXN1bHRzIGluIHN1cHByZXNzaW9uIG9mIHJlYWwgVlBOIHJvdXRlIGRpc3RyaWJ1dGlvbg0K PiB0byB0b3AgbGV2ZWwgUlIgdmlhIHN1Y2ggbm9kZS4NCkknbSBhbHdheXMga2VlcGluZyB0aGlz IGluIG1pbmQuIDotKQ0KDQotLSBKZWZmDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C645NKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgc2lk ZWVmZmVjdCBvZiBzZW5kaW5nIGRlZmF1bHQgUlQgJm5ic3A7YnkgdGhlIHRvcC1sZXZlbCBSUiBp cyB0aGF0IHNvbWUgVlBOIHJvdXRlcyB3b3VsZCBiZSB1bm5lY2Vzc2FyaWx5IHNlbnQgdG8gdGhh dCB0b3AtbGV2ZWwgUlIuIEhvdyBhYm91dCBhZGRpbmcNCiBSRCB0byB0aGUgUlQgbWVtYmVyc2hp cCBOTFJJIChpLmUuLCB0aGUgUlQgbWVtYmVyc2hpcCBOTFJJcyBvcmlnaW5hdGVkIGZyb20gZGlm ZmVyZW50IFBFcyBhcmUgZGlzdGluZ3Vpc2hhYmxlKSB3aGlsZSBvbiBhIHNlc3Npb24gb25seSBh ZHZlcnRpc2luZyBvbmUgUlQgbWVtYmVyc2hpcCBOTFJJIGZvciBhIGdpdmVuIFJUIChpLmUuLCBh bGwgdGhlIG90aGVyIFJUIG1lbWJlcnNoaXAgTkxSSXMgY29udGFpbmluZyB0aGF0IFJUIHdvdWxk IGJlIHN1cHByZXNzZWQpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0 IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5YaWFv aHU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgSnVuZSAyNCwgMjAxNCAzOjI0IEFNPGJyPg0KPGI+VG86PC9iPiBKZWZmcmV5 IEhhYXM8YnI+DQo8Yj5DYzo8L2I+IGlkckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW0lkcl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kb25nLWlkci1ydGMt aGllcmFyY2hpY2FsLXJyLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5IaSBKZWZmLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1heWJlIEkgYW0gbWlzc2luZyBzb21l dGhpbmcgZnVuZGFtZW50YWwsIGJ1dCB0aGUgbGVjdHVyZSBvZiB5b3VyIGJlbG93IG5vdGUgc29y dCBvZiBzaGVkIGEgY29tcGxldGVseSBuZXcgbGlnaHQgb24gdGhpcyBlbnRpcmUgJnF1b3Q7aXNz dWUmcXVvdDsuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TGV0J3Mgc3RlcCBiYWNrIGZv ciBhIHNlY29uZCBhbmQgYXNrIG91cnNlbHZlcyB3aHkgdG9wIGxldmVsIFJSIHdvdWxkIG5vdCBz ZW5kIGRlZmF1bHQgUlQgKHNlbmQgYWxsKSBSVEMgTkxSSSB0byBpdCdzIGxvd2VyIGxheWVyIGNs aWVudHMgPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoYXQgd2F5IHRvcCBsZXZlbCBS UiB3aWxsIGxlYXJuIGFsbCBWUE4gcm91dGVzIGFuZCBkaXN0cmlidXRlIHRoZW0gYXMgc2VlbXMg Zml0IHRvIGxvd2VyIGxldmVsIFJScyBhY2NvcmRpbmcgdG8gYXRvbWljIFJUQyByb3V0ZXMgdGhl eSB3aWxsIHB1c2ggdG8gaGltLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHNvIEkgd291bGQg Y2FsbCB0aGlzIGVudGlyZSAmcXVvdDtpc3N1ZSZxdW90OyBhIG1pc2NvbmZpZ3VyYXRpb24gYW5k IG1vdmUgb24gOyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5iZXN0LDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gTW9u LCBKdW4gMjMsIDIwMTQgYXQgOTowNCBQTSwgSmVmZnJleSBIYWFzICZsdDs8YSBocmVmPSJtYWls dG86amhhYXNAcGZyYy5vcmciIHRhcmdldD0iX2JsYW5rIj5qaGFhc0BwZnJjLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5bcmVmb3JtYXR0aW5nIHRvIGF2b2lkIHRoZSB0b3AtcG9zdF08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KT24gTW9uLCBKdW4gMjMs IDIwMTQgYXQgMDg6NTY6MzlQTSAmIzQzOzAyMDAsIFJvYmVydCBSYXN6dWsgd3JvdGU6PGJyPg0K Jmd0OyAmZ3Q7IEFkZC1wYXRocyBhcmUgbG9jYWwgYmV0d2VlbiBwYWlycyBvZiByb3V0ZXJzLiAm bmJzcDtXZSdkIHJlYWxseSBuZWVkIGRpc3RpbmN0PGJyPg0KJmd0OyAmZ3Q7IFJELXR5cGUgaWRl bnRpZmllcnMgdG8gY292ZXIgdGhlIHByb2JsZW0uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IC0tIEplZmY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7IEkgZG9uJ3QgdGhpbmsgc28uPGJyPg0KJmd0Ozxicj4NCiZndDsgTm90aWNlIHRo YXQgdGhlIGlzc3VlIGlzIG5vdCB0aGF0IHdlIGFyZSBzdXBwcmVzc2luZyBwcmVzZW5jZSBvZiBS VEMgcm91dGVzPGJyPg0KJmd0OyBkdWUgdG8gc2VsZWN0aW9uIG9mIHNvbWUgb3RoZXIgcGF0aHMu IFRoYXQgaXMgdGhlIG9ubHkgY2FzZSB3aGljaCB1bmlxdWUgUkQ8YnI+DQomZ3Q7IGZvciBSVEMg TkxSSSBjb3VsZCBoZWxwIHdpdGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHN1cHByZXNzaW9uIGlzIGlu Y2lkZW50YWwgdG8gdGhlIHByb2JsZW06IFJULUMgbmVlZHMgdGhlIHJvdXRlIHRvIGJvdW5jZTxi cj4NCmJhY2sgZnJvbSBhIFJSLWNsaWVudCB3aGVuIGl0J3MgYW5vdGhlciBSUi4gJm5ic3A7Q2x1 c3RlciBsaXN0IGlzIGNhdXNpbmcgdGhhdDxicj4NCmZpbHRlcmluZyB0byBoYXBwZW4uPGJyPg0K PGJyPg0KQXMgSSB0cnkgdG8gZ2V0IGEgaGFuZGxlIG9uIHBvc3NpYmxlIHNvbHV0aW9ucywgb25l IHRob3VnaHQgaGFkIGJlZW4gdGhhdDxicj4NCnRoZSByZWZsZWN0aW9uIHdhcyBpdHNlbGYgYWxy ZWFkeSB0aGF0IGJvdW5jZS1iYWNrLiAmbmJzcDtBbiBpbXBsZW1lbnRhdGlvbjxicj4NCnNpbXBs eSBrZWVwcyB0aGUgbG9vcGVkIHJvdXRlIChtYW55IGRpc2NhcmQgc3VjaCBsb29wcykgYW5kIHVz ZXMgdGhhdCBmb3I8YnI+DQppdCdzIFJULUMgZmxvb2Rpbmcgc3RhdGUuPGJyPg0KPGJyPg0KSG93 ZXZlciwgdGhlIFJSIHBpbmctcG9uZyBkdWUgdG8gaW50ZXItY2x1c3Rlci9jbGllbnQgY2hhbmdl cyBtYXkgcmVzdWx0IGluPGJyPg0KcGFydGlhbCBtZXNoZXMgb2YgZmxvb2RpbmcgZm9ybWluZyBh bW9uZyB0aGUgdmFyaW91cyBSUnMgd2l0aCByZXN1bHRhbnQ8YnI+DQp0aHJhc2hpbmcgb2YgVlBO IHJvdXRlcy4gJm5ic3A7VGhpcyBpcyBhIEJhZCBUaGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KJmd0OyBUaGUgaXNzdWUgaGVyZSBpcyB3aXRoIGZp bHRlcmVkIGRpc3RyaWJ1dGlvbiB2ZWN0b3IgYmV0d2VuIHRvcCBoaWVyYXJjaHk8YnI+DQomZ3Q7 IGFuZCBsb3dlciBsYXllciBmb3Igb25lIFJSIHBlZXIgd2hpY2ggaGFwcGVuIHRvIGJlIHRoZSBz cmMgb2YgdGhlIGJlc3QgcGF0aDxicj4NCiZndDsgb2Ygc3VjaCBSVEMgTkxSSS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5JIGFncmVlIHdpdGggeW91ciBvYnNlcnZhdGlvbiBmcm9tIHRoaXMgcGVyc3BlY3RpdmUu PGJyPg0KPGJyPg0KSSB1cmdlIHlvdSB0byByZWZyYW1lIHRoaXMgcGVyc3BlY3RpdmUgdG8gYXJi aXRyYXJ5IG1lc2hlcyBvZiByZWZsZWN0b3JzLDxicj4NCnBlcmhhcHMgd2l0aCBtdWx0aXBsZSBj bHVzdGVyIG1lbWJlcnMuPGJyPg0KPGJyPg0KVGhhdCBzYWlkLCB0aGUgc2ltcGxlc3Qgc29sdXRp b24gc3BhY2VzIHdpbGwgYmUgZWFzaWVzdCB0byBzZWUgKEkgdGhpbmspIGluPGJyPg0KdGhlIHNp bXBsZSBleGFtcGxlIEppZSBwcmVzZW50ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxicj4NCiZndDsgQWxzbyB3aGlsZSBkaWdlc3RpbmcgdGhlIHByb2JsZW0g a2VlcCBpbiBtaW5kIHRoYXQgb3BlcmF0aW9uIG9mIFJUQyBpczxicj4NCiZndDsgc2Vzc2lvbiBv cmllbnRlZCBhbmQgcmVzdWx0cyBpbiBzdXBwcmVzc2lvbiBvZiByZWFsIFZQTiByb3V0ZSBkaXN0 cmlidXRpb248YnI+DQomZ3Q7IHRvIHRvcCBsZXZlbCBSUiB2aWEgc3VjaCBub2RlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkknbSBhbHdheXMga2VlcGluZyB0aGlzIGluIG1pbmQuIDotKTxicj4NCjxicj4NCi0t IEplZmY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C645NKGEML512MBSchi_-- From nobody Mon Jun 23 18:59:59 2014 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 79D881A05CB for ; Mon, 23 Jun 2014 18:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 itfXOAnWGDCC for ; Mon, 23 Jun 2014 18:59:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B281A03AF for ; Mon, 23 Jun 2014 18:59:52 -0700 (PDT) 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 BGF10987; Tue, 24 Jun 2014 01:59:51 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 02:59:49 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 09:59:44 +0800 From: "Dongjie (Jimmy)" To: Jeffrey Haas , Robert Raszuk Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgACZ1UD//3vOgIAAChOAgAADtwCABRJ9gIAA/gQQ Date: Tue, 24 Jun 2014 01:59:43 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927336A7B5E@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15043_1403268251_53A42C9B_15043_2147_1_9E32478DFA9976438E7A22F69B08FF92022DEA@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140623182457.GO11842@pfrc> In-Reply-To: <20140623182457.GO11842@pfrc> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/dTDIg5SCQV1gIZ3ODYVWT51PsZw Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 01:59:57 -0000 Hi Jeff, > On Fri, Jun 20, 2014 at 02:57:28PM +0200, Robert Raszuk wrote: > > I am not worried about efficiency here. >=20 > I am. :-) >=20 > I've been quiet on the thread partially because I don't have any better > observations on the nature of the fix to contribute. But I do have an > observation about the shape of the solution. Your comments are always welcome:) > Solutions that rely on meddling with the existing route reflection semant= ics in > the cluster list will have to deal with the fact that there can be signif= icant > "noise" in convergence events as part of a hierarchical RR environment. = The > sort of "ping pong" that happens is certainly one negative thing that > discourages such deployments. Agree that we need to avoid the oscillation of RTC route. Since the solutio= n proposes to send an alternate RTC route only to the source of best route = and increase its visibility to the RTC routes, with a well designed RR topo= logy this should not change the best path selection on the source of the be= st RTC route. Or maybe you have a specific topology in mind where the "ping= pong" of RTC route could happen?=20 BTW, the existing RTC also modifies the route reflection semantics with the= rules in section 3.2 of RFC 4684. > Where this is particularly messy for VPN environments is that if the full= set of > VPN routes is prevented from being flooded across RRs in the hierarchy wi= th > whatever solution we come up with, then a RT-C reconvergence event could > result in a massive thrashing of routes among the reflectors. That is exactly what we should avoid:) We need to minimize the RTC route re= convergence and make sure each convergence can produce the correct VPN rout= e distribution graph. Best regards, Jie From nobody Mon Jun 23 19:47:24 2014 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 A64AE1B2803 for ; Mon, 23 Jun 2014 19:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 37rPep3BV7By for ; Mon, 23 Jun 2014 19:47:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863D71B27E5 for ; Mon, 23 Jun 2014 19:47:18 -0700 (PDT) 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 BJC78750; Tue, 24 Jun 2014 02:47:16 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 03:47:14 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 10:47:08 +0800 From: "Dongjie (Jimmy)" To: "UTTARO, JAMES" , "'idr@ietf.org'" Thread-Topic: New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAEPJ1CAA6L2EIAAkJHAgAD5kYA= Date: Tue, 24 Jun 2014 02:47:08 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927336A7B8C@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273369B6A5@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/mgZNWtysCMGIpr5fy9TUy_Bskqw Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 02:47:22 -0000 Hi Jim, > -----Original Message----- > From: UTTARO, JAMES [mailto:ju1738@att.com] > Sent: Monday, June 23, 2014 7:24 PM > To: Dongjie (Jimmy); 'idr@ietf.org' > Subject: RE: New Version Notification for > draft-dong-idr-rtc-hierarchical-rr-00.txt >=20 > Jie, >=20 > I still do not understand the architecture of hierarcacal RRs for the VP= NV4 > AF. As evidenced by your diagram and associated text probably not a good = idea. > Regardless of that here are my thoughts, concerns and the where RT-C may > have utility. Maybe the diagram is not clear enough. In one word the problem is the RTC r= oute advertised by higher layer RR is discarded by the lower layer RR, whic= h would block the VPN route distribution from lower layer RR to the higher = layer RR, and cause some PEs cannot receive those VPN routes. You may also find some description about the problem in Robert and Jeff's m= ails:) > RT-C Premise.. >=20 > The reason articulated in the original RT-C draft was based on the notion= that > VPNs would be highly localized in nature and where there associated routi= ng > state could also be contained in a sub-graph of the topology. My experien= ce is > that this is not the case. The major advertisers of routing state are big > organizations that have footprint spanning multiple continents across the= globe. >=20 > A benefit of RT-C may be to limit the amount of routing state sent to a P= E when > a soft refresh, VRF add or re-boot occurs. The savings here is CPU cycles= , ease > of HOL blocking for those implementations that do not discriminate betwee= n > routes incrementally added and a new VRF and reducing reboot time. >=20 > For these limited benefits full blown RT-C is not something I would deplo= y as I > risk fate sharing, disconnected VPNs ( Based on Topology ), etc... For al= l of the > business needs competing for cycles/windows it is difficult to understand= the > cost/benefit.. Agree that RTC may not be the same beneficial for all networks, and analysi= s of the cost/benefit is needed before deployment. As contrast to full blow= n RTC, are you indicating you may deploy RTC partially? > SDN Control >=20 > RT-C like filter deployed from an SDN controller may be the way to go. A= s the > RR/Route Server topology can easily scale to millions of routes we can fo= cus > our energy on reducing the flood of routing state to an individual PE, be= tween > providers or even between RRs although the last one holds little interest= for me. IMO one of the objectives of RTC in traditional scenarios is also to reduce= the unnecessary flooding of VPN routes to PEs. Agree that controlling the route distribution in SDN scenario would be a va= lid use case. And if the controller and the PE are direct BGP peers, ORF ma= y also help. Many thanks, Jie > -----Original Message----- > From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com] > Sent: Sunday, June 22, 2014 10:42 PM > To: UTTARO, JAMES; 'idr@ietf.org' > Subject: RE: New Version Notification for > draft-dong-idr-rtc-hierarchical-rr-00.txt >=20 > Hi Jim, >=20 > Here is the example I previously sent to the list: >=20 > PE1---RR2 > \ > \ > PE2- RR1 > \ / > \ / > RR3 > / > / > PE3- >=20 > RR1 is level-1 RR, and RR2 and RR3 are level-2 RRs. >=20 > 1. All the PEs advertise RTC route of RT-X to their connecting RRs. > 2. RR2 and RR3 select the best RTC route, add their cluster_id to the clu= ster_list > and advertise the RTC route to RR1 respectively. > 3. RR1 selects one RTC route as best (let's say RTC route from RR2), adds= its > cluster_id into the cluster_list and advertises it to RR2 and RR3. > 4. Then RR2 would receive the RTC route from RR1 with its own cluster_id = in the > cluster_list and will drop this RTC route. > 5. As a result, RR2 will not advertise VPN routes with RT-X to RR1. >=20 > For a network with hierarchical RR, RTC can also be useful to control the= VPN > routes being distributed only to PEs which have the corresponding custome= rs > connected. >=20 > I'm not quite clear about your comments about RTC and SDN controller, do = you > mean RTC mechanism can be used to distribute routes to SDN controller? I'= d > agree that is another possible use case of RTC. >=20 > Best regards, > Jie >=20 > > -----Original Message----- > > From: UTTARO, JAMES [mailto:ju1738@att.com] > > Sent: Saturday, June 21, 2014 3:02 AM > > To: Dongjie (Jimmy); 'idr@ietf.org' > > Subject: RE: New Version Notification for > > draft-dong-idr-rtc-hierarchical-rr-00.txt > > > > Why? A picture would be quite useful here. I am struggling to > > understand a hierarcacal design that then needs RT-C?? Maybe if the > > VPNs are highly localized.. BTW isn't RT-C a good candidate to off net = to an > SDN controller? > > IMO that should be the future. > > > > Jim Uttaro > > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) > > Sent: Thursday, June 19, 2014 10:55 PM > > To: idr@ietf.org > > Subject: [Idr] FW: New Version Notification for > > draft-dong-idr-rtc-hierarchical-rr-00.txt > > > > Hi all, > > > > This is a short draft to make RTC applicable in hierarchical RR scenari= o. > > > > Comments are welcome. > > > > Best regards, > > Jie > > > > > -----Original Message----- > > > > > > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt > > > has been successfully submitted by Jie Dong and posted to the IETF > repository. > > > > > > Name: draft-dong-idr-rtc-hierarchical-rr > > > Revision: 00 > > > Title: Extensions to RT-Constrain in Hierarchical Route Reflection > > > Scenarios > > > Document date: 2014-06-19 > > > Group: Individual Submission > > > Pages: 5 > > > URL: > > > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarchical- > > > rr > > > -00.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchical-rr/ > > > Htmlized: > > > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-00 > > > > > > > > > Abstract: > > > The Route Target (RT) Constrain mechanism specified in RFC 4684 is > > > used to build a route distribution graph in order to restrict the > > > propagation of Virtual Private Network (VPN) routes. In network > > > scenarios where hierarchical route reflection (RR) is used, the > > > existing RT-Constrain mechanism cannot build a correct route > > > distribution graph. This document refines the route distribution > > > rules of RT-Constrain to address the hierarchical RR scenarios. > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at tools= .ietf.org. > > > > > > The IETF Secretariat > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Jun 24 00:19:30 2014 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 D5EAB1B285B for ; Tue, 24 Jun 2014 00:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvJ1Dlr2ySNW for ; Tue, 24 Jun 2014 00:19:28 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29EB1B283E for ; Tue, 24 Jun 2014 00:19:28 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id rp18so7090535iec.27 for ; Tue, 24 Jun 2014 00:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h/iKRRWrtdFDl0E+WwSrDHG9JhsK5mdRZDzv9Or4c/g=; b=nYBUYMlIXksTRlkLPe3Q1idGh6fj1+6REILxIxpsjlWl233r9GZKoX1CEalYu1sTM5 ab3gF+40B9Hz1my360JsnZh8j3A6yuGOwCGh8uyE8fSDEoO/5YKJzHaoxAeyN77XsMek Ca3/z/GS7rbGjWZghuVJlhpXWRJzusGwGnr+Jb6mLJvZ66QgfDTiY+nNG6U0psl5cRRA 8WjytkrBBb+QPd9+eox/vbIoyTDN0PLb5AfkKVc0xctcrVjMNrgoNjID/pb+6EuxwWbk SKnU+4tnd30sxDMpB4/JevWMkcxzTeRUUVTA1Kk5XBhTeuIsHyGx1qxLyKqqlhSmsdrL pfMg== MIME-Version: 1.0 X-Received: by 10.50.98.100 with SMTP id eh4mr32843995igb.9.1403594367995; Tue, 24 Jun 2014 00:19:27 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Tue, 24 Jun 2014 00:19:27 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C645@NKGEML512-MBS.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <20140623182619.GP11842@pfrc> <20140623190420.GT11842@pfrc> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C645@NKGEML512-MBS.china.huawei.com> Date: Tue, 24 Jun 2014 09:19:27 +0200 X-Google-Sender-Auth: hRzhfQdY0xR0fESmwtG3YHjBu8U Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: multipart/alternative; boundary=047d7b2e15dfb694a704fc8fc722 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/6w_dH8jrZ5M4gjV5yYYLK98Sr_4 Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 07:19:30 -0000 --047d7b2e15dfb694a704fc8fc722 Content-Type: text/plain; charset=UTF-8 Hi Xu, IMO changing the format of RTC NLRI is the worst idea of all discussed so far on this thread. Sorry. It is not backwards compatible and will result in heavy deployment mess. Note that this will likely require new SAFI and transition scheme as well as moving current RFC4864 to historic. NLRI is a database key in RTC. So by all means you are free to propose a new draft on that and let the IDR WG (maybe with L3VPN input) decide. If anything I am eager to read the "Justification section" of the new proposal .... Cheers, R. On Tue, Jun 24, 2014 at 3:33 AM, Xuxiaohu wrote: > The sideeffect of sending default RT by the top-level RR is that some > VPN routes would be unnecessarily sent to that top-level RR. How about > adding RD to the RT membership NLRI (i.e., the RT membership NLRIs > originated from different PEs are distinguishable) while on a session only > advertising one RT membership NLRI for a given RT (i.e., all the other RT > membership NLRIs containing that RT would be suppressed)? > > > > Best regards, > > Xiaohu > > > --047d7b2e15dfb694a704fc8fc722 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Xu,

IMO changing the format of RTC NLRI is the worst idea of all discussed so f= ar on this thread. Sorry.

It is not backwards compatible and will result in heavy deployment mess.=C2= =A0

Note that this will likely require new SAFI and transition scheme as well a= s moving current RFC4864 to historic.=C2=A0

NLRI is a database key in RTC.=C2=A0

So by all means you are free to propose a new draft on that and let th= e IDR WG (maybe with L3VPN input) decide.=C2=A0

If anything I am eager to read the &q= uot;Justification section" of the new proposal ....

Cheers,
R.



On Tue, Jun 24, 2014 at 3:33 AM, Xuxiaohu <xuxiaohu@hua= wei.com> wrote:

The sideef= fect of sending default RT =C2=A0by the top-level RR is that some VPN route= s would be unnecessarily sent to that top-level RR. How about adding RD to the RT membership NLRI (i.e., the RT membership NLRIs originated fro= m different PEs are distinguishable) while on a session only advertising on= e RT membership NLRI for a given RT (i.e., all the other RT membership NLRI= s containing that RT would be suppressed)?

=C2= =A0

Best regar= ds,

Xiaohu<= /u>

=C2= =A0

--047d7b2e15dfb694a704fc8fc722-- From nobody Tue Jun 24 01:39:12 2014 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 6DDD71A01B8 for ; Tue, 24 Jun 2014 01:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 aWy5RYa1TfIy for ; Tue, 24 Jun 2014 01:39:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29281A0165 for ; Tue, 24 Jun 2014 01:39:07 -0700 (PDT) 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 BJE10727; Tue, 24 Jun 2014 08:39:05 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 09:39:03 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 16:38:58 +0800 From: Xuxiaohu To: Robert Raszuk Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//4fPgIAAGG8AgAKT/sD//7OAAIAAzkiAgAAIeoCAAAIlAIAABYEAgADnqBD//+A7gAAR+TPw Date: Tue, 24 Jun 2014 08:38:58 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C726@NKGEML512-MBS.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <20140623182619.GP11842@pfrc> <20140623190420.GT11842@pfrc> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C645@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C726NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Ib4Vf1_FNduNBCS2jMV3k6As1M4 Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 08:39:11 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C726NKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJIGFncmVlIHRoYXQgY2hhbmdpbmcgdGhlIGZvcm1hdCBvZiBSVEMgTkxS SSBpcyB0aGUgd29yc3QgaWRlYSBmcm9tIHRoZSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBwZXJz cGVjdGl2ZS4gSG93ZXZlciwgaWYgeW91IG5lZWQgdGhlIFJUQyB0byBiZSBhcHBsaWNhYmxlIGlu IGFueSBCR1AgdG9wb2xvZ3kgKGUuZy4sIGFyYml0cmFyeSBtZXNoZXMgb2YgcmVmbGVjdG9ycyks IGl0IHNlZW1zIHdvcnRod2hpbGUgdG8gY29uc2lkZXIgdGhhdCBwb3NzaWJpbGl0eS4gRnVydGhl cm1vcmUsIHdpdGggdGhhdCBhcHByb2FjaCwgdGhlIGZvbGxvd2luZyBjb21wbGV4IGFkdmVydGlz ZW1lbnQgcnVsZXMgKHNlZSBiZWxvdykgd291bGQgYmUgZ3JlYXRseSBzaW1wbGlmaWVkLCBpbiBv dGhlciB3b3JkcywgbGVzcyBjaGFuZ2VzIHRvIHRoZSBiYXNpYyBCR1AgYWR2ZXJ0aXNlbWVudCBw cm9jZWR1cmVzIHdvdWxkIGJlIHJlcXVpcmVkLg0KDQpXaGVuIHByb2Nlc3NpbmcgUlQgbWVtYmVy c2hpcCBOTFJJcyByZWNlaXZlZCBmcm9tIGludGVybmFsIGlCR1ANCiAgIHBlZXJzLCBpdCBpcyBu ZWNlc3NhcnkgdG8gY29uc2lkZXIgYWxsIGF2YWlsYWJsZSBpQkdQIHBhdGhzIGZvciBhDQogICBn aXZlbiBSVCBwcmVmaXgsIGZvciBidWlsZGluZyB0aGUgb3V0Ym91bmQgcm91dGUgZmlsdGVyLCBh bmQgbm90IGp1c3QNCiAgIHRoZSBiZXN0IHBhdGguDQoNCiAgIEluIGFkZGl0aW9uLCB3aGVuIGFk dmVydGlzaW5nIFJvdXRlIFRhcmdldCBtZW1iZXJzaGlwIGluZm9ybWF0aW9uDQogICBzb3VyY2Vk IGJ5IHRoZSBsb2NhbCBhdXRvbm9tb3VzIHN5c3RlbSB0byBhbiBpQkdQIHBlZXIsIGEgQkdQIHNw ZWFrZXINCiAgIHNoYWxsIG1vZGlmeSBpdHMgcHJvY2VkdXJlIHRvIGNhbGN1bGF0ZSB0aGUgQkdQ IGF0dHJpYnV0ZXMgc3VjaCB0aGF0DQogICB0aGUgZm9sbG93aW5nIGFwcGx5Og0KDQogICBpLiAg IFdoZW4gYWR2ZXJ0aXNpbmcgUlQgbWVtYmVyc2hpcCBOTFJJIHRvIGEgcm91dGUtcmVmbGVjdG9y IGNsaWVudCwNCiAgICAgICAgdGhlIE9yaWdpbmF0b3IgYXR0cmlidXRlIHNoYWxsIGJlIHNldCB0 byB0aGUgcm91dGVyLWlkIG9mIHRoZQ0KICAgICAgICBhZHZlcnRpc2VyLCBhbmQgdGhlIE5leHQt aG9wIGF0dHJpYnV0ZSBzaGFsbCBiZSBzZXQgb2YgdGhlIGxvY2FsDQogICAgICAgIGFkZHJlc3Mg Zm9yIHRoYXQgc2Vzc2lvbi4NCg0KICAgaWkuICBXaGVuIGFkdmVydGlzaW5nIGFuIFJUIG1lbWJl cnNoaXAgTkxSSSB0byBhIG5vbi1jbGllbnQgcGVlciwgaWYNCiAgICAgICAgdGhlIGJlc3QgcGF0 aCBhcyBzZWxlY3RlZCBieSB0aGUgcGF0aCBzZWxlY3Rpb24gcHJvY2VkdXJlDQogICAgICAgIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDkuMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0Njg0 I3NlY3Rpb24tOS4xPiBvZiB0aGUgYmFzZSBCR1Agc3BlY2lmaWNhdGlvbiBbNDxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM0Njg0I3JlZi00Pl0gaXMgYQ0KICAgICAgICByb3V0ZSByZWNl aXZlZCBmcm9tIGEgbm9uLWNsaWVudCBwZWVyLCBhbmQgaWYgdGhlcmUgaXMgYW4NCiAgICAgICAg YWx0ZXJuYXRpdmUgcGF0aCB0byB0aGUgc2FtZSBkZXN0aW5hdGlvbiBmcm9tIGEgY2xpZW50LCB0 aGUNCiAgICAgICAgYXR0cmlidXRlcyBvZiB0aGUgY2xpZW50IHBhdGggYXJlIGFkdmVydGlzZWQg dG8gdGhlIHBlZXIuDQoNCiAgIFRoZSBmaXJzdCBvZiB0aGVzZSByb3V0ZSBhZHZlcnRpc2VtZW50 IHJ1bGVzIGlzIGRlc2lnbmVkIHN1Y2ggdGhhdA0KICAgdGhlIG9yaWdpbmF0b3Igb2YgYW4gUlQg bWVtYmVyc2hpcCBOTFJJIGRvZXMgbm90IGRyb3AgYW4gUlQNCiAgIG1lbWJlcnNoaXAgTkxSSSB0 aGF0IGlzIHJlZmxlY3RlZCBiYWNrIHRvIGl0LCB0aHVzIGFsbG93aW5nIHRoZSByb3V0ZQ0KICAg cmVmbGVjdG9yIHRvIHVzZSB0aGlzIFJUIG1lbWJlcnNoaXAgTkxSSSBpbiBvcmRlciB0byBzaWdu YWwgdGhlDQogICBjbGllbnQgdGhhdCBpdCBzaG91bGQgZGlzdHJpYnV0ZSBWUE4gcm91dGVzIHdp dGggdGhlIHNwZWNpZmljIHRhcmdldA0KICAgdG93YXJkcyB0aGUgcmVmbGVjdG9yLg0KDQogICBU aGUgc2Vjb25kIHJ1bGUgYWxsb3dzIGFueSBCR1Agc3BlYWtlciBwcmVzZW50IGluIGFuIGlCR1Ag bWVzaCB0bw0KICAgc2lnbmFsIHRoZSBpbnRlcmVzdCBvZiBpdHMgcm91dGUgcmVmbGVjdGlvbiBj bGllbnRzIGluIHJlY2VpdmluZyBWUE4NCiAgIHJvdXRlcyBmb3IgdGhhdCB0YXJnZXQuDQoNCg0K DQpCVFcsIGl0IHNhaWQgaW4gUkZDNDY4NA0KDQoNCiAgIEFuIGFsdGVybmF0aXZlIHNvbHV0aW9u IHRvIHRoZSBwcm9jZWR1cmUgZ2l2ZW4gYWJvdmUgd291bGQgaGF2ZSBiZWVuDQoNCiAgIHRvIHNv dXJjZSBkaWZmZXJlbnQgcm91dGVzIHBlciBQRSwgc3VjaCBhcyBOTFJJIG9mIHRoZSBmb3JtDQoN CiAgIHtvcmlnaW5hdG9yLWlkLCByb3V0ZS10YXJnZXR9LCBhbmQgdG8gYWdncmVnYXRlIHRoZW0g YXQgdGhlIGVkZ2Ugb2YNCg0KICAgdGhlIG5ldHdvcmsuICBUaGUgc29sdXRpb24gYWRvcHRlZCBp cyBjb25zaWRlcmVkIGFkdmFudGFnZW91cyBvdmVyDQoNCiAgIHRoZSBmb3JtZXIgaW4gdGhhdCBp dCByZXF1aXJlcyBsZXNzIHJvdXRpbmctaW5mb3JtYXRpb24gd2l0aGluIGENCg0KICAgZ2l2ZW4g QVMuDQoNCg0KDQpJTUhPLCBieSB1c2luZyB0aGUgc3VwcHJlc3Npb24gdHJpY2sgYXMgbWVudGlv bmVkIGJlZm9yZSwgaXQgc2VlbXMgdGhhdCB0aGUgYXBwcm9hY2ggYXMgbWVudGlvbmVkIGFib3Zl IGRvZXNu4oCZdCByZXF1aXJlIG1vcmUgcm91dGluZy1pbmZvcm1hdGlvbiB3aXRoaW4gYSBnaXZl biBBU+KYug0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KRnJvbTogcnJhc3p1a0BnbWFpbC5j b20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsN ClNlbnQ6IFR1ZXNkYXksIEp1bmUgMjQsIDIwMTQgMzoxOSBQTQ0KVG86IFh1eGlhb2h1DQpDYzog SmVmZnJleSBIYWFzOyBpZHJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRyXSBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAu dHh0DQoNCkhpIFh1LA0KDQpJTU8gY2hhbmdpbmcgdGhlIGZvcm1hdCBvZiBSVEMgTkxSSSBpcyB0 aGUgd29yc3QgaWRlYSBvZiBhbGwgZGlzY3Vzc2VkIHNvIGZhciBvbiB0aGlzIHRocmVhZC4gU29y cnkuDQoNCkl0IGlzIG5vdCBiYWNrd2FyZHMgY29tcGF0aWJsZSBhbmQgd2lsbCByZXN1bHQgaW4g aGVhdnkgZGVwbG95bWVudCBtZXNzLg0KDQpOb3RlIHRoYXQgdGhpcyB3aWxsIGxpa2VseSByZXF1 aXJlIG5ldyBTQUZJIGFuZCB0cmFuc2l0aW9uIHNjaGVtZSBhcyB3ZWxsIGFzIG1vdmluZyBjdXJy ZW50IFJGQzQ4NjQgdG8gaGlzdG9yaWMuDQoNCk5MUkkgaXMgYSBkYXRhYmFzZSBrZXkgaW4gUlRD Lg0KDQpTbyBieSBhbGwgbWVhbnMgeW91IGFyZSBmcmVlIHRvIHByb3Bvc2UgYSBuZXcgZHJhZnQg b24gdGhhdCBhbmQgbGV0IHRoZSBJRFIgV0cgKG1heWJlIHdpdGggTDNWUE4gaW5wdXQpIGRlY2lk ZS4NCg0KSWYgYW55dGhpbmcgSSBhbSBlYWdlciB0byByZWFkIHRoZSAiSnVzdGlmaWNhdGlvbiBz ZWN0aW9uIiBvZiB0aGUgbmV3IHByb3Bvc2FsIC4uLi4NCg0KDQoNCkNoZWVycywNClIuDQoNCg0K DQpPbiBUdWUsIEp1biAyNCwgMjAxNCBhdCAzOjMzIEFNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVh d2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+IHdyb3RlOg0KVGhlIHNpZGVlZmZl Y3Qgb2Ygc2VuZGluZyBkZWZhdWx0IFJUICBieSB0aGUgdG9wLWxldmVsIFJSIGlzIHRoYXQgc29t ZSBWUE4gcm91dGVzIHdvdWxkIGJlIHVubmVjZXNzYXJpbHkgc2VudCB0byB0aGF0IHRvcC1sZXZl bCBSUi4gSG93IGFib3V0IGFkZGluZyBSRCB0byB0aGUgUlQgbWVtYmVyc2hpcCBOTFJJIChpLmUu LCB0aGUgUlQgbWVtYmVyc2hpcCBOTFJJcyBvcmlnaW5hdGVkIGZyb20gZGlmZmVyZW50IFBFcyBh cmUgZGlzdGluZ3Vpc2hhYmxlKSB3aGlsZSBvbiBhIHNlc3Npb24gb25seSBhZHZlcnRpc2luZyBv bmUgUlQgbWVtYmVyc2hpcCBOTFJJIGZvciBhIGdpdmVuIFJUIChpLmUuLCBhbGwgdGhlIG90aGVy IFJUIG1lbWJlcnNoaXAgTkxSSXMgY29udGFpbmluZyB0aGF0IFJUIHdvdWxkIGJlIHN1cHByZXNz ZWQpPw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C726NKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byP IjsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1D TiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb2JlcnQsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCBjaGFuZ2luZyB0aGUgZm9ybWF0IG9mIFJUQyBOTFJJ IGlzIHRoZSB3b3JzdCBpZGVhIGZyb20gdGhlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHBlcnNw ZWN0aXZlLiBIb3dldmVyLCBpZiB5b3UgbmVlZCB0aGUgUlRDIHRvIGJlDQogYXBwbGljYWJsZSBp biBhbnkgQkdQIHRvcG9sb2d5IChlLmcuLCBhcmJpdHJhcnkgbWVzaGVzIG9mIHJlZmxlY3RvcnMp LCBpdCBzZWVtcyB3b3J0aHdoaWxlIHRvIGNvbnNpZGVyIHRoYXQgcG9zc2liaWxpdHkuIEZ1cnRo ZXJtb3JlLCB3aXRoIHRoYXQgYXBwcm9hY2gsIHRoZSBmb2xsb3dpbmcgY29tcGxleCBhZHZlcnRp c2VtZW50IHJ1bGVzIChzZWUgYmVsb3cpIHdvdWxkIGJlIGdyZWF0bHkgc2ltcGxpZmllZCwgaW4g b3RoZXIgd29yZHMsIGxlc3MNCiBjaGFuZ2VzIHRvIHRoZSBiYXNpYyBCR1AgYWR2ZXJ0aXNlbWVu dCBwcm9jZWR1cmVzIHdvdWxkIGJlIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2 LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0i RU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XaGVuIHByb2Nlc3NpbmcgUlQgbWVtYmVyc2hp cCBOTFJJcyByZWNlaXZlZCBmcm9tIGludGVybmFsIGlCR1A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBwZWVy cywgaXQgaXMgbmVjZXNzYXJ5IHRvIGNvbnNpZGVyIGFsbCBhdmFpbGFibGUgaUJHUCBwYXRocyBm b3IgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7Jm5ic3A7IGdpdmVuIFJUIHByZWZpeCwgZm9yIGJ1aWxkaW5nIHRoZSBv dXRib3VuZCByb3V0ZSBmaWx0ZXIsIGFuZCBub3QganVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHRoZSBi ZXN0IHBhdGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBJbiBhZGRpdGlvbiwgd2hlbiBh ZHZlcnRpc2luZyBSb3V0ZSBUYXJnZXQgbWVtYmVyc2hpcCBpbmZvcm1hdGlvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 Jm5ic3A7IHNvdXJjZWQgYnkgdGhlIGxvY2FsIGF1dG9ub21vdXMgc3lzdGVtIHRvIGFuIGlCR1Ag cGVlciwgYSBCR1Agc3BlYWtlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHNoYWxsIG1vZGlmeSBpdHMgcHJv Y2VkdXJlIHRvIGNhbGN1bGF0ZSB0aGUgQkdQIGF0dHJpYnV0ZXMgc3VjaCB0aGF0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDsmbmJzcDsgdGhlIGZvbGxvd2luZyBhcHBseTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBs YW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7 IGkuJm5ic3A7Jm5ic3A7IFdoZW4gYWR2ZXJ0aXNpbmcgUlQgbWVtYmVyc2hpcCBOTFJJIHRvIGEg cm91dGUtcmVmbGVjdG9yIGNsaWVudCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0aGUgT3JpZ2luYXRvciBhdHRyaWJ1dGUgc2hhbGwgYmUgc2V0IHRvIHRo ZSByb3V0ZXItaWQgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgYWR2ZXJ0aXNlciwgYW5kIHRoZSBOZXh0LWhvcCBhdHRyaWJ1dGUgc2hhbGwgYmUg c2V0IG9mIHRoZSBsb2NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGFkZHJlc3MgZm9yIHRoYXQgc2Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i c3A7IGlpLiZuYnNwOyBXaGVuIGFkdmVydGlzaW5nIGFuIFJUIG1lbWJlcnNoaXAgTkxSSSB0byBh IG5vbi1jbGllbnQgcGVlciwgaWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0aGUgYmVzdCBwYXRoIGFzIHNlbGVjdGVkIGJ5IHRoZSBwYXRoIHNlbGVjdGlv biBwcm9jZWR1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBkZXNjcmliZWQgaW4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ2 ODQjc2VjdGlvbi05LjEiPlNlY3Rpb24gOS4xPC9hPiBvZiB0aGUgYmFzZSBCR1Agc3BlY2lmaWNh dGlvbiBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDY4NCNyZWYtNCIg dGl0bGU9IiZxdW90O0EgQm9yZGVyIEdhdGV3YXkgUHJvdG9jb2wgNCAoQkdQLTQpJnF1b3Q7Ij40 PC9hPl0gaXMgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHJvdXRlIHJlY2VpdmVkIGZyb20gYSBub24tY2xpZW50IHBlZXIsIGFuZCBpZiB0aGVyZSBpcyBh bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFsdGVybmF0 aXZlIHBhdGggdG8gdGhlIHNhbWUgZGVzdGluYXRpb24gZnJvbSBhIGNsaWVudCwgdGhlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXR0cmlidXRlcyBvZiB0 aGUgY2xpZW50IHBhdGggYXJlIGFkdmVydGlzZWQgdG8gdGhlIHBlZXIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOyZuYnNwOyBUaGUgZmlyc3Qgb2YgdGhlc2Ugcm91dGUgYWR2ZXJ0aXNlbWVudCBydWxl cyBpcyBkZXNpZ25lZCBzdWNoIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyB0aGUgb3JpZ2luYXRvciBv ZiBhbiBSVCBtZW1iZXJzaGlwIE5MUkkgZG9lcyBub3QgZHJvcCBhbiBSVDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i c3A7IG1lbWJlcnNoaXAgTkxSSSB0aGF0IGlzIHJlZmxlY3RlZCBiYWNrIHRvIGl0LCB0aHVzIGFs bG93aW5nIHRoZSByb3V0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHJlZmxlY3RvciB0byB1c2UgdGhpcyBS VCBtZW1iZXJzaGlwIE5MUkkgaW4gb3JkZXIgdG8gc2lnbmFsIHRoZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7 IGNsaWVudCB0aGF0IGl0IHNob3VsZCBkaXN0cmlidXRlIFZQTiByb3V0ZXMgd2l0aCB0aGUgc3Bl Y2lmaWMgdGFyZ2V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgdG93YXJkcyB0aGUgcmVmbGVjdG9yLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgVGhlIHNlY29uZCBydWxlIGFsbG93cyBhbnkgQkdQIHNw ZWFrZXIgcHJlc2VudCBpbiBhbiBpQkdQIG1lc2ggdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBzaWduYWwg dGhlIGludGVyZXN0IG9mIGl0cyByb3V0ZSByZWZsZWN0aW9uIGNsaWVudHMgaW4gcmVjZWl2aW5n IFZQTjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHJvdXRlcyBmb3IgdGhhdCB0YXJnZXQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CVFcsIGl0IHNhaWQgaW4gUkZDNDY4NDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBs YW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBBbiBhbHRlcm5h dGl2ZSBzb2x1dGlvbiB0byB0aGUgcHJvY2VkdXJlIGdpdmVuIGFib3ZlIHdvdWxkIGhhdmUgYmVl bjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZu YnNwOyB0byBzb3VyY2UgZGlmZmVyZW50IHJvdXRlcyBwZXIgUEUsIHN1Y2ggYXMgTkxSSSBvZiB0 aGUgZm9ybTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyB7b3JpZ2luYXRvci1pZCwgcm91dGUtdGFyZ2V0fSwgYW5kIHRvIGFnZ3JlZ2F0 ZSB0aGVtIGF0IHRoZSBlZGdlIG9mPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHRoZSBuZXR3b3JrLiZuYnNwOyBUaGUgc29sdXRpb24g YWRvcHRlZCBpcyBjb25zaWRlcmVkIGFkdmFudGFnZW91cyBvdmVyPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9 IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHRoZSBmb3JtZXIgaW4g dGhhdCBpdCByZXF1aXJlcyBsZXNzIHJvdXRpbmctaW5mb3JtYXRpb24gd2l0aGluIGE8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgZ2l2 ZW4gQVMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SU1ITywgYnkgdXNpbmcg dGhlIHN1cHByZXNzaW9uIHRyaWNrIGFzIG1lbnRpb25lZCBiZWZvcmUsIGl0IHNlZW1zIHRoYXQg dGhlIGFwcHJvYWNoIGFzIG1lbnRpb25lZCBhYm92ZSBkb2VzbuKAmXQgcmVxdWlyZSBtb3JlIHJv dXRpbmctaW5mb3JtYXRpb24NCiB3aXRoaW4gYSBnaXZlbiBBUzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9y OiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVz dCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WGlh b2h1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86 cnJhc3p1a0BnbWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAyNCwgMjAxNCAzOjE5IFBNPGJyPg0KPGI+VG86 PC9iPiBYdXhpYW9odTxicj4NCjxiPkNjOjwvYj4gSmVmZnJleSBIYWFzOyBpZHJAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGkgWHUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SU1P IGNoYW5naW5nIHRoZSBmb3JtYXQgb2YgUlRDIE5MUkkgaXMgdGhlIHdvcnN0IGlkZWEgb2YgYWxs IGRpc2N1c3NlZCBzbyBmYXIgb24gdGhpcyB0aHJlYWQuIFNvcnJ5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPkl0IGlzIG5vdCBiYWNrd2FyZHMgY29tcGF0aWJsZSBhbmQgd2lsbCByZXN1bHQgaW4g aGVhdnkgZGVwbG95bWVudCBtZXNzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5vdGUg dGhhdCB0aGlzIHdpbGwgbGlrZWx5IHJlcXVpcmUgbmV3IFNBRkkgYW5kIHRyYW5zaXRpb24gc2No ZW1lIGFzIHdlbGwgYXMgbW92aW5nIGN1cnJlbnQgUkZDNDg2NCB0byBoaXN0b3JpYy4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OTFJJIGlzIGEgZGF0YWJhc2Uga2V5IGluIFJUQy4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TbyBieSBhbGwgbWVhbnMgeW91IGFyZSBmcmVlIHRv IHByb3Bvc2UgYSBuZXcgZHJhZnQgb24gdGhhdCBhbmQgbGV0IHRoZSBJRFIgV0cgKG1heWJlIHdp dGggTDNWUE4gaW5wdXQpIGRlY2lkZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiBh bnl0aGluZyBJIGFtIGVhZ2VyIHRvIHJlYWQgdGhlICZxdW90O0p1c3RpZmljYXRpb24gc2VjdGlv biZxdW90OyBvZiB0aGUgbmV3IHByb3Bvc2FsIC4uLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5D aGVlcnMsPGJyPg0KUi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUdWUsIEp1biAyNCwgMjAxNCBhdCAzOjMz IEFNLCBYdXhpYW9odSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20iIHRh cmdldD0iX2JsYW5rIj54dXhpYW9odUBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHNp ZGVlZmZlY3Qgb2Ygc2VuZGluZyBkZWZhdWx0IFJUICZuYnNwO2J5IHRoZSB0b3AtbGV2ZWwgUlIg aXMgdGhhdCBzb21lIFZQTiByb3V0ZXMgd291bGQNCiBiZSB1bm5lY2Vzc2FyaWx5IHNlbnQgdG8g dGhhdCB0b3AtbGV2ZWwgUlIuIEhvdyBhYm91dCBhZGRpbmcgUkQgdG8gdGhlIFJUIG1lbWJlcnNo aXAgTkxSSSAoaS5lLiwgdGhlIFJUIG1lbWJlcnNoaXAgTkxSSXMgb3JpZ2luYXRlZCBmcm9tIGRp ZmZlcmVudCBQRXMgYXJlIGRpc3Rpbmd1aXNoYWJsZSkgd2hpbGUgb24gYSBzZXNzaW9uIG9ubHkg YWR2ZXJ0aXNpbmcgb25lIFJUIG1lbWJlcnNoaXAgTkxSSSBmb3IgYSBnaXZlbiBSVCAoaS5lLiwg YWxsDQogdGhlIG90aGVyIFJUIG1lbWJlcnNoaXAgTkxSSXMgY29udGFpbmluZyB0aGF0IFJUIHdv dWxkIGJlIHN1cHByZXNzZWQpPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJl c3QgcmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5YaWFvaHU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C726NKGEML512MBSchi_-- From nobody Tue Jun 24 06:11:04 2014 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 7A7B51B294D for ; Tue, 24 Jun 2014 06:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 cP-4GlAHgmPu for ; Tue, 24 Jun 2014 06:10:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 975781B2942 for ; Tue, 24 Jun 2014 06:10:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AA2A0C22C; Tue, 24 Jun 2014 09:10:54 -0400 (EDT) Date: Tue, 24 Jun 2014 09:10:54 -0400 From: Jeffrey Haas To: "Dongjie (Jimmy)" Message-ID: <20140624131054.GU11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15043_1403268251_53A42C9B_15043_2147_1_9E32478DFA9976438E7A22F69B08FF92022DEA@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140623182457.GO11842@pfrc> <76CD132C3ADEF848BD84D028D243C927336A7B5E@nkgeml512-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76CD132C3ADEF848BD84D028D243C927336A7B5E@nkgeml512-mbx.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/NiekRUOnXMz26jCMs2kHz7TnqTA Cc: "idr@ietf.org" , Robert Raszuk Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:11:01 -0000 Jie, On Tue, Jun 24, 2014 at 01:59:43AM +0000, Dongjie (Jimmy) wrote: > BTW, the existing RTC also modifies the route reflection semantics with the rules in section 3.2 of RFC 4684. Arguably, incompletely working through the impacts of this are what got us into this problem. :-) -- Jeff From nobody Tue Jun 24 06:20:26 2014 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 D2C601B2942 for ; Tue, 24 Jun 2014 06:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 BtdQUmHEL2pr for ; Tue, 24 Jun 2014 06:20:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8B51B2915 for ; Tue, 24 Jun 2014 06:20:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CB687C22C; Tue, 24 Jun 2014 09:20:20 -0400 (EDT) Date: Tue, 24 Jun 2014 09:20:20 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140624132020.GV11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <20140623182619.GP11842@pfrc> <20140623190420.GT11842@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jKxT3N5UDpD3jo7O6dEsJW6G72I Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:20:26 -0000 Robert, On Mon, Jun 23, 2014 at 09:24:02PM +0200, Robert Raszuk wrote: > Let's step back for a second and ask ourselves why top level RR would not > send default RT (send all) RTC NLRI to it's lower layer clients ? > > That way top level RR will learn all VPN routes and distribute them as > seems fit to lower level RRs according to atomic RTC routes they will push > to him. > > If so I would call this entire "issue" a misconfiguration and move on ;) As mentioned elsewhere in-thread, this does break some of the semantic of the route distribution graph. But let's focus on this for a moment as a point of discussion. Assume for a moment that we decide that the route selection behavior of a mesh of reflectors is something we don't care to meddle with too much in order to fix RT-C's behavior in this scenario. What we then have is something that more strongly resembles the more typical deployment scenario for RT-C: PE's run RT-C toward their first-hop RR and the prime benefit is pruning paths from PE through the core to another PE. If we treat the/a mesh of RRs as a place where we don't try to prune paths but realize that much of our benefit remains near the edges, then reducing this to the case where we distribute all VPN routes within the mesh may simply solve the problem. In such a case, we wouldn't want to generate a default RT-C route for a few reasons: - We can't properly limit its distribution to the RR infrastructure. - We don't want to interfere with a legitimate default route. We should still have implementations *act* as if they received default - or effectively just don't implement RT-C filtering. The main circumstance necessary to do this is to know when the remote RR-client is also an RR. Nothing in the protocol is going to tell us this a priori; we need this via configuration. -- Jeff From nobody Tue Jun 24 06:23:19 2014 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 9D5761B29B3 for ; Tue, 24 Jun 2014 06:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 qjHm-Gs18zxc for ; Tue, 24 Jun 2014 06:23:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F0B6C1B294D for ; Tue, 24 Jun 2014 06:23:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BED19C22C; Tue, 24 Jun 2014 09:23:15 -0400 (EDT) Date: Tue, 24 Jun 2014 09:23:15 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140624132315.GW11842@pfrc> References: <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <20140623182619.GP11842@pfrc> <20140623190420.GT11842@pfrc> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C645@NKGEML512-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/sVUAp2xp-5zzGebPmC4gyK2L5aM Cc: "idr@ietf.org" , Xuxiaohu Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:23:17 -0000 On Tue, Jun 24, 2014 at 09:19:27AM +0200, Robert Raszuk wrote: > IMO changing the format of RTC NLRI is the worst idea of all discussed so > far on this thread. Sorry. > > It is not backwards compatible and will result in heavy deployment mess. Agreed. But the fun part is the original authors told us this had been considered. From RFC 4684: : An alternative solution to the procedure given above would have been : to source different routes per PE, such as NLRI of the form : {originator-id, route-target}, and to aggregate them at the edge of : the network. The solution adopted is considered advantageous over : the former in that it requires less routing-information within a : given AS. The aggregation procedures, however, would have been messy. The thought of doing community coloring to limit the RT distribution graph for specific AFI/SAFI has the same issue. While I think the idea is still worth considering, working through the implementation details for that have given me a nasty headache. -- Jeff From nobody Tue Jun 24 06:28:03 2014 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 EA9ED1B29C4 for ; Tue, 24 Jun 2014 06:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 UURsjsxzoZYW for ; Tue, 24 Jun 2014 06:28:00 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5C71B2935 for ; Tue, 24 Jun 2014 06:28:00 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2DE2EC22C; Tue, 24 Jun 2014 09:28:00 -0400 (EDT) Date: Tue, 24 Jun 2014 09:28:00 -0400 From: Jeffrey Haas To: "UTTARO, JAMES" Message-ID: <20140624132800.GX11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273369B6A5@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C816D@EX01.swan.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_VufAUoB2cvUrl_P0dW2-r78Gx4 Cc: "'idr@ietf.org'" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:28:02 -0000 Jim, On Mon, Jun 23, 2014 at 10:41:24PM +0000, UTTARO, JAMES wrote: > Adam, > > I am uncomfortable turning over route distribution to a protocol. IMO the risk for a L3VPN network with sites that are geographically spread does not warrant the gain. I would suggest the working group tee this up with the IRS2 team as a use case. > While certainly worth discussing on the i2rs list, I'm not 100% clear on what you think the proposal would be. If the general observation is around "discontiguous VPN islands", static provisioning (with API help from something like i2rs) is certainly one way to tackle that. But even so, I've been kicking around the idea that tools like RT-C (similar in form but not in exact detail) may be useful for helping to determine the shape of such islands. Presented somewhat abstractly, it'd be nice to keep large amounts of state outside of devices that don't need to carry it. Discovering the set of devices that must carry that state and building dynamic routing connectivity among them is interesting in an academic sense - but I suspect violates many principles that operators need for predictability in their networks. -- Jeff From nobody Tue Jun 24 07:22:07 2014 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 0BCE81B2A6F for ; Tue, 24 Jun 2014 07:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 Vy2gZDL_Q3Lu for ; Tue, 24 Jun 2014 07:22:04 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149BE1B2A26 for ; Tue, 24 Jun 2014 07:22:04 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id c8989a35.2b13c6e6a940.3124803.00-2475.8699383.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 24 Jun 2014 14:22:04 +0000 (UTC) X-MXL-Hash: 53a9898c75bc14e1-8d6254211f77479b06521da39d239ec170829394 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 1b889a35.0.3121918.00-2262.8691519.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 24 Jun 2014 14:18:32 +0000 (UTC) X-MXL-Hash: 53a988b86ed11798-03cea42393e7537f5cd43c32174ecbb1064fd8cb Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5OEIOJP009698; Tue, 24 Jun 2014 10:18:25 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5OEIGcO009557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2014 10:18:19 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 24 Jun 2014 14:18:02 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.4]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0174.001; Tue, 24 Jun 2014 10:18:02 -0400 From: "UTTARO, JAMES" To: "'Jeffrey Haas'" Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAEPJ1CAA6L2EIAAkJHAgAAtGcCAAJN+4IABOy0A///Ji8A= Date: Tue, 24 Jun 2014 14:18:01 +0000 Message-ID: References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273369B6A5@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C816D@EX01.swan.local> <20140624132800.GX11842@pfrc> In-Reply-To: <20140624132800.GX11842@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=LbmLHEji c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=BlBDPaJd33wA:10 a=ofMgfj31e3cA:10 a=lB4lNuC3LbQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=Tg0nUI2_AAAA:8 a=48vgC7mUAAAA:8 a=LMBGXmdseHn9okV] X-AnalysisOut: [n5PAA:9 a=CjuIK1q_8ugA:10 a=3ODoesluOjEA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/YOAYAuKvr26jnvImjIWfJ4Xj--Q Cc: "'idr@ietf.org'" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 14:22:06 -0000 Jeff, My thinking is that we have the routing state available in the topology an= d we can export that to a controller which can then determine the specific = distribution tree for a given VPN. I2RS can subsequently "program" the PEs = and/or RRs ( Don't really want to limit the route at the RRs ) accordingly.= Actually another approach could be looking at the import list of all of th= e VRFs and construct the distribution tree without looking at each path. Th= is may be simpler if we are only concerned with the state being sent to the= PEs.. Jim Uttaro -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Tuesday, June 24, 2014 9:28 AM To: UTTARO, JAMES Cc: 'Vitkovsk? Adam'; 'Dongjie (Jimmy)'; 'idr@ietf.org' Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarch= ical-rr-00.txt Jim, On Mon, Jun 23, 2014 at 10:41:24PM +0000, UTTARO, JAMES wrote: > Adam, >=20 > I am uncomfortable turning over route distribution to a protocol. IMO th= e risk for a L3VPN network with sites that are geographically spread does n= ot warrant the gain. I would suggest the working group tee this up with the= IRS2 team as a use case. >=20 While certainly worth discussing on the i2rs list, I'm not 100% clear on what you think the proposal would be. If the general observation is around "discontiguous VPN islands", static provisioning (with API help from something like i2rs) is certainly one way to tackle that. But even so, I've been kicking around the idea that tools like RT-C (similar in form but not in exact detail) may be useful for helping to determine the shape of such islands. Presented somewhat abstractly, it'd be nice to keep large amounts of state outside of devices that don't need to carry it. Discovering the set of devices that must carry that state and building dynamic routing connectivit= y among them is interesting in an academic sense - but I suspect violates man= y principles that operators need for predictability in their networks. -- Jeff From nobody Tue Jun 24 07:56:49 2014 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 BB39D1B2AEE for ; Tue, 24 Jun 2014 07:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 peltjYldT6U3 for ; Tue, 24 Jun 2014 07:56:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 77B6E1B2AC4 for ; Tue, 24 Jun 2014 07:56:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id EA5BDC22C; Tue, 24 Jun 2014 10:56:44 -0400 (EDT) Date: Tue, 24 Jun 2014 10:56:44 -0400 From: Jeffrey Haas To: "UTTARO, JAMES" Message-ID: <20140624145644.GD11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273369B6A5@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C816D@EX01.swan.local> <20140624132800.GX11842@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/c6QeLBiyd_Z6OjUrY259DgwLk7s Cc: "'idr@ietf.org'" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 14:56:47 -0000 Jim, On Tue, Jun 24, 2014 at 02:18:01PM +0000, UTTARO, JAMES wrote: > My thinking is that we have the routing state available in the topology and we can export that to a controller which can then determine the specific distribution tree for a given VPN. I2RS can subsequently "program" the PEs and/or RRs ( Don't really want to limit the route at the RRs ) accordingly. Actually another approach could be looking at the import list of all of the VRFs and construct the distribution tree without looking at each path. This may be simpler if we are only concerned with the state being sent to the PEs.. That work is definitely in-scope for I2RS. -- Jeff From nobody Tue Jun 24 12:46:37 2014 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 CA16B1A037D; Tue, 24 Jun 2014 12:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, 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 lAsORPfBcIFM; Tue, 24 Jun 2014 12:46:23 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16471A03C1; Tue, 24 Jun 2014 12:46:15 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5OJkDjZ024113; Tue, 24 Jun 2014 20:46:13 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5OJkAUT024083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 20:46:13 +0100 From: "Adrian Farrel" To: , Date: Tue, 24 Jun 2014 20:46:08 +0100 Message-ID: <035e01cf8fe4$f36212c0$da263840$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+P5NmxFjkJp+wQSeKwuhx3i4Ptdw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20778.000 X-TM-AS-Result: No--0.746-10.0-31-10 X-imss-scan-details: No--0.746-10.0-31-10 X-TMASE-MatchedRID: RZGtuGBMNjW2oWr/dU6+kB9NWUi6yjCBXArLpqs9pJctWyi3YZaESQji 0cLmTX9f+BY5Eio9E49aaVIsgpwFfl1YKGD2ztkY4EprSlQmFqB9LQinZ4QefL6qvLNjDYTwfyj BJDnutUhQSFbL1bvQASdET58jp62SkiEZtEMssv51kG6E/AtJXkZR7/RTlTYnTFwq2LzmPhjFQy 4iPkNYGwkCnkA3h/n1D701dfVAizuSL9OvtUca/e6+D482nHhrnqg/VrSZEiM= Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AADI7jhiDFb26wowXfpO3j7vumA Cc: "Eggert, Lars" , routing-discussion@ietf.org Subject: [Idr] Heads up interesting IRTF talk X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:46:29 -0000 There will be a talk describing a prize-winning piece of research in the IRTF Open Meeting in Toronto at 1420-1620 on Tuesday. > *** Robert Lychev *** for studying the security benefits provided by partially-deployed S*BGP: > > Robert Lychev, Sharon Goldberg and Michael Schapira. BGP > Security in Partial Deployment. Proc.ACM SIGCOMM, Hong Kong, > China, August 2013. Adrian From nobody Tue Jun 24 18:42:43 2014 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 667121B29CC for ; Tue, 24 Jun 2014 18:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 y_KezRZFGVcY for ; Tue, 24 Jun 2014 18:42:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A140C1B2A2F for ; Tue, 24 Jun 2014 18:42:39 -0700 (PDT) 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 BJE83502; Wed, 25 Jun 2014 01:42:38 +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.158.1; Wed, 25 Jun 2014 02:42:37 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 25 Jun 2014 09:42:34 +0800 From: "Dongjie (Jimmy)" To: Jeffrey Haas Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgACZ1UD//3vOgIAAChOAgAADtwCABRJ9gIAA/gQQgAA8kwCAAVR9MA== Date: Wed, 25 Jun 2014 01:42:34 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927336AF0D8@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <16107_1403265821_53A4231D_16107_10483_1_9E32478DFA9976438E7A22F69B08FF92022D80@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15043_1403268251_53A42C9B_15043_2147_1_9E32478DFA9976438E7A22F69B08FF92022DEA@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140623182457.GO11842@pfrc> <76CD132C3ADEF848BD84D028D243C927336A7B5E@nkgeml512-mbx.china.huawei.com> <20140624131054.GU11842@pfrc> In-Reply-To: <20140624131054.GU11842@pfrc> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/diVzbYrCHzZuQ2eQs_AAI9CkFv4 Cc: "idr@ietf.org" , Robert Raszuk Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 01:42:41 -0000 Jeff,=20 So let's work through it completely for valid network scenarios:) Best regards, Jie > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Tuesday, June 24, 2014 9:11 PM > To: Dongjie (Jimmy) > Cc: Jeffrey Haas; Robert Raszuk; idr@ietf.org > Subject: Re: [Idr] New Version Notification for > draft-dong-idr-rtc-hierarchical-rr-00.txt >=20 > Jie, >=20 > On Tue, Jun 24, 2014 at 01:59:43AM +0000, Dongjie (Jimmy) wrote: > > BTW, the existing RTC also modifies the route reflection semantics with= the > rules in section 3.2 of RFC 4684. >=20 > Arguably, incompletely working through the impacts of this are what got u= s into > this problem. :-) >=20 > -- Jeff From nobody Tue Jun 24 20:52:13 2014 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 EF5541B2AA8 for ; Tue, 24 Jun 2014 20:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 2B5P3icbRkqA for ; Tue, 24 Jun 2014 20:52:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BA41B2A97 for ; Tue, 24 Jun 2014 20:52:09 -0700 (PDT) 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 BJE91333; Wed, 25 Jun 2014 03:52:07 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Jun 2014 04:52:03 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 25 Jun 2014 11:51:58 +0800 From: Xuxiaohu To: Jeffrey Haas , Robert Raszuk Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//4fPgIAAGG8AgAKT/sD//7OAAIAAzkiAgAAIeoCAAAIlAIAABYEAgADnqBD//+A7gAAMtLCAAC0LHnA= Date: Wed, 25 Jun 2014 03:51:57 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828CC26@NKGEML512-MBS.china.huawei.com> References: <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <20140623182619.GP11842@pfrc> <20140623190420.GT11842@pfrc> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828C645@NKGEML512-MBS.china.huawei.com> <20140624132315.GW11842@pfrc> In-Reply-To: <20140624132315.GW11842@pfrc> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/4S1jHTUBNssf5r_4N034BBNPK7A Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 03:52:12 -0000 > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Tuesday, June 24, 2014 9:23 PM > To: Robert Raszuk > Cc: Xuxiaohu; Jeffrey Haas; idr@ietf.org > Subject: Re: [Idr] New Version Notification for > draft-dong-idr-rtc-hierarchical-rr-00.txt >=20 > On Tue, Jun 24, 2014 at 09:19:27AM +0200, Robert Raszuk wrote: > > IMO changing the format of RTC NLRI is the worst idea of all discussed > > so far on this thread. Sorry. > > > > It is not backwards compatible and will result in heavy deployment mess= . >=20 > Agreed. But the fun part is the original authors told us this had been > considered. From RFC 4684: >=20 > : An alternative solution to the procedure given above would have been > : to source different routes per PE, such as NLRI of the form > : {originator-id, route-target}, and to aggregate them at the edge of > : the network. The solution adopted is considered advantageous over > : the former in that it requires less routing-information within a > : given AS. If I understand the above text correctly, it seems that " aggregate them at= the edge of the network" just meant to aggregate them (i.e., from {origina= tor-id, route-target} to {origin AS, route-target}) when advertising them o= utside of the originating AS. > The aggregation procedures, however, would have been messy. The thought Compared to the aggregation procedure which is executed on eBGP sessions, t= he suppression procedure which would be executed on IBGP sessions is a real= headache. > of doing community coloring to limit the RT distribution graph for specif= ic > AFI/SAFI has the same issue. While I think the idea is still worth consi= dering, > working through the implementation details for that have given me a nasty > headache. How about making the suppression as an option? For example, if it is safe t= o enable the suppression in some topology(e.g., the hierarchical RR topolog= y ), then enable it. Otherwise (e.g., arbitrary meshes of RRs), disable it.= Compared to the current procedure which is based on the granularity of {o= rigin AS, route-target}, for those scenarios which could be dealt with by t= he current procedure (e.g., the hierarchical RR topology), the new procedur= e could deal with them at almost the same cost (i.e., no more routing-infor= mation by enabling the suppression). For those scenarios which could hardly= be dealt with by the current procedure (e.g., arbitrary meshes of RRs), th= e new procedure could deal with them as well just at a relatively higher co= st (i.e., by disabling the suppression), anyway, better than nothing. Best regards, Xiaohu > -- Jeff From nobody Thu Jun 26 14:50:12 2014 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 32DDF1B2F8E for ; Thu, 26 Jun 2014 14:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlI-Sr9E51DF for ; Thu, 26 Jun 2014 14:50:08 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CFB2D1B2F73 for ; Thu, 26 Jun 2014 14:50:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Thu, 26 Jun 2014 17:50:04 -0400 Message-ID: <00ea01cf9188$96f0d8a0$c4d289e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EB_01CF9167.0FE09830" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac+RiGZxIiUHrjs5QC2s69qqs6NU0w== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/W1qbDexaz4uOg-ql3Q-0dQv0tn4 Subject: [Idr] WG LC draft-ietf-idr-flowspec-redirect-rt-bis-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, 26 Jun 2014 21:50:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EB_01CF9167.0FE09830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is to begin a 2 week WG LC staring 6/26/14, and ending on 6/11/14 for the draft: draft-ietf-idr-flowspec-redirect-rt-bis. http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ Please indicate in your comments: Support yes/no. Thank you, Sue and John ------=_NextPart_000_00EB_01CF9167.0FE09830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to = begin a 2 week WG LC staring 6/26/14, and ending on 6/11/14 for the = draft:

draft-ietf-idr-flowspec-redirect-rt-bis.

=

 

http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect= -rt-bis/

 

Please indicate in your comments: Support yes/no. =

 

Thank you,

 

Sue and John =  

------=_NextPart_000_00EB_01CF9167.0FE09830-- From nobody Thu Jun 26 22:24:40 2014 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 60ABD1B315B for ; Thu, 26 Jun 2014 22:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 QiqkFcTuo-HH for ; Thu, 26 Jun 2014 22:24:36 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84CEF1B315A for ; Thu, 26 Jun 2014 22:24:36 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s5R5OXtn022933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Jun 2014 00:24:35 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s5R5OWXA031330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 07:24:33 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 27 Jun 2014 07:24:32 +0200 From: "Henderickx, Wim (Wim)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC draft-ietf-idr-flowspec-redirect-rt-bis-00 Thread-Index: Ac+RiGZxIiUHrjs5QC2s69qqs6NU0wAP6gQA Date: Fri, 27 Jun 2014 05:24:31 +0000 Message-ID: References: <00ea01cf9188$96f0d8a0$c4d289e0$@ndzh.com> In-Reply-To: <00ea01cf9188$96f0d8a0$c4d289e0$@ndzh.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_CFD2CC9FDAB05wimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/TXbgttY-aiztKcq0jxkzGjrRgec Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-redirect-rt-bis-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, 27 Jun 2014 05:24:38 -0000 --_000_CFD2CC9FDAB05wimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable support From: Susan Hares > Date: Thursday 26 June 2014 15:50 To: idr wg > Subject: [Idr] WG LC draft-ietf-idr-flowspec-redirect-rt-bis-00 This is to begin a 2 week WG LC staring 6/26/14, and ending on 6/11/14 for = the draft: draft-ietf-idr-flowspec-redirect-rt-bis. http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ Please indicate in your comments: Support yes/no. Thank you, Sue and John --_000_CFD2CC9FDAB05wimhenderickxalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4C2525E6C4B05F419A1CA87A065ED4D8@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
support

From: Susan Hares <shares@ndzh.com>
Date: Thursday 26 June 2014 15:50 To: idr wg <idr@ietf.org>
Subject: [Idr] WG LC draft-ietf-idr= -flowspec-redirect-rt-bis-00

This is to begin a 2 week WG LC staring 6/26/14, and= ending on 6/11/14 for the draft:

draft-ietf-idr-flowspec-redirect-rt-bis.<= /p>

 

http://datatracker.ietf.org/doc/draft-ietf= -idr-flowspec-redirect-rt-bis/

 

Please indicate in your comments: Support yes/no.

 

Thank you,

 

Sue and John  

 --_000_CFD2CC9FDAB05wimhenderickxalcatellucentcom_-- From nobody Fri Jun 27 00:47:02 2014 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 EB15C1B3179 for ; Fri, 27 Jun 2014 00:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3UI-ynCapx-U for ; Fri, 27 Jun 2014 00:46:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C56B1B3173 for ; Fri, 27 Jun 2014 00:46:57 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5F54D3241B1; Fri, 27 Jun 2014 09:46:55 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3D12B27C098; Fri, 27 Jun 2014 09:46:55 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.110]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Fri, 27 Jun 2014 09:46:55 +0200 From: To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC draft-ietf-idr-flowspec-redirect-rt-bis-00 Thread-Index: Ac+RiGZxIiUHrjs5QC2s69qqs6NU0wAU4zAQ Date: Fri, 27 Jun 2014 07:46:54 +0000 Message-ID: <716_1403855215_53AD216F_716_62_1_9E32478DFA9976438E7A22F69B08FF9203459D@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <00ea01cf9188$96f0d8a0$c4d289e0$@ndzh.com> In-Reply-To: <00ea01cf9188$96f0d8a0$c4d289e0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF9203459DOPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.100319 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AWAKqBrQX-ABB7GYD-s6YWin0nE Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-redirect-rt-bis-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, 27 Jun 2014 07:47:00 -0000 --_000_9E32478DFA9976438E7A22F69B08FF9203459DOPEXCLILM34corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, June 26, 2014 23:50 To: idr wg Subject: [Idr] WG LC draft-ietf-idr-flowspec-redirect-rt-bis-00 This is to begin a 2 week WG LC staring 6/26/14, and ending on 6/11/14 for = the draft: draft-ietf-idr-flowspec-redirect-rt-bis. http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ Please indicate in your comments: Support yes/no. Thank you, Sue and John ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF9203459DOPEXCLILM34corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, June 26, 2014 23:50
To: idr wg
Subject: [Idr] WG LC draft-ietf-idr-flowspec-redirect-rt-bis-00=

 

This is to begin a 2 week WG LC staring 6/26/14, and= ending on 6/11/14 for the draft:

draft-ietf-idr-flowspec-redirect-rt-bis.<= /p>

 

http://datatracker.ietf.org/doc/draft-ietf= -idr-flowspec-redirect-rt-bis/

 

Please indicate in your comments: Support yes/no.

 

Thank you,

 

Sue and John  

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF9203459DOPEXCLILM34corpor_-- From nobody Fri Jun 27 04:52:51 2014 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 D60331B3179 for ; Fri, 27 Jun 2014 04:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hA18VlK2onf5 for ; Fri, 27 Jun 2014 04:52:43 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F801B3180 for ; Fri, 27 Jun 2014 04:52:41 -0700 (PDT) From: =?utf-8?B?Vml0a292c2vDvSBBZGFt?= To: "Dongjie (Jimmy)" , Robert Raszuk Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//+xkgIAAOCmwgAHzEgCABv+DcA== Date: Fri, 27 Jun 2014 11:52:33 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.44.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/mizHigTC2ygniZ6NC29wFmJXNNc Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 11:52:46 -0000 SGkgZm9sa3MsDQoNClJlZ2FyZGluZyB0aGUgcnVsZSAzLjIuaSBvZiBSRkM0Njg0LiANCg0KRmly c3QgY29uc2lkZXIgc2NlbmFyaW8gYSk6DQphKQ0KUlItLS0tUEUxDQoNCldoeSB3b3VsZCBJIHdh bnQgdGhlIFJSIHRvIGxlYXJuIHRoZSBQRSdzIHByZWZpeGVzIGlmIHRoZXJlJ3Mgbm8gb25lIGlu dGVyZXN0ZWQgaW4gdGhlbSAobm8gb3RoZXIgY2xpZW50cyBpbnRlcmVzdGVkIHRvIHJlY2VpdmUg TlJMSSBmb3IgZ2l2ZW4gUlRzKSBhcyBQRTEgaXMgdGhlIG9ubHkgb25lIHRoYXQgYWR2ZXJ0aXNl ZCB0aGUgUm91dGUgVGFyZ2V0IG1lbWJlcnNoaXAgaW5mb3JtYXRpb24gdG8gUlIuIA0KDQpOb3cg bGV0J3MgY29uc2lkZXIgc2NlbmFyaW8gYik6DQpiKQ0KUEUyLS0tLVJSLS0tLVBFMQ0KDQpOb3cg dGhlcmUgaXMgYW5vdGhlciBjbGllbnQgKFBFMikgY29ubmVjdGVkIHRvIHRoZSBSUiBhbmQgaXQg aGFwcGVucyB0byBiZSBpbnRlcmVzdGVkIGluIHJlY2VpdmluZyBOUkxJIGZvciBhIGdpdmVuIFJU IGFzIGRlc2lnbmF0ZWQgYnkgdGhlIGFkdmVydGlzZWQgUm91dGUgVGFyZ2V0IG1lbWJlcnNoaXAg aW5mb3JtYXRpb24gZm9yIHRoZSBnaXZlbiBSVC4gDQpPayBub3cgdGhhdCB0aGVyZSBhcmUgaW50 ZXJlc3RlZCByZWNlaXZlcnMgZm9yIGEgZ2l2ZW4gTlJMSSBvbiBib3RoIHNlc3Npb25zIC0gUlIg c2hvdWxkIHN0YXJ0IGxlYXJuaW5nIHRoZSBOUkxJcyBmcm9tIGNsaWVudHMgc28gdGhhdCBpdCBj YW4gZGlzc2VtaW5hdGUgdGhlIGluZm9ybWF0aW9uIGFjY29yZGluZ2x5LiANCg0KSW4gb3JkZXIg dG8gc3RhcnQgbGVhcm5pbmcgdGhlIE5STElzIFJSIGhhcyB0byBhZHZlcnRpc2UgYSBkZXNpcmUg dG8gcmVjZWl2ZSB0aGVtIGFuZCB0byBkbyB0aGF0IHdlIGNhbiB1c2UgbW9kaWZpZWQgcnVsZSAz LjIuaWkuDQoNCiAgICAgICAgV2hlbiBhZHZlcnRpc2luZyBhbiBSVCBtZW1iZXJzaGlwIE5MUkkg dG8gYSBjbGllbnQgcGVlciwgaWYNCiAgICAgICAgdGhlIGJlc3QgcGF0aCBhcyBzZWxlY3RlZCBi eSB0aGUgcGF0aCBzZWxlY3Rpb24gcHJvY2VkdXJlDQogICAgICAgIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDkuMSBvZiB0aGUgYmFzZSBCR1Agc3BlY2lmaWNhdGlvbiBbNF0gaXMgYQ0KICAgICAgICBy b3V0ZSByZWNlaXZlZCBmcm9tIHRoYXQgY2xpZW50IHBlZXIgaW4gcGFydGljdWxhciwgYW5kIGlm IHRoZXJlIGlzIGFuDQogICAgICAgIGFsdGVybmF0aXZlIHBhdGggdG8gdGhlIHNhbWUgZGVzdGlu YXRpb24gZnJvbSBhbm90aGVyIGNsaWVudCBvciBhIG5vbi1jbGllbnQsIHRoZQ0KICAgICAgICBh dHRyaWJ1dGVzIG9mIHRoZSBvdGhlciBwYXRoIGFyZSBhZHZlcnRpc2VkIHRvIHRoZSBwZWVyLiAN Cg0KTm93IHRoaW5raW5nIGFib3V0IGl0IG9ubHkgb25lIHJ1bGUgZm9yIHJlZmxlY3Rpb24gb2Yg UlQgbWVtYmVyc2hpcCBOTFJJIGlzIGVub3VnaCBJIGd1ZXNzLiANCklmIHlvdSByZWNlaXZlZCBS VCBtZW1iZXJzaGlwIE5MUkkgZnJvbSBvbmx5IG9uZSBwZWVyIGRvbid0IGFkdmVydGlzZSBpdCB1 bnRpbCB5b3UgaGF2ZSByZWNlaXZlZCB0aGUgUlQgbWVtYmVyc2hpcCBOTFJJIHdpdGggdGhlIHNh bWUgUlQgZnJvbSBhbm90aGVyIHBlZXIuIA0KVGhlbiB5b3UgY2FuIGFkdmVydGlzZSB0aGUgYWx0 ZXJuYXRlIChub3QgdGhlIG9uZSB0aGF0IHRoZSBwZWVyIHNlbnQgeW91KSBSVCBtZW1iZXJzaGlw IE5MUkkgdG8gYSBnaXZlbiBwZWVyIChzaW1wbGUgc3BsaXQgaG9yaXpvbikuIA0KDQpUaGVuIHRo ZXJlJ3Mgbm8gbmVlZCB0byBtb2RpZnkgdGhlIHVwZGF0ZSBzbyB0aGF0IGl0IGNhbiBiZSBhY2Nl cHRlZCBieSB0aGUgb3JpZ2luYXRvciAoYXMgaW4gMy4yLmkuKS4gDQpBbmQgdGhpcyBhbHNvIHNv bHZlcyB0aGUgaGllcmFyY2hpY2FsIFJSIHByb2JsZW0gYXMgd2VsbC4gDQoNCg0KSSdkIGxpa2Ug dGhlIHRoaW5rIG9mIGl0IGFzIHdpdGggbXVsdGljYXN0IGZsb3cgd2hlcmUgUlIgaXMgbGlrZSBS UCBhbmQgUEVzIGFyZSBsaWtlIFNvdXJjZXMgKyBSZWNlaXZlcnMuIA0KVGhlcmUncyBubyBuZWVk IGZvciB0aGUgUlAgKFJSKSB0byByZWNlaXZlIHRoZSBtY2FzdCBzdHJlYW0gKGUuZy4gVlBOIFBy ZWZpeGVzKSB3aGVuIHRoZXJlJ3MganVzdCBvbmUgU291cmNlL1JlY2VpdmVyIChQRSkgY29ubmVj dGVkIHRvIGl0LiANCkEgc2ltcGxlIHN0YXRlIG9uIHRoZSBSUCBzYXlpbmcgdGhlcmUgaXMgYSBw YXJ0aWN1bGFyIHN0cmVhbSBhdmFpbGFibGUgYXQgdGhpcyBwYXJ0aWN1bGFyIHNvdXJjZSBpcyBl bm91Z2ggKGkuZS4gUlQgbWVtYmVyc2hpcCBOTFJJIG9uIFJSKS4gDQpPbmNlIG90aGVyIHNvdXJj ZS9yZWNlaXZlcnMgKFBFcykgYXJlIGNvbm5lY3RlZCB0byB0aGUgUlAoUlIpIGFuZCBzaWduYWwg dGhlaXIgZGVzaXJlIHRvIHJlY2VpdmUgdGhlIHN0cmVhbSAodmlhIFJUIG1lbWJlcnNoaXAgTkxS SSkuIA0KVGhlbiBSUCAoUlIpIGRlY2lkZXMgdGhlIGRlc2lyZSByZWNlaXZlIHRoZSBzdHJlYW0g KFJUIG1lbWJlcnNoaXAgTkxSSSkgaXMgd29ydGggc3ByZWFkaW5nIGFuZCBkaXNzZW1pbmF0ZXMg dGhlIGluZm9ybWF0aW9uIHRvIHRoZSBpbnRlcmVzdGVkIHNvdXJjZXMvcmVjZWl2ZXJzIChQRXMp LiANCk9uY2UgdGhhdCBoYXBwZW5zIHNvdXJjZXMvcmVjZWl2ZXJzIChQRXMpIHdpbGwgc3RhcnQg c2VuZGluZyB0aGUgbWNhc3Qgc3RyZWFtIChlLmcuIFZQTiBQcmVmaXhlcykgdG93YXJkcyB0aGUg UlAgKFJSKSB3aGljaCB0aGFuIHJlZmxlY3RzIHRoaXMgbWNhc2Ugc3RyZWFtcyB0byBhbGwgaW50 ZXJlc3RlZCBzb3VyY2VzL3JlY2VpdmVycyAoUEVzKS4gDQoNCg0KSSBiZWxpZXZlIHRoZSBjb25j ZXJucyBwcmVzZW50ZWQgaW4gZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMCBj b3VsZCBiZSByZXNvbHZlZCBieSBhZGQtcGF0aCB3aGVyZSBhdCBsZWFzdCBvbmUgYWRkaXRpb25h bCBwYXRoIGlzIGFkdmVydGlzZWQgYWxvbmcgd2l0aCB0aGUgYmVzdC1wYXRoLiANCkJ1dCBzdGls bCBydWxlIDMuMi5pLiBpbiBSRkM0Njg0IGlzIHZlcnkgaGFybWZ1bCBpbiBzY2VuYXJpb3Mgd2hl cmUgUlJzIGFyZSBjbGllbnRzIG9mIG90aGVyIFJScyAoc2FtZSBsZXZlbCBvciBkaWZmZXJlbnQg bGV2ZWwpLiANCg0KDQoNCiBhZGFtDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBEb25namllIChKaW1teSkgW21haWx0bzpqaWUuZG9uZ0BodWF3ZWkuY29tXQ0KPiBT ZW50OiBNb25kYXksIEp1bmUgMjMsIDIwMTQgNDo1OSBBTQ0KPiBUbzogVml0a292c2vDvSBBZGFt OyBSb2JlcnQgUmFzenVrDQo+IENjOiBpZHJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtJZHJd IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNo aWNhbC0NCj4gcnItMDAudHh0DQo+IA0KPiBIaSBBZGFtLA0KPiANCj4gSWYgUkQgaXMgcGFydCBv ZiB0aGUgUlRDIHJvdXRlcywgdGhpcyBwcm9ibGVtIHdpbGwgbm90IG9jY3VyOikgV2hpbGUgYXMg YW5hbHl6ZWQNCj4gaW4gcmZjIDQ2ODQsIHRoaXMgcmVxdWlyZXMgbW9yZSBSVEMgcm91dGVzIGJl aW5nIGV4Y2hhbmdlZCBhbmQga2VwdCBpbiB0aGUNCj4gbG9jYWwgQVMuDQo+IA0KPiBJIGFncmVl IHRoYXQgYWRkLXBhdGggaXMgYSBjYW5kaWRhdGUgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtLCB3 aGlsZSB3aGVuDQo+IGVuYWJsaW5nIGFkZC1wYXRoIG9uIFJUQyBBRkkvU0FGSSwgd2Ugc3RpbGwg bmVlZCB0byBzcGVjaWZ5IHRoZSBydWxlcyBvZiB3aGljaA0KPiBSVEMgcm91dGVzIHNob3VsZCBi ZSBhZHZlcnRpc2VkIHRvIHNvbHZlIHRoaXMgcHJvYmxlbS4gT3Igd2UganVzdCB1cGRhdGUgdGhl DQo+IHJ1bGVzIG9mIFJUQyBhZHZlcnRpc2VtZW50IGFzIHRoZSBvdGhlciBSVEMgcmVsYXRlZCBu ZXcgZHJhZnRzPw0KPiANCj4gTWFueSB0aGFua3MsDQo+IEppZQ0KPiANCj4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFZpdGtvdnNrw70gQWRhbSBbbWFpbHRvOmFkYW0u dml0a292c2t5QHN3YW4uc2tdDQo+ID4gU2VudDogU3VuZGF5LCBKdW5lIDIyLCAyMDE0IDM6MjAg QU0NCj4gPiBUbzogUm9iZXJ0IFJhc3p1aw0KPiA+IENjOiBEb25namllIChKaW1teSk7IGlkckBp ZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBbSWRyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yDQo+ID4gZHJhZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMC50eHQNCj4gPg0K PiA+IEFhaCBJIHNlZSA6KQ0KPiA+IFdlbGwgd2UgY291bGQgaGF2ZSB0aGF0IG9uZSBzb2x2ZWQg aWYgUkQgd291bGQgYmUgcGFydCBvZiB0aGUgUlRDDQo+ID4gcm91dGVzIDopICh0aG91Z2ggSSB1 bmRlcnN0YW5kIG9uZSBjb3VsZCB1c2UgUlRDIGZvciBub24gVlBOIHJvdXRlcyBhcw0KPiA+IHdl bGwgc28uLi4pIEFueXdheXMgc28gdGhhbiBhcyB5b3UgbWVudGlvbmVkIGFkZC1wYXRoIG9uIHRo ZSBSVEMgQUYNCj4gPiBzZWVtcyBhcyB0aGUgYmVzdCBvcHRpb24gdGhlbi4NCj4gPg0KPiA+IGFk YW0NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBycmFzenVr QGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YNCj4gPiA+ IFJvYmVydCBSYXN6dWsNCj4gPiA+IFNlbnQ6IFNhdHVyZGF5LCBKdW5lIDIxLCAyMDE0IDc6NTIg UE0NCj4gPiA+IFRvOiBWaXRrb3Zza8O9IEFkYW0NCj4gPiA+IENjOiBEb25namllIChKaW1teSk7 IGlkckBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtJZHJdIE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3INCj4gPiA+IGRyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtIHJyLTAw LnR4dA0KPiA+ID4NCj4gPiA+IEhpIEFkYW0sDQo+ID4gPg0KPiA+ID4gSmllIGlzIGRlc2NyaWJp bmcgUlQgcm91dGVzIG5vdCBWUE4gcm91dGVzLiBZb3VyIHN0b3J5IGRvZXMgbm90DQo+ID4gPiBh cHBseSB0byBSVCByb3V0ZXMgYXMgZm9ybWF0IG9mIFJUIE5MUkkgaXMgd2VsbCBkZWZpbmVkIGJ5 IFJGQyA7KQ0KPiA+ID4NCj4gPiA+IEJlc2lkZXMgTVBMUyBuZXR3b3JrIG9yIG5vdCBoYXMgbm90 aGluZyB0byBkbyB3aXRoIGl0IC4uLi4NCj4gPiA+DQo+ID4gPiBCZXN0LA0KPiA+ID4gUi4NCj4g PiA+DQo+ID4gPiBPbiBTYXQsIEp1biAyMSwgMjAxNCBhdCA3OjE5IFBNLCBWaXRrb3Zza8O9IEFk YW0NCj4gPiA+IDxhZGFtLnZpdGtvdnNreUBzd2FuLnNrPg0KPiA+ID4gd3JvdGU6DQo+ID4gPiA+ IEhpIEppZSwNCj4gPiA+ID4gV2VsbCB0aGUgY29ycmVjdGx5IGRlc2lnbmVkIE1QTFMgbmV0d29y a3MgdXNlIHVuaXF1ZSBwZXIgUEUgcGVyDQo+ID4gPiA+IFZSRiBSRHMNCj4gPiA+IGluIGZvcm0g b2YgUklEOnh4eHh4Lg0KPiA+ID4gPiBVbmlxdWUgcGVyIFBFIFJEcyBtYWtlcyBhbGwgY29waWVz IG9mIHRoZSBzYW1lIFZQTiBwcmVmaXggcmVjZWl2ZWQNCj4gPiA+ID4gZnJvbQ0KPiA+ID4gZGlm ZmVyZW50IFBFcyB1bmlxdWUgc28gUlJzIHdpbGwgc2VsZWN0IGFsbCBhcyBiZXN0IHBhdGggYW5k DQo+ID4gPiBkaXN0cmlidXRlIHRoZW0gYWNjb3JkaW5nbHksIHdoaWNoIHNvbHZlcyB0aGlzIGFu ZCBtYW55IG90aGVyIGlzc3Vlcy4NCj4gPiA+ID4NCj4gPiA+ID4gSW4gb3RoZXIgd29yZHMgaWYg c29tZW9uZSB0cmllcyB0byBzaG9vdCBoaW1zZWxmIGluIHRoZSBmb290IEkNCj4gPiA+ID4gd291 bGRuJ3QNCj4gPiA+IGRldmVsb3AgYnVsbGV0cHJvb2YgYm9vdHMgZm9yIGhpbS4NCj4gPiA+ID4N Cj4gPiA+ID4gYWRhbQ0KPiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ ID4+IEZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RG9uZ2ppZQ0KPiA+ID4gPj4gKEppbW15KQ0KPiA+ID4gPj4gU2VudDogRnJpZGF5LCBKdW5lIDIw LCAyMDE0IDQ6NTUgQU0NCj4gPiA+ID4+IFRvOiBpZHJAaWV0Zi5vcmcNCj4gPiA+ID4+IFN1Ympl Y3Q6IFtJZHJdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gPiA+PiBkcmFm dC1kb25nLWlkci1ydGMtIGhpZXJhcmNoaWNhbC1yci0wMC50eHQNCj4gPiA+ID4+DQo+ID4gPiA+ PiBIaSBhbGwsDQo+ID4gPiA+Pg0KPiA+ID4gPj4gVGhpcyBpcyBhIHNob3J0IGRyYWZ0IHRvIG1h a2UgUlRDIGFwcGxpY2FibGUgaW4gaGllcmFyY2hpY2FsIFJSIHNjZW5hcmlvLg0KPiA+ID4gPj4N Cj4gPiA+ID4+IENvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPiA+ID4gPj4NCj4gPiA+ID4+IEJlc3Qg cmVnYXJkcywNCj4gPiA+ID4+IEppZQ0KPiA+ID4gPj4NCj4gPiA+ID4+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4gQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAudHh0DQo+ID4gPiA+PiA+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmllIERvbmcgYW5kIHBvc3RlZCB0 byB0aGUNCj4gPiA+ID4+ID4gSUVURg0KPiA+ID4gPj4gcmVwb3NpdG9yeS4NCj4gPiA+ID4+ID4N Cj4gPiA+ID4+ID4gTmFtZTogICAgICAgICAgICAgICBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFy Y2hpY2FsLXJyDQo+ID4gPiA+PiA+IFJldmlzaW9uOiAgIDAwDQo+ID4gPiA+PiA+IFRpdGxlOiAg ICAgICAgICAgICAgRXh0ZW5zaW9ucyB0byBSVC1Db25zdHJhaW4gaW4gSGllcmFyY2hpY2FsIFJv dXRlDQo+ID4gUmVmbGVjdGlvbg0KPiA+ID4gPj4gPiBTY2VuYXJpb3MNCj4gPiA+ID4+ID4gRG9j dW1lbnQgZGF0ZTogICAgICAyMDE0LTA2LTE5DQo+ID4gPiA+PiA+IEdyb3VwOiAgICAgICAgICAg ICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gPiA+PiA+IFBhZ2VzOiAgICAgICAgICAgICAg NQ0KPiA+ID4gPj4gPiBVUkw6DQo+ID4gPiA+PiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaA0KPiA+ID4gPj4gPiBpYw0KPiA+ ID4gPj4gPiBhbA0KPiA+ID4gPj4gPiAtcnINCj4gPiA+ID4+ID4gLTAwLnR4dA0KPiA+ID4gPj4g PiBTdGF0dXM6DQo+ID4gPiA+PiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYQ0KPiA+ID4gPj4gPiBsLQ0KPiA+ID4gPj4gPiBy cg0KPiA+ID4gPj4gPiAvDQo+ID4gPiA+PiA+IEh0bWxpemVkOg0KPiA+ID4gPj4gPiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTAN Cj4gPiA+ID4+ID4gMA0KPiA+ID4gPj4gPg0KPiA+ID4gPj4gPg0KPiA+ID4gPj4gPiBBYnN0cmFj dDoNCj4gPiA+ID4+ID4gICAgVGhlIFJvdXRlIFRhcmdldCAoUlQpIENvbnN0cmFpbiBtZWNoYW5p c20gc3BlY2lmaWVkIGluIFJGQyA0Njg0IGlzDQo+ID4gPiA+PiA+ICAgIHVzZWQgdG8gYnVpbGQg YSByb3V0ZSBkaXN0cmlidXRpb24gZ3JhcGggaW4gb3JkZXIgdG8gcmVzdHJpY3QgdGhlDQo+ID4g PiA+PiA+ICAgIHByb3BhZ2F0aW9uIG9mIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrIChWUE4pIHJv dXRlcy4gIEluIG5ldHdvcmsNCj4gPiA+ID4+ID4gICAgc2NlbmFyaW9zIHdoZXJlIGhpZXJhcmNo aWNhbCByb3V0ZSByZWZsZWN0aW9uIChSUikgaXMgdXNlZCwgdGhlDQo+ID4gPiA+PiA+ICAgIGV4 aXN0aW5nIFJULUNvbnN0cmFpbiBtZWNoYW5pc20gY2Fubm90IGJ1aWxkIGEgY29ycmVjdCByb3V0 ZQ0KPiA+ID4gPj4gPiAgICBkaXN0cmlidXRpb24gZ3JhcGguICBUaGlzIGRvY3VtZW50IHJlZmlu ZXMgdGhlIHJvdXRlIGRpc3RyaWJ1dGlvbg0KPiA+ID4gPj4gPiAgICBydWxlcyBvZiBSVC1Db25z dHJhaW4gdG8gYWRkcmVzcyB0aGUgaGllcmFyY2hpY2FsIFJSIHNjZW5hcmlvcy4NCj4gPiA+ID4+ ID4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4NCj4gPiA+ ID4+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUNCj4gPiA+ID4+ID4gb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlDQo+ID4gPiA+PiA+IGF0DQo+ID4gPiB0b29s cy5pZXRmLm9yZy4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQN Cj4gPiA+ID4+DQo+ID4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+ID4gPj4gSWRyIG1haWxpbmcgbGlzdA0KPiA+ID4gPj4gSWRyQGlldGYu b3JnDQo+ID4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K PiA+ID4gPg0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+ID4gPiBJZHIgbWFpbGluZyBsaXN0DQo+ID4gPiA+IElkckBpZXRmLm9yZw0K PiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Fri Jun 27 18:49:13 2014 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 887181A0260 for ; Fri, 27 Jun 2014 18:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 WFbhnn5eJ_vZ for ; Fri, 27 Jun 2014 18:49:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676B51A025E for ; Fri, 27 Jun 2014 18:49:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJI71505; Sat, 28 Jun 2014 01:49:06 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 28 Jun 2014 02:49:05 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Sat, 28 Jun 2014 09:48:59 +0800 From: "Dongjie (Jimmy)" To: =?utf-8?B?Vml0a292c2vDvSBBZGFt?= , Robert Raszuk Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//4fPgIAAGG8AgAKT/sCABl0XgIABZG1g Date: Sat, 28 Jun 2014 01:48:58 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927336B72F7@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HqLLNO5arhEWMWbIl6buSQ_M-Ek Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 01:49:11 -0000 SGkgQWRhbSwNCg0KVGhhbmtzIGZvciB5b3VyIGFuYWx5c2lzLCBhbmQgcGxlYXNlIHNlZSBteSBy ZXBsaWVzIGlubGluZToNCg0KPiBSZWdhcmRpbmcgdGhlIHJ1bGUgMy4yLmkgb2YgUkZDNDY4NC4N Cj4gDQo+IEZpcnN0IGNvbnNpZGVyIHNjZW5hcmlvIGEpOg0KPiBhKQ0KPiBSUi0tLS1QRTENCj4g DQo+IFdoeSB3b3VsZCBJIHdhbnQgdGhlIFJSIHRvIGxlYXJuIHRoZSBQRSdzIHByZWZpeGVzIGlm IHRoZXJlJ3Mgbm8gb25lIGludGVyZXN0ZWQNCj4gaW4gdGhlbSAobm8gb3RoZXIgY2xpZW50cyBp bnRlcmVzdGVkIHRvIHJlY2VpdmUgTlJMSSBmb3IgZ2l2ZW4gUlRzKSBhcyBQRTEgaXMgdGhlDQo+ IG9ubHkgb25lIHRoYXQgYWR2ZXJ0aXNlZCB0aGUgUm91dGUgVGFyZ2V0IG1lbWJlcnNoaXAgaW5m b3JtYXRpb24gdG8gUlIuDQoNCkFncmVlIHRoYXQgaW4gdGhpcyBjYXNlIFJSIGRvZXMgbm90IG5l ZWQgdG8gYWR2ZXJ0aXNlIFJUIG1lbWJlcnNoaXAgaW5mbyB0byBQRTEuIA0KDQo+IE5vdyBsZXQn cyBjb25zaWRlciBzY2VuYXJpbyBiKToNCj4gYikNCj4gUEUyLS0tLVJSLS0tLVBFMQ0KPiANCj4g Tm93IHRoZXJlIGlzIGFub3RoZXIgY2xpZW50IChQRTIpIGNvbm5lY3RlZCB0byB0aGUgUlIgYW5k IGl0IGhhcHBlbnMgdG8gYmUNCj4gaW50ZXJlc3RlZCBpbiByZWNlaXZpbmcgTlJMSSBmb3IgYSBn aXZlbiBSVCBhcyBkZXNpZ25hdGVkIGJ5IHRoZSBhZHZlcnRpc2VkDQo+IFJvdXRlIFRhcmdldCBt ZW1iZXJzaGlwIGluZm9ybWF0aW9uIGZvciB0aGUgZ2l2ZW4gUlQuDQo+IE9rIG5vdyB0aGF0IHRo ZXJlIGFyZSBpbnRlcmVzdGVkIHJlY2VpdmVycyBmb3IgYSBnaXZlbiBOUkxJIG9uIGJvdGggc2Vz c2lvbnMgLQ0KPiBSUiBzaG91bGQgc3RhcnQgbGVhcm5pbmcgdGhlIE5STElzIGZyb20gY2xpZW50 cyBzbyB0aGF0IGl0IGNhbiBkaXNzZW1pbmF0ZSB0aGUNCj4gaW5mb3JtYXRpb24gYWNjb3JkaW5n bHkuDQo+IA0KPiBJbiBvcmRlciB0byBzdGFydCBsZWFybmluZyB0aGUgTlJMSXMgUlIgaGFzIHRv IGFkdmVydGlzZSBhIGRlc2lyZSB0byByZWNlaXZlIHRoZW0NCj4gYW5kIHRvIGRvIHRoYXQgd2Ug Y2FuIHVzZSBtb2RpZmllZCBydWxlIDMuMi5paS4NCj4gDQo+ICAgICAgICAgV2hlbiBhZHZlcnRp c2luZyBhbiBSVCBtZW1iZXJzaGlwIE5MUkkgdG8gYSBjbGllbnQgcGVlciwgaWYNCj4gICAgICAg ICB0aGUgYmVzdCBwYXRoIGFzIHNlbGVjdGVkIGJ5IHRoZSBwYXRoIHNlbGVjdGlvbiBwcm9jZWR1 cmUNCj4gICAgICAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiA5LjEgb2YgdGhlIGJhc2UgQkdQIHNw ZWNpZmljYXRpb24gWzRdIGlzIGENCj4gICAgICAgICByb3V0ZSByZWNlaXZlZCBmcm9tIHRoYXQg Y2xpZW50IHBlZXIgaW4gcGFydGljdWxhciwgYW5kIGlmIHRoZXJlIGlzIGFuDQo+ICAgICAgICAg YWx0ZXJuYXRpdmUgcGF0aCB0byB0aGUgc2FtZSBkZXN0aW5hdGlvbiBmcm9tIGFub3RoZXIgY2xp ZW50IG9yIGENCj4gbm9uLWNsaWVudCwgdGhlDQo+ICAgICAgICAgYXR0cmlidXRlcyBvZiB0aGUg b3RoZXIgcGF0aCBhcmUgYWR2ZXJ0aXNlZCB0byB0aGUgcGVlci4NCj4gDQo+IE5vdyB0aGlua2lu ZyBhYm91dCBpdCBvbmx5IG9uZSBydWxlIGZvciByZWZsZWN0aW9uIG9mIFJUIG1lbWJlcnNoaXAg TkxSSSBpcw0KPiBlbm91Z2ggSSBndWVzcy4NCj4gSWYgeW91IHJlY2VpdmVkIFJUIG1lbWJlcnNo aXAgTkxSSSBmcm9tIG9ubHkgb25lIHBlZXIgZG9uJ3QgYWR2ZXJ0aXNlIGl0IHVudGlsDQo+IHlv dSBoYXZlIHJlY2VpdmVkIHRoZSBSVCBtZW1iZXJzaGlwIE5MUkkgd2l0aCB0aGUgc2FtZSBSVCBm cm9tIGFub3RoZXINCj4gcGVlci4NCj4gVGhlbiB5b3UgY2FuIGFkdmVydGlzZSB0aGUgYWx0ZXJu YXRlIChub3QgdGhlIG9uZSB0aGF0IHRoZSBwZWVyIHNlbnQgeW91KSBSVA0KPiBtZW1iZXJzaGlw IE5MUkkgdG8gYSBnaXZlbiBwZWVyIChzaW1wbGUgc3BsaXQgaG9yaXpvbikuDQoNCj4gVGhlbiB0 aGVyZSdzIG5vIG5lZWQgdG8gbW9kaWZ5IHRoZSB1cGRhdGUgc28gdGhhdCBpdCBjYW4gYmUgYWNj ZXB0ZWQgYnkgdGhlDQo+IG9yaWdpbmF0b3IgKGFzIGluIDMuMi5pLikuDQo+IEFuZCB0aGlzIGFs c28gc29sdmVzIHRoZSBoaWVyYXJjaGljYWwgUlIgcHJvYmxlbSBhcyB3ZWxsLg0KDQpQYXJ0bHkg YWdyZWUuIEFkdmVydGlzaW5nIGFuIGFsdGVybmF0ZSBSVCBtZW1iZXJzaGlwIGluZm8gcm91dGUg aXMgYWxzbyBwcm9wb3NlZCBpbiBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLCBp biBhZGRpdGlvbiB0aGUgZHJhZnQgYWxzbyBzcGVjaWZpZXMgY29uc3RyYWludHMgb24gdGhhdCAi YWx0ZXJuYXRlIHBhdGgiIGNvbnNpZGVyaW5nIHRoZSBCR1AgbG9vcCBkZXRlY3Rpb24gbWVjaGFu aXNtcy4gV2hlbiB0aGUgUlIgaGFzIG11bHRpcGxlIGFsdGVybmF0ZXMsIHRoZXJlIGhhcyB0byBi ZSBzb21lIHJ1bGUgZm9yIGNob29zaW5nIHRoZSBhbHRlcm5hdGUgYW5kIGFkdmVydGlzaW5nIGl0 IHRvIHRoZSBzZW5kZXIgb2YgdGhlIGJlc3QuDQoNCkknZCBhZ3JlZSB0aGF0IHdlIG1heSBnZW5l cmFsaXplIHRoZSBydWxlIGZvciB0aGUgZGlzdHJpYnV0aW9uIG9mIFJUIG1lbWJlcnNoaXAgaW5m byBpZiBpdCB3b3JrcyB0aHJvdWdoIGFsbCBwb3NzaWJsZSBsZWdpdGltYXRlIHNjZW5hcmlvcy4N Cg0KPiANCj4gSSdkIGxpa2UgdGhlIHRoaW5rIG9mIGl0IGFzIHdpdGggbXVsdGljYXN0IGZsb3cg d2hlcmUgUlIgaXMgbGlrZSBSUCBhbmQgUEVzIGFyZSBsaWtlDQo+IFNvdXJjZXMgKyBSZWNlaXZl cnMuDQo+IFRoZXJlJ3Mgbm8gbmVlZCBmb3IgdGhlIFJQIChSUikgdG8gcmVjZWl2ZSB0aGUgbWNh c3Qgc3RyZWFtIChlLmcuIFZQTiBQcmVmaXhlcykNCj4gd2hlbiB0aGVyZSdzIGp1c3Qgb25lIFNv dXJjZS9SZWNlaXZlciAoUEUpIGNvbm5lY3RlZCB0byBpdC4NCj4gQSBzaW1wbGUgc3RhdGUgb24g dGhlIFJQIHNheWluZyB0aGVyZSBpcyBhIHBhcnRpY3VsYXIgc3RyZWFtIGF2YWlsYWJsZSBhdCB0 aGlzDQo+IHBhcnRpY3VsYXIgc291cmNlIGlzIGVub3VnaCAoaS5lLiBSVCBtZW1iZXJzaGlwIE5M Ukkgb24gUlIpLg0KPiBPbmNlIG90aGVyIHNvdXJjZS9yZWNlaXZlcnMgKFBFcykgYXJlIGNvbm5l Y3RlZCB0byB0aGUgUlAoUlIpIGFuZCBzaWduYWwgdGhlaXINCj4gZGVzaXJlIHRvIHJlY2VpdmUg dGhlIHN0cmVhbSAodmlhIFJUIG1lbWJlcnNoaXAgTkxSSSkuDQo+IFRoZW4gUlAgKFJSKSBkZWNp ZGVzIHRoZSBkZXNpcmUgcmVjZWl2ZSB0aGUgc3RyZWFtIChSVCBtZW1iZXJzaGlwIE5MUkkpIGlz DQo+IHdvcnRoIHNwcmVhZGluZyBhbmQgZGlzc2VtaW5hdGVzIHRoZSBpbmZvcm1hdGlvbiB0byB0 aGUgaW50ZXJlc3RlZA0KPiBzb3VyY2VzL3JlY2VpdmVycyAoUEVzKS4NCj4gT25jZSB0aGF0IGhh cHBlbnMgc291cmNlcy9yZWNlaXZlcnMgKFBFcykgd2lsbCBzdGFydCBzZW5kaW5nIHRoZSBtY2Fz dCBzdHJlYW0NCj4gKGUuZy4gVlBOIFByZWZpeGVzKSB0b3dhcmRzIHRoZSBSUCAoUlIpIHdoaWNo IHRoYW4gcmVmbGVjdHMgdGhpcyBtY2FzZSBzdHJlYW1zDQo+IHRvIGFsbCBpbnRlcmVzdGVkIHNv dXJjZXMvcmVjZWl2ZXJzIChQRXMpLg0KDQpOaWNlIGFuYWxvZ3k6KSBXaGlsZSBpbiBCR1AgSU1P IHdlIGFsc28gbmVlZCB0byBjb25zaWRlciBzb21lIGV4aXN0aW5nIHJ1bGVzIChlLmcuIGJlc3Qg cGF0aCBzZWxlY3Rpb24sIGxvb3AgZGV0ZWN0aW9uKSwgaWYgd2UgZG9uJ3Qgd2FudCB0byBjaGFu Z2UgdGhlbSB0b28gbXVjaC4NCg0KPiBJIGJlbGlldmUgdGhlIGNvbmNlcm5zIHByZXNlbnRlZCBp biBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLXJyLTAwIGNvdWxkDQo+IGJlIHJlc29s dmVkIGJ5IGFkZC1wYXRoIHdoZXJlIGF0IGxlYXN0IG9uZSBhZGRpdGlvbmFsIHBhdGggaXMgYWR2 ZXJ0aXNlZCBhbG9uZw0KPiB3aXRoIHRoZSBiZXN0LXBhdGguDQoNCkFzIEkgbWVudGlvbmVkIGlu IG9uZSBwcmV2aW91cyBtYWlsLCBhZGQtcGF0aHMgYWxzbyBuZWVkIHNvbWUgcnVsZXMgdG8gc2Vs ZWN0IHRoZSBhcHByb3ByaWF0ZSBhZGRpdGlvbmFsIHBhdGgocyksIHVubGVzcyAiYWRkLXBhdGhz IGFsbCIgaXMgdXNlZC4gQW5kIGlmIHRoZSBSUiBrbm93cyB3aGljaCBhbHRlcm5hdGUgcGF0aCB3 b3VsZCB3b3JrLCBqdXN0IGFkdmVydGlzZSB0aGF0IHBhdGggd291bGQgYmUgZW5vdWdoLg0KDQo+ IEJ1dCBzdGlsbCBydWxlIDMuMi5pLiBpbiBSRkM0Njg0IGlzIHZlcnkgaGFybWZ1bCBpbiBzY2Vu YXJpb3Mgd2hlcmUgUlJzIGFyZSBjbGllbnRzDQo+IG9mIG90aGVyIFJScyAoc2FtZSBsZXZlbCBv ciBkaWZmZXJlbnQgbGV2ZWwpLg0KDQpBZ3JlZSB0aGF0IHdlIG1heSBmaW5kIHNvbWUgYmV0dGVy IHdheSB0byBhY2hpZXZlIHRoZSBzYW1lIGVmZmVjdC46KQ0KDQpCZXN0IHJlZ2FyZHMsDQpKaWUN Cg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogRG9uZ2ppZSAoSmlt bXkpIFttYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbV0NCj4gPiBTZW50OiBNb25kYXksIEp1bmUg MjMsIDIwMTQgNDo1OSBBTQ0KPiA+IFRvOiBWaXRrb3Zza8O9IEFkYW07IFJvYmVydCBSYXN6dWsN Cj4gPiBDYzogaWRyQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFtJZHJdIE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3INCj4gPiBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2FsLSBy ci0wMC50eHQNCj4gPg0KPiA+IEhpIEFkYW0sDQo+ID4NCj4gPiBJZiBSRCBpcyBwYXJ0IG9mIHRo ZSBSVEMgcm91dGVzLCB0aGlzIHByb2JsZW0gd2lsbCBub3Qgb2NjdXI6KSBXaGlsZQ0KPiA+IGFz IGFuYWx5emVkIGluIHJmYyA0Njg0LCB0aGlzIHJlcXVpcmVzIG1vcmUgUlRDIHJvdXRlcyBiZWlu ZyBleGNoYW5nZWQNCj4gPiBhbmQga2VwdCBpbiB0aGUgbG9jYWwgQVMuDQo+ID4NCj4gPiBJIGFn cmVlIHRoYXQgYWRkLXBhdGggaXMgYSBjYW5kaWRhdGUgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVt LCB3aGlsZQ0KPiA+IHdoZW4gZW5hYmxpbmcgYWRkLXBhdGggb24gUlRDIEFGSS9TQUZJLCB3ZSBz dGlsbCBuZWVkIHRvIHNwZWNpZnkgdGhlDQo+ID4gcnVsZXMgb2Ygd2hpY2ggUlRDIHJvdXRlcyBz aG91bGQgYmUgYWR2ZXJ0aXNlZCB0byBzb2x2ZSB0aGlzIHByb2JsZW0uDQo+ID4gT3Igd2UganVz dCB1cGRhdGUgdGhlIHJ1bGVzIG9mIFJUQyBhZHZlcnRpc2VtZW50IGFzIHRoZSBvdGhlciBSVEMg cmVsYXRlZA0KPiBuZXcgZHJhZnRzPw0KPiA+DQo+ID4gTWFueSB0aGFua3MsDQo+ID4gSmllDQo+ ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBWaXRrb3Zz a8O9IEFkYW0gW21haWx0bzphZGFtLnZpdGtvdnNreUBzd2FuLnNrXQ0KPiA+ID4gU2VudDogU3Vu ZGF5LCBKdW5lIDIyLCAyMDE0IDM6MjAgQU0NCj4gPiA+IFRvOiBSb2JlcnQgUmFzenVrDQo+ID4g PiBDYzogRG9uZ2ppZSAoSmltbXkpOyBpZHJAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBb SWRyXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gPiBkcmFmdC1kb25nLWlkci1y dGMtaGllcmFyY2hpY2FsLXJyLTAwLnR4dA0KPiA+ID4NCj4gPiA+IEFhaCBJIHNlZSA6KQ0KPiA+ ID4gV2VsbCB3ZSBjb3VsZCBoYXZlIHRoYXQgb25lIHNvbHZlZCBpZiBSRCB3b3VsZCBiZSBwYXJ0 IG9mIHRoZSBSVEMNCj4gPiA+IHJvdXRlcyA6KSAodGhvdWdoIEkgdW5kZXJzdGFuZCBvbmUgY291 bGQgdXNlIFJUQyBmb3Igbm9uIFZQTiByb3V0ZXMNCj4gPiA+IGFzIHdlbGwgc28uLi4pIEFueXdh eXMgc28gdGhhbiBhcyB5b3UgbWVudGlvbmVkIGFkZC1wYXRoIG9uIHRoZSBSVEMNCj4gPiA+IEFG IHNlZW1zIGFzIHRoZSBiZXN0IG9wdGlvbiB0aGVuLg0KPiA+ID4NCj4gPiA+IGFkYW0NCj4gPiA+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogcnJhc3p1a0BnbWFp bC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mDQo+ID4gPiA+IFJv YmVydCBSYXN6dWsNCj4gPiA+ID4gU2VudDogU2F0dXJkYXksIEp1bmUgMjEsIDIwMTQgNzo1MiBQ TQ0KPiA+ID4gPiBUbzogVml0a292c2vDvSBBZGFtDQo+ID4gPiA+IENjOiBEb25namllIChKaW1t eSk7IGlkckBpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW0lkcl0gTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvcg0KPiA+ID4gPiBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpY2Fs LSByci0wMC50eHQNCj4gPiA+ID4NCj4gPiA+ID4gSGkgQWRhbSwNCj4gPiA+ID4NCj4gPiA+ID4g SmllIGlzIGRlc2NyaWJpbmcgUlQgcm91dGVzIG5vdCBWUE4gcm91dGVzLiBZb3VyIHN0b3J5IGRv ZXMgbm90DQo+ID4gPiA+IGFwcGx5IHRvIFJUIHJvdXRlcyBhcyBmb3JtYXQgb2YgUlQgTkxSSSBp cyB3ZWxsIGRlZmluZWQgYnkgUkZDIDspDQo+ID4gPiA+DQo+ID4gPiA+IEJlc2lkZXMgTVBMUyBu ZXR3b3JrIG9yIG5vdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIGl0IC4uLi4NCj4gPiA+ID4NCj4g PiA+ID4gQmVzdCwNCj4gPiA+ID4gUi4NCj4gPiA+ID4NCj4gPiA+ID4gT24gU2F0LCBKdW4gMjEs IDIwMTQgYXQgNzoxOSBQTSwgVml0a292c2vDvSBBZGFtDQo+ID4gPiA+IDxhZGFtLnZpdGtvdnNr eUBzd2FuLnNrPg0KPiA+ID4gPiB3cm90ZToNCj4gPiA+ID4gPiBIaSBKaWUsDQo+ID4gPiA+ID4g V2VsbCB0aGUgY29ycmVjdGx5IGRlc2lnbmVkIE1QTFMgbmV0d29ya3MgdXNlIHVuaXF1ZSBwZXIg UEUgcGVyDQo+ID4gPiA+ID4gVlJGIFJEcw0KPiA+ID4gPiBpbiBmb3JtIG9mIFJJRDp4eHh4eC4N Cj4gPiA+ID4gPiBVbmlxdWUgcGVyIFBFIFJEcyBtYWtlcyBhbGwgY29waWVzIG9mIHRoZSBzYW1l IFZQTiBwcmVmaXgNCj4gPiA+ID4gPiByZWNlaXZlZCBmcm9tDQo+ID4gPiA+IGRpZmZlcmVudCBQ RXMgdW5pcXVlIHNvIFJScyB3aWxsIHNlbGVjdCBhbGwgYXMgYmVzdCBwYXRoIGFuZA0KPiA+ID4g PiBkaXN0cmlidXRlIHRoZW0gYWNjb3JkaW5nbHksIHdoaWNoIHNvbHZlcyB0aGlzIGFuZCBtYW55 IG90aGVyIGlzc3Vlcy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEluIG90aGVyIHdvcmRzIGlmIHNv bWVvbmUgdHJpZXMgdG8gc2hvb3QgaGltc2VsZiBpbiB0aGUgZm9vdCBJDQo+ID4gPiA+ID4gd291 bGRuJ3QNCj4gPiA+ID4gZGV2ZWxvcCBidWxsZXRwcm9vZiBib290cyBmb3IgaGltLg0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gYWRhbQ0KPiA+ID4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+ID4gPiA+PiBGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIERvbmdqaWUNCj4gPiA+ID4gPj4gKEppbW15KQ0KPiA+ID4gPiA+PiBTZW50OiBG cmlkYXksIEp1bmUgMjAsIDIwMTQgNDo1NSBBTQ0KPiA+ID4gPiA+PiBUbzogaWRyQGlldGYub3Jn DQo+ID4gPiA+ID4+IFN1YmplY3Q6IFtJZHJdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yDQo+ID4gPiA+ID4+IGRyYWZ0LWRvbmctaWRyLXJ0Yy0gaGllcmFyY2hpY2FsLXJyLTAwLnR4 dA0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBIaSBhbGwsDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+ IFRoaXMgaXMgYSBzaG9ydCBkcmFmdCB0byBtYWtlIFJUQyBhcHBsaWNhYmxlIGluIGhpZXJhcmNo aWNhbCBSUiBzY2VuYXJpby4NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gQ29tbWVudHMgYXJlIHdl bGNvbWUuDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEJlc3QgcmVnYXJkcywNCj4gPiA+ID4gPj4g SmllDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+PiA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELA0KPiA+ID4g PiA+PiA+IGRyYWZ0LWRvbmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnItMDAudHh0DQo+ID4gPiA+ ID4+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaWUgRG9uZyBhbmQgcG9z dGVkIHRvIHRoZQ0KPiA+ID4gPiA+PiA+IElFVEYNCj4gPiA+ID4gPj4gcmVwb3NpdG9yeS4NCj4g PiA+ID4gPj4gPg0KPiA+ID4gPiA+PiA+IE5hbWU6ICAgICAgICAgICAgICAgZHJhZnQtZG9uZy1p ZHItcnRjLWhpZXJhcmNoaWNhbC1ycg0KPiA+ID4gPiA+PiA+IFJldmlzaW9uOiAgIDAwDQo+ID4g PiA+ID4+ID4gVGl0bGU6ICAgICAgICAgICAgICBFeHRlbnNpb25zIHRvIFJULUNvbnN0cmFpbiBp biBIaWVyYXJjaGljYWwNCj4gUm91dGUNCj4gPiA+IFJlZmxlY3Rpb24NCj4gPiA+ID4gPj4gPiBT Y2VuYXJpb3MNCj4gPiA+ID4gPj4gPiBEb2N1bWVudCBkYXRlOiAgICAgIDIwMTQtMDYtMTkNCj4g PiA+ID4gPj4gPiBHcm91cDogICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+ ID4gPiA+PiA+IFBhZ2VzOiAgICAgICAgICAgICAgNQ0KPiA+ID4gPiA+PiA+IFVSTDoNCj4gPiA+ ID4gPj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kb25nLWlk ci1ydGMtaGllcmFyDQo+ID4gPiA+ID4+ID4gY2gNCj4gPiA+ID4gPj4gPiBpYw0KPiA+ID4gPiA+ PiA+IGFsDQo+ID4gPiA+ID4+ID4gLXJyDQo+ID4gPiA+ID4+ID4gLTAwLnR4dA0KPiA+ID4gPiA+ PiA+IFN0YXR1czoNCj4gPiA+ID4gPj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1kb25nLWlkci1ydGMtaGllcmFyY2hpDQo+ID4gPiA+ID4+ID4gY2ENCj4gPiA+ID4g Pj4gPiBsLQ0KPiA+ID4gPiA+PiA+IHJyDQo+ID4gPiA+ID4+ID4gLw0KPiA+ID4gPiA+PiA+IEh0 bWxpemVkOg0KPiA+ID4gPiA+PiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRv bmctaWRyLXJ0Yy1oaWVyYXJjaGljYWwtcnINCj4gPiA+ID4gPj4gPiAtMA0KPiA+ID4gPiA+PiA+ IDANCj4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4+ID4gQWJzdHJhY3Q6DQo+ ID4gPiA+ID4+ID4gICAgVGhlIFJvdXRlIFRhcmdldCAoUlQpIENvbnN0cmFpbiBtZWNoYW5pc20g c3BlY2lmaWVkIGluIFJGQyA0Njg0DQo+IGlzDQo+ID4gPiA+ID4+ID4gICAgdXNlZCB0byBidWls ZCBhIHJvdXRlIGRpc3RyaWJ1dGlvbiBncmFwaCBpbiBvcmRlciB0byByZXN0cmljdCB0aGUNCj4g PiA+ID4gPj4gPiAgICBwcm9wYWdhdGlvbiBvZiBWaXJ0dWFsIFByaXZhdGUgTmV0d29yayAoVlBO KSByb3V0ZXMuICBJbg0KPiBuZXR3b3JrDQo+ID4gPiA+ID4+ID4gICAgc2NlbmFyaW9zIHdoZXJl IGhpZXJhcmNoaWNhbCByb3V0ZSByZWZsZWN0aW9uIChSUikgaXMgdXNlZCwgdGhlDQo+ID4gPiA+ ID4+ID4gICAgZXhpc3RpbmcgUlQtQ29uc3RyYWluIG1lY2hhbmlzbSBjYW5ub3QgYnVpbGQgYSBj b3JyZWN0IHJvdXRlDQo+ID4gPiA+ID4+ID4gICAgZGlzdHJpYnV0aW9uIGdyYXBoLiAgVGhpcyBk b2N1bWVudCByZWZpbmVzIHRoZSByb3V0ZSBkaXN0cmlidXRpb24NCj4gPiA+ID4gPj4gPiAgICBy dWxlcyBvZiBSVC1Db25zdHJhaW4gdG8gYWRkcmVzcyB0aGUgaGllcmFyY2hpY2FsIFJSIHNjZW5h cmlvcy4NCj4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4+ID4NCj4gPiA+ID4g Pj4gPg0KPiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlDQo+ID4gPiA+ID4+ID4gdGltZSBvZiBz dWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZQ0KPiA+ID4g PiA+PiA+IGF2YWlsYWJsZSBhdA0KPiA+ID4gPiB0b29scy5pZXRmLm9yZy4NCj4gPiA+ID4gPj4g Pg0KPiA+ID4gPiA+PiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4gPiA+ID4+DQo+ID4gPiA+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g PiA+ID4+IElkciBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPj4gSWRyQGlldGYub3JnDQo+ID4gPiA+ ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+ID4gPiA+IElkciBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBJZHJAaWV0Zi5vcmcNCj4g PiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From nobody Sat Jun 28 10:58:31 2014 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 658B01A038E for ; Sat, 28 Jun 2014 10:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UTpKpZuZlhU7 for ; Sat, 28 Jun 2014 10:58:25 -0700 (PDT) Received: from out-13.mail.exa.net.uk (out-13.mail.exa.net.uk [82.219.4.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8B91A038B for ; Sat, 28 Jun 2014 10:58:24 -0700 (PDT) Received: from smtp-2.mail.exa.net.uk (smtp-2.mail.exa.net.uk [82.219.5.2]) by out-13.mail.exa.net.uk (ExaSMTPD) with ESMTP id 128591C006B for ; Sat, 28 Jun 2014 18:58:22 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id E901940260 for ; Sat, 28 Jun 2014 18:58:21 +0100 (BST) From: Thomas Mangin Content-Type: multipart/signed; boundary="Apple-Mail=_13EEAA9E-7897-4AF1-A319-6D377915DB9D"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Mao-Original-Outgoing-Id: 425671100.521756-f5501278e5706cede0244e107db54748 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Message-Id: <3D07E614-7615-430F-B39F-95EBE7ECC8FE@exa-networks.co.uk> Date: Sat, 28 Jun 2014 18:58:21 +0100 To: idr wg X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.98.1 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/idr/nbMYT1HXdTuAuvzeSe1qUMzegto Subject: [Idr] draft-ietf-l2vpn-evpn-07 : cosmetic comment 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, 28 Jun 2014 17:58:27 -0000 --Apple-Mail=_13EEAA9E-7897-4AF1-A319-6D377915DB9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07#section-7.2 The graphical description for "MAC Address" indicates the value 6 bytes. = It should read " MAC Address (variable)". with an indication that the value is to read the content of the "MAC = Address Length" divided by 8 AND not hardcode the value 6 ... As I said, cosmetic. Thomas --Apple-Mail=_13EEAA9E-7897-4AF1-A319-6D377915DB9D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlOvAjwACgkQA/52wvuLgaGfpgCfRcAFgv19k51d9cFy1zO5ei0s jtsAoMLY31iLHYeBmuDNT7f4Mw8XWeH/ =sHoa -----END PGP SIGNATURE----- --Apple-Mail=_13EEAA9E-7897-4AF1-A319-6D377915DB9D-- From nobody Sun Jun 29 06:50:15 2014 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 E678F1A04CD; Sun, 29 Jun 2014 06:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 ucXhwINWopwu; Sun, 29 Jun 2014 06:50:10 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA11F1A04C8; Sun, 29 Jun 2014 06:50:09 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5TDo4cg008316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 29 Jun 2014 08:50:06 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5TDo3Ed017821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Jun 2014 15:50:04 +0200 Received: from [135.244.224.52] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 29 Jun 2014 15:50:02 +0200 Message-ID: <53B01988.6080502@alcatel-lucent.com> Date: Sun, 29 Jun 2014 15:50:00 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: , , References: <5399AE30.3020703@alcatel-lucent.com> In-Reply-To: <5399AE30.3020703@alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/d-ILGqZD7j6Huo80G3f4nYuqNco Cc: l3vpn-chairs@tools.ietf.org, mpls-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 13:50:12 -0000 All, this WG LC is now closed. Thank you for your reviews and comments. There were few comments which I compiled and sent to the authors. We will proceed with requesting publication. -m Le 12/06/2014 15:42, Martin Vigoureux a écrit : > Working Groups, > > This is to start a 2-week Working Group Last Call in three Working > Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. > > The draft has been made a WG Document by WG Chairs decision. > > In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP > VPNs), an optional transitive BGP attribute called the > "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is > specified. This BGP attribute uses an octet field to specify the > PMSI tunnel type. RFC 6514 allocates the values 0-7. > > There now is need to make further code point allocations from this > name space. In particular, draft-ietf-mpls-seamless-mcast > needs to make such an allocation. That draft is currently in WG Last > Call in the MPLS Working Group. > > draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called > "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for > these code points. > The registry is created in the "Border Gateway Protocol (BGP) > Parameters" registry. > > Please send comments to the l3vpn mailing list (l3vpn@ietf.org). > > The WG LC will end on Friday the 27th of June. > > > Martin, on behalf of the WGs co-chairs > > From nobody Mon Jun 30 08:33:48 2014 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 ABDBE1A0393 for ; Mon, 30 Jun 2014 08:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.353 X-Spam-Level: ** X-Spam-Status: No, score=2.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu3XvxB7JiQY for ; Mon, 30 Jun 2014 08:33:44 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910591A0392 for ; Mon, 30 Jun 2014 08:33:43 -0700 (PDT) From: =?utf-8?B?Vml0a292c2vDvSBBZGFt?= To: "Dongjie (Jimmy)" , Robert Raszuk Thread-Topic: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt Thread-Index: AQHPjDJlm41jOEL66EOT5ZVndaWnMpt5THPAgAKASAD//+xkgIAAOCmwgAHzEgCABv+DcIAAyHgAgAQmF5A= Date: Mon, 30 Jun 2014 15:33:40 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B019C9019@EX01.swan.local> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C927336B72F7@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927336B72F7@nkgeml512-mbx.china.huawei.com> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.40.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/BMkY-LzriLHqyJSvVMpk8pdrrlg Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 15:33:46 -0000 SGkgSmllLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHkuDQpQbGVhc2Ugc2VlIG15IGNvbW1l bnRzIGlubGluZS4gDQoNCg0KPiANCj4gSGkgQWRhbSwNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBh bmFseXNpcywgYW5kIHBsZWFzZSBzZWUgbXkgcmVwbGllcyBpbmxpbmU6DQo+IA0KPiA+IFJlZ2Fy ZGluZyB0aGUgcnVsZSAzLjIuaSBvZiBSRkM0Njg0Lg0KPiA+DQo+ID4gRmlyc3QgY29uc2lkZXIg c2NlbmFyaW8gYSk6DQo+ID4gYSkNCj4gPiBSUi0tLS1QRTENCj4gPg0KPiA+IFdoeSB3b3VsZCBJ IHdhbnQgdGhlIFJSIHRvIGxlYXJuIHRoZSBQRSdzIHByZWZpeGVzIGlmIHRoZXJlJ3Mgbm8gb25l DQo+ID4gaW50ZXJlc3RlZCBpbiB0aGVtIChubyBvdGhlciBjbGllbnRzIGludGVyZXN0ZWQgdG8g cmVjZWl2ZSBOUkxJIGZvcg0KPiA+IGdpdmVuIFJUcykgYXMgUEUxIGlzIHRoZSBvbmx5IG9uZSB0 aGF0IGFkdmVydGlzZWQgdGhlIFJvdXRlIFRhcmdldA0KPiBtZW1iZXJzaGlwIGluZm9ybWF0aW9u IHRvIFJSLg0KPiANCj4gQWdyZWUgdGhhdCBpbiB0aGlzIGNhc2UgUlIgZG9lcyBub3QgbmVlZCB0 byBhZHZlcnRpc2UgUlQgbWVtYmVyc2hpcCBpbmZvIHRvDQo+IFBFMS4NCj4gDQo+ID4gTm93IGxl dCdzIGNvbnNpZGVyIHNjZW5hcmlvIGIpOg0KPiA+IGIpDQo+ID4gUEUyLS0tLVJSLS0tLVBFMQ0K PiA+DQo+ID4gTm93IHRoZXJlIGlzIGFub3RoZXIgY2xpZW50IChQRTIpIGNvbm5lY3RlZCB0byB0 aGUgUlIgYW5kIGl0IGhhcHBlbnMNCj4gPiB0byBiZSBpbnRlcmVzdGVkIGluIHJlY2VpdmluZyBO UkxJIGZvciBhIGdpdmVuIFJUIGFzIGRlc2lnbmF0ZWQgYnkgdGhlDQo+ID4gYWR2ZXJ0aXNlZCBS b3V0ZSBUYXJnZXQgbWVtYmVyc2hpcCBpbmZvcm1hdGlvbiBmb3IgdGhlIGdpdmVuIFJULg0KPiA+ IE9rIG5vdyB0aGF0IHRoZXJlIGFyZSBpbnRlcmVzdGVkIHJlY2VpdmVycyBmb3IgYSBnaXZlbiBO UkxJIG9uIGJvdGgNCj4gPiBzZXNzaW9ucyAtIFJSIHNob3VsZCBzdGFydCBsZWFybmluZyB0aGUg TlJMSXMgZnJvbSBjbGllbnRzIHNvIHRoYXQgaXQNCj4gPiBjYW4gZGlzc2VtaW5hdGUgdGhlIGlu Zm9ybWF0aW9uIGFjY29yZGluZ2x5Lg0KPiA+DQo+ID4gSW4gb3JkZXIgdG8gc3RhcnQgbGVhcm5p bmcgdGhlIE5STElzIFJSIGhhcyB0byBhZHZlcnRpc2UgYSBkZXNpcmUgdG8NCj4gPiByZWNlaXZl IHRoZW0gYW5kIHRvIGRvIHRoYXQgd2UgY2FuIHVzZSBtb2RpZmllZCBydWxlIDMuMi5paS4NCj4g Pg0KPiA+ICAgICAgICAgV2hlbiBhZHZlcnRpc2luZyBhbiBSVCBtZW1iZXJzaGlwIE5MUkkgdG8g YSBjbGllbnQgcGVlciwgaWYNCj4gPiAgICAgICAgIHRoZSBiZXN0IHBhdGggYXMgc2VsZWN0ZWQg YnkgdGhlIHBhdGggc2VsZWN0aW9uIHByb2NlZHVyZQ0KPiA+ICAgICAgICAgZGVzY3JpYmVkIGlu IFNlY3Rpb24gOS4xIG9mIHRoZSBiYXNlIEJHUCBzcGVjaWZpY2F0aW9uIFs0XSBpcyBhDQo+ID4g ICAgICAgICByb3V0ZSByZWNlaXZlZCBmcm9tIHRoYXQgY2xpZW50IHBlZXIgaW4gcGFydGljdWxh ciwgYW5kIGlmIHRoZXJlIGlzIGFuDQo+ID4gICAgICAgICBhbHRlcm5hdGl2ZSBwYXRoIHRvIHRo ZSBzYW1lIGRlc3RpbmF0aW9uIGZyb20gYW5vdGhlciBjbGllbnQNCj4gPiBvciBhIG5vbi1jbGll bnQsIHRoZQ0KPiA+ICAgICAgICAgYXR0cmlidXRlcyBvZiB0aGUgb3RoZXIgcGF0aCBhcmUgYWR2 ZXJ0aXNlZCB0byB0aGUgcGVlci4NCj4gPg0KPiA+IE5vdyB0aGlua2luZyBhYm91dCBpdCBvbmx5 IG9uZSBydWxlIGZvciByZWZsZWN0aW9uIG9mIFJUIG1lbWJlcnNoaXANCj4gPiBOTFJJIGlzIGVu b3VnaCBJIGd1ZXNzLg0KPiA+IElmIHlvdSByZWNlaXZlZCBSVCBtZW1iZXJzaGlwIE5MUkkgZnJv bSBvbmx5IG9uZSBwZWVyIGRvbid0IGFkdmVydGlzZQ0KPiA+IGl0IHVudGlsIHlvdSBoYXZlIHJl Y2VpdmVkIHRoZSBSVCBtZW1iZXJzaGlwIE5MUkkgd2l0aCB0aGUgc2FtZSBSVA0KPiA+IGZyb20g YW5vdGhlciBwZWVyLg0KPiA+IFRoZW4geW91IGNhbiBhZHZlcnRpc2UgdGhlIGFsdGVybmF0ZSAo bm90IHRoZSBvbmUgdGhhdCB0aGUgcGVlciBzZW50DQo+ID4geW91KSBSVCBtZW1iZXJzaGlwIE5M UkkgdG8gYSBnaXZlbiBwZWVyIChzaW1wbGUgc3BsaXQgaG9yaXpvbikuDQo+IA0KPiA+IFRoZW4g dGhlcmUncyBubyBuZWVkIHRvIG1vZGlmeSB0aGUgdXBkYXRlIHNvIHRoYXQgaXQgY2FuIGJlIGFj Y2VwdGVkDQo+ID4gYnkgdGhlIG9yaWdpbmF0b3IgKGFzIGluIDMuMi5pLikuDQo+ID4gQW5kIHRo aXMgYWxzbyBzb2x2ZXMgdGhlIGhpZXJhcmNoaWNhbCBSUiBwcm9ibGVtIGFzIHdlbGwuDQo+IA0K PiBQYXJ0bHkgYWdyZWUuIEFkdmVydGlzaW5nIGFuIGFsdGVybmF0ZSBSVCBtZW1iZXJzaGlwIGlu Zm8gcm91dGUgaXMgYWxzbw0KPiBwcm9wb3NlZCBpbiBkcmFmdC1kb25nLWlkci1ydGMtaGllcmFy Y2hpY2FsLXJyLCBpbiBhZGRpdGlvbiB0aGUgZHJhZnQgYWxzbw0KPiBzcGVjaWZpZXMgY29uc3Ry YWludHMgb24gdGhhdCAiYWx0ZXJuYXRlIHBhdGgiIGNvbnNpZGVyaW5nIHRoZSBCR1AgbG9vcA0K PiBkZXRlY3Rpb24gbWVjaGFuaXNtcy4gV2hlbiB0aGUgUlIgaGFzIG11bHRpcGxlIGFsdGVybmF0 ZXMsIHRoZXJlIGhhcyB0byBiZQ0KPiBzb21lIHJ1bGUgZm9yIGNob29zaW5nIHRoZSBhbHRlcm5h dGUgYW5kIGFkdmVydGlzaW5nIGl0IHRvIHRoZSBzZW5kZXIgb2YgdGhlDQo+IGJlc3QuDQo+IA0K WWVzIHBsZWFzZSBJIGFncmVlLiANCkhvd2V2ZXIgSSB0aGluayB0aGUgbmV3IHJ1bGUgc2hvdWxk IGJlIGdlbmVyYWxpemVkIGZvciBhbGwgaUJHUCBzZXNzaW9ucyBhbmQgc2hvdWxkIHJlcGxhY2Ug dGhlIHR3byBleGlzdGluZyBydWxlcy4gDQoNCj4gSSdkIGFncmVlIHRoYXQgd2UgbWF5IGdlbmVy YWxpemUgdGhlIHJ1bGUgZm9yIHRoZSBkaXN0cmlidXRpb24gb2YgUlQNCj4gbWVtYmVyc2hpcCBp bmZvIGlmIGl0IHdvcmtzIHRocm91Z2ggYWxsIHBvc3NpYmxlIGxlZ2l0aW1hdGUgc2NlbmFyaW9z Lg0KPiANCkknbSByZWFsbHkgaW50ZXJlc3RlZCB0byBzZWUgYSBsZWdpdGltYXRlIHNjZW5hcmlv IHdoZXJlIGEgc2ltcGxlICJzcGxpdC1ob3Jpem9uLWxpa2UiIHJ1bGUgd291bGQgbm90IHdvcmsu IA0KDQoNCj4gPg0KPiA+IEknZCBsaWtlIHRoZSB0aGluayBvZiBpdCBhcyB3aXRoIG11bHRpY2Fz dCBmbG93IHdoZXJlIFJSIGlzIGxpa2UgUlANCj4gPiBhbmQgUEVzIGFyZSBsaWtlIFNvdXJjZXMg KyBSZWNlaXZlcnMuDQo+ID4gVGhlcmUncyBubyBuZWVkIGZvciB0aGUgUlAgKFJSKSB0byByZWNl aXZlIHRoZSBtY2FzdCBzdHJlYW0gKGUuZy4gVlBODQo+ID4gUHJlZml4ZXMpIHdoZW4gdGhlcmUn cyBqdXN0IG9uZSBTb3VyY2UvUmVjZWl2ZXIgKFBFKSBjb25uZWN0ZWQgdG8gaXQuDQo+ID4gQSBz aW1wbGUgc3RhdGUgb24gdGhlIFJQIHNheWluZyB0aGVyZSBpcyBhIHBhcnRpY3VsYXIgc3RyZWFt IGF2YWlsYWJsZQ0KPiA+IGF0IHRoaXMgcGFydGljdWxhciBzb3VyY2UgaXMgZW5vdWdoIChpLmUu IFJUIG1lbWJlcnNoaXAgTkxSSSBvbiBSUikuDQo+ID4gT25jZSBvdGhlciBzb3VyY2UvcmVjZWl2 ZXJzIChQRXMpIGFyZSBjb25uZWN0ZWQgdG8gdGhlIFJQKFJSKSBhbmQNCj4gPiBzaWduYWwgdGhl aXIgZGVzaXJlIHRvIHJlY2VpdmUgdGhlIHN0cmVhbSAodmlhIFJUIG1lbWJlcnNoaXAgTkxSSSku DQo+ID4gVGhlbiBSUCAoUlIpIGRlY2lkZXMgdGhlIGRlc2lyZSByZWNlaXZlIHRoZSBzdHJlYW0g KFJUIG1lbWJlcnNoaXANCj4gPiBOTFJJKSBpcyB3b3J0aCBzcHJlYWRpbmcgYW5kIGRpc3NlbWlu YXRlcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlDQo+ID4gaW50ZXJlc3RlZCBzb3VyY2VzL3JlY2Vp dmVycyAoUEVzKS4NCj4gPiBPbmNlIHRoYXQgaGFwcGVucyBzb3VyY2VzL3JlY2VpdmVycyAoUEVz KSB3aWxsIHN0YXJ0IHNlbmRpbmcgdGhlIG1jYXN0DQo+ID4gc3RyZWFtIChlLmcuIFZQTiBQcmVm aXhlcykgdG93YXJkcyB0aGUgUlAgKFJSKSB3aGljaCB0aGFuIHJlZmxlY3RzDQo+ID4gdGhpcyBt Y2FzZSBzdHJlYW1zIHRvIGFsbCBpbnRlcmVzdGVkIHNvdXJjZXMvcmVjZWl2ZXJzIChQRXMpLg0K PiANCj4gTmljZSBhbmFsb2d5OikgV2hpbGUgaW4gQkdQIElNTyB3ZSBhbHNvIG5lZWQgdG8gY29u c2lkZXIgc29tZSBleGlzdGluZw0KPiBydWxlcyAoZS5nLiBiZXN0IHBhdGggc2VsZWN0aW9uLCBs b29wIGRldGVjdGlvbiksIGlmIHdlIGRvbid0IHdhbnQgdG8gY2hhbmdlDQo+IHRoZW0gdG9vIG11 Y2guDQo+IA0KPiA+IEkgYmVsaWV2ZSB0aGUgY29uY2VybnMgcHJlc2VudGVkIGluDQo+ID4gZHJh ZnQtZG9uZy1pZHItcnRjLWhpZXJhcmNoaWNhbC1yci0wMCBjb3VsZCBiZSByZXNvbHZlZCBieSBh ZGQtcGF0aA0KPiA+IHdoZXJlIGF0IGxlYXN0IG9uZSBhZGRpdGlvbmFsIHBhdGggaXMgYWR2ZXJ0 aXNlZCBhbG9uZyB3aXRoIHRoZSBiZXN0LXBhdGguDQo+IA0KPiBBcyBJIG1lbnRpb25lZCBpbiBv bmUgcHJldmlvdXMgbWFpbCwgYWRkLXBhdGhzIGFsc28gbmVlZCBzb21lIHJ1bGVzIHRvDQo+IHNl bGVjdCB0aGUgYXBwcm9wcmlhdGUgYWRkaXRpb25hbCBwYXRoKHMpLCB1bmxlc3MgImFkZC1wYXRo cyBhbGwiIGlzIHVzZWQuIEFuZA0KPiBpZiB0aGUgUlIga25vd3Mgd2hpY2ggYWx0ZXJuYXRlIHBh dGggd291bGQgd29yaywganVzdCBhZHZlcnRpc2UgdGhhdCBwYXRoDQo+IHdvdWxkIGJlIGVub3Vn aC4NCg0KWWVzIHBsZWFzZSB5b3UgaGF2ZSBtZW50aW9uZWQgdGhhdCB0aGVyZSBtaWdodCBiZSBz b21lIHRyaWNreSBzY2VuYXJpb3Mgd2hlcmUgYWRkLXBhdGggMiBjb3VsZCBzZWxlY3QgdHdvIHBh dGhzIGZyb20gd2hpY2ggbmVpdGhlciBvbmUgd2lsbCBiZSBhY2NlcHRlZC4gDQpXb3VsZCB5b3Ug cGxlYXNlIHNoYXJlIHRoZSBzY2VuYXJpb3MgYXMgSSdtIHJlYWxseSBzdHVjayB3aXRoIHRoaXMg b25lIGFuZCBJIGNhbid0IHNlZW0gdG8gZmluZCBhIHRvcG9sb2d5IHdoZXJlIHRoaXMgY291bGQg aGFwcGVuLiANClRoZSBvbmx5IG9uZSBJIGNhbWUgdXAgd2l0aCBpcyBhIHRyaWFuZ2xlIG9mIFJS IHdoZXJlIHNpbmdsZSBQRSBpcyBjb25uZWN0ZWQgdG8gb25seSBvbmUgb2YgdGhlIFJScy4gDQpC dXQgaW4gdGhpcyB0b3BvbG9neSB0aGVyZSdzIG5vIG5lZWQgdG8gYWR2ZXJ0aXNlIHRoZSBwcmVm aXhlcyBhcyBJIG1lbnRpb25lZCBpbiBteSBwcmV2aW91cyBtYWlsIChubyBvdGhlciBpbnRlcmVz dGVkIHJlY2VpdmVycykuIA0KDQoNCg0KPiANCj4gPiBCdXQgc3RpbGwgcnVsZSAzLjIuaS4gaW4g UkZDNDY4NCBpcyB2ZXJ5IGhhcm1mdWwgaW4gc2NlbmFyaW9zIHdoZXJlDQo+ID4gUlJzIGFyZSBj bGllbnRzIG9mIG90aGVyIFJScyAoc2FtZSBsZXZlbCBvciBkaWZmZXJlbnQgbGV2ZWwpLg0KPiAN Cj4gQWdyZWUgdGhhdCB3ZSBtYXkgZmluZCBzb21lIGJldHRlciB3YXkgdG8gYWNoaWV2ZSB0aGUg c2FtZSBlZmZlY3QuOikNCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gSmllDQo+IA0KDQoNCg0KYWRh bQ0KDQo= From nobody Mon Jun 30 11:45:36 2014 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 CAB601A0640 for ; Mon, 30 Jun 2014 11:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 x2b6aguhMokc for ; Mon, 30 Jun 2014 11:45:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 82AAB1A063A for ; Mon, 30 Jun 2014 11:45:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2F4EFC428; Mon, 30 Jun 2014 14:45:22 -0400 (EDT) Date: Mon, 30 Jun 2014 14:45:22 -0400 From: Jeffrey Haas To: Vitkovsk?? Adam Message-ID: <20140630184522.GC11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/WRYr-ZWdZEMZr5q9pggz98VwZcM Cc: Robert Raszuk , "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 18:45:26 -0000 Adam, On Fri, Jun 27, 2014 at 11:52:33AM +0000, Vitkovsk?? Adam wrote: > Hi folks, > > Regarding the rule 3.2.i of RFC4684. > > First consider scenario a): > a) > RR----PE1 > > Why would I want the RR to learn the PE's prefixes if there's no one interested in them (no other clients interested to receive NRLI for given RTs) as PE1 is the only one that advertised the Route Target membership information to RR. > > Now let's consider scenario b): > b) > PE2----RR----PE1 PE1 and PE2 advertise RT-C route R to RR. RR selects one of R(PE1) or R(PE2). It then would go to reflect that route back to the originator. Using standard rules, even with modification, loop suppression occurs either by the originator or via proxy at the reflector. The rule accommodates this case. The fact that it also incidentally serves as an attractor to the RR can be perceived as a bug or as a feature. Mostly it tends to be viewed as a feature. > I believe the concerns presented in draft-dong-idr-rtc-hierarchical-rr-00 could be resolved by add-path where at least one additional path is advertised along with the best-path. > But still rule 3.2.i. in RFC4684 is very harmful in scenarios where RRs are clients of other RRs (same level or different level). My current thinking is that add-path - within the RR hierarchy only - is perhaps a sufficient solution to this problem. This would avoid the need to implement RT-C add-path at the PEs, an important detail for faster deployment of a fix for this issue. (I have my doubts about the number of providers currently experiencing this issue.) A rough version of a proposal using add-path only among reflectors would look like the following: Reflector clients are tagged as being route-reflectors or not via configuration. Among RR clients that are also RRs: - Do not use 4684 3.2.i/ii - RT-C paths are advertised using add-path with the ORIGINATOR attribute preserved as it would otherwise be attached by a RR not doing 3.2.i The above procedure would permit routes received by the edge of a hierarchy of RRs to pass along RT-C routes within the hierarchy and build a loop-free graph following standard BGP distribution rules. At a RR that has as candidates RT-C routes either non-hierarchy routes or hierarchy routes, active route selection is performed as normal. When advertising to non-RR client routers, 3.2.i is performed. This ensures that an active path selected using best-path originating from that router may be advertised back as per above. (Similarly follow 3.2.ii, if necessary.) I have that nagging feeling that I've missed an important detail, so the above may not survive scrutiny. (But that's how engineering and science is supposed to work.) -- Jeff From nobody Mon Jun 30 11:53:21 2014 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 5FAC51A04B9 for ; Mon, 30 Jun 2014 11:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSlhZ82e5Wp2 for ; Mon, 30 Jun 2014 11:53:08 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE7A1A02E9 for ; Mon, 30 Jun 2014 11:53:07 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id hn18so4614325igb.11 for ; Mon, 30 Jun 2014 11:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cb1sPvMqt36Z0KNUWa8dA2K4itC7upDYKAatqpMkPEA=; b=LzZp8acGPkCvwCCLHS0SYQdTjjZpv9rzIslQ6YXZOw++esjN67zA6ZZGUYVwDJt0go cPILhCC4ZLX8omEcvr5pBJVGYQ4XpG8XMJqtVuDNV3pqEb4nYoqkbrhxbHIJe6TYjDYb wVvDNX/57JP6PON/06QT+uLwcUWFdYa8zDGCW+ZIDV1A0S5T8yiB0f6gzviRbZc5LInA MGjbSzVmD7zPPYK8TeldockU2I4lM/h/j9MqppXVJuvDe5QgDVfDVaR6cvuJuU1UOy1Z /R2owXIW7r/aekpuChOE3gjfxIVuJIHJlDQFjJYlG8Rz+f3D4OGMc1KQq5cc/22C+pEF uvbQ== MIME-Version: 1.0 X-Received: by 10.50.98.100 with SMTP id eh4mr35385240igb.9.1404154387246; Mon, 30 Jun 2014 11:53:07 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Mon, 30 Jun 2014 11:53:06 -0700 (PDT) In-Reply-To: <20140630184522.GC11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> <20140630184522.GC11842@pfrc> Date: Mon, 30 Jun 2014 20:53:06 +0200 X-Google-Sender-Auth: obdx6aKH-tSr-Upx7WC0CNn8Kcw Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: multipart/alternative; boundary=047d7b2e15df7632d404fd122b5b Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Q7gTbfWdWuUxbEpe6xH9mAatj8A Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 18:53:10 -0000 --047d7b2e15df7632d404fd122b5b Content-Type: text/plain; charset=UTF-8 Jeff, > My current thinking is that add-path - within the RR hierarchy only Just for clarity this is what I proposed earlier. I never seen a need to run RTC SAFI with add-paths to the PEs. Thx, R. On Mon, Jun 30, 2014 at 8:45 PM, Jeffrey Haas wrote: > Adam, > > On Fri, Jun 27, 2014 at 11:52:33AM +0000, Vitkovsk?? Adam wrote: > > Hi folks, > > > > Regarding the rule 3.2.i of RFC4684. > > > > First consider scenario a): > > a) > > RR----PE1 > > > > Why would I want the RR to learn the PE's prefixes if there's no one > interested in them (no other clients interested to receive NRLI for given > RTs) as PE1 is the only one that advertised the Route Target membership > information to RR. > > > > Now let's consider scenario b): > > b) > > PE2----RR----PE1 > > PE1 and PE2 advertise RT-C route R to RR. > RR selects one of R(PE1) or R(PE2). > It then would go to reflect that route back to the originator. > > Using standard rules, even with modification, loop suppression occurs > either > by the originator or via proxy at the reflector. > > The rule accommodates this case. The fact that it also incidentally serves > as an attractor to the RR can be perceived as a bug or as a feature. > Mostly > it tends to be viewed as a feature. > > > I believe the concerns presented in > draft-dong-idr-rtc-hierarchical-rr-00 could be resolved by add-path where > at least one additional path is advertised along with the best-path. > > But still rule 3.2.i. in RFC4684 is very harmful in scenarios where RRs > are clients of other RRs (same level or different level). > > My current thinking is that add-path - within the RR hierarchy only - is > perhaps a sufficient solution to this problem. This would avoid the need > to > implement RT-C add-path at the PEs, an important detail for faster > deployment of a fix for this issue. (I have my doubts about the > number of providers currently experiencing this issue.) > > > A rough version of a proposal using add-path only among reflectors would > look like the following: > > Reflector clients are tagged as being route-reflectors or not via > configuration. > Among RR clients that are also RRs: > - Do not use 4684 3.2.i/ii > - RT-C paths are advertised using add-path with the ORIGINATOR attribute > preserved as it would otherwise be attached by a RR not doing 3.2.i > > The above procedure would permit routes received by the edge of a hierarchy > of RRs to pass along RT-C routes within the hierarchy and build a loop-free > graph following standard BGP distribution rules. > > At a RR that has as candidates RT-C routes either non-hierarchy routes or > hierarchy routes, active route selection is performed as normal. When > advertising to non-RR client routers, 3.2.i is performed. This ensures > that > an active path selected using best-path originating from that router may be > advertised back as per above. > > (Similarly follow 3.2.ii, if necessary.) > > I have that nagging feeling that I've missed an important detail, so the > above may not survive scrutiny. (But that's how engineering and science is > supposed to work.) > > -- Jeff > --047d7b2e15df7632d404fd122b5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff,

>=C2=A0My curr= ent thinking is that add-path - within the RR hierarchy only

= Just for clarity this is what I proposed = earlier. I never seen a need to run RTC SAFI with add-paths to the PEs.=C2= =A0

=
Thx,
R.


On Mon, Jun 30, 2014 at 8:45 PM, Jeffrey Haas = <j= haas@pfrc.org> wrote:
Adam,

On Fri, Jun 27, 2014 at 11:52:33AM +0000, Vitkovsk?? Adam wrote:
> Hi folks,
>
> Regarding the rule 3.2.i of RFC4684.
>
> First consider scenario a):
> a)
> RR----PE1
>
> Why would I want the RR to learn the PE's prefixes if there's = no one interested in them (no other clients interested to receive NRLI for = given RTs) as PE1 is the only one that advertised the Route Target membersh= ip information to RR.
>
> Now let's consider scenario b):
> b)
> PE2----RR----PE1

PE1 and PE2 advertise RT-C route R to RR.
RR selects one of R(PE1) or R(PE2).
It then would go to reflect that route back to the originator.

Using standard rules, even with modification, loop suppression occurs eithe= r
by the originator or via proxy at the reflector.

The rule accommodates this case. =C2=A0The fact that it also incidentally s= erves
as an attractor to the RR can be perceived as a bug or as a feature. =C2=A0= Mostly
it tends to be viewed as a feature.

> I believe the concerns presented in draft-dong-idr-rtc-hierarchical-rr= -00 could be resolved by add-path where at least one additional path is adv= ertised along with the best-path.
> But still rule 3.2.i. in RFC4684 is very harmful in scenarios where RR= s are clients of other RRs (same level or different level).

My current thinking is that add-path - within the RR hierarchy only -= is
perhaps a sufficient solution to this problem. =C2=A0This would avoid the n= eed to
implement RT-C add-path at the PEs, an important detail for faster
deployment of a fix for this issue. =C2=A0(I have my doubts about the
number of providers currently experiencing this issue.)


A rough version of a proposal using add-path only among reflectors would look like the following:

Reflector clients are tagged as being route-reflectors or not via
configuration.
Among RR clients that are also RRs:
- Do not use 4684 3.2.i/ii
- RT-C paths are advertised using add-path with the ORIGINATOR attribute =C2=A0 preserved as it would otherwise be attached by a RR not doing 3.2.i<= br>
The above procedure would permit routes received by the edge of a hierarchy=
of RRs to pass along RT-C routes within the hierarchy and build a loop-free=
graph following standard BGP distribution rules.

At a RR that has as candidates RT-C routes either non-hierarchy routes or hierarchy routes, active route selection is performed as normal. =C2=A0When=
advertising to non-RR client routers, 3.2.i is performed. =C2=A0This ensure= s that
an active path selected using best-path originating from that router may be=
advertised back as per above.

(Similarly follow 3.2.ii, if necessary.)

I have that nagging feeling that I've missed an important detail, so th= e
above may not survive scrutiny. =C2=A0(But that's how engineering and s= cience is
supposed to work.)

-- Jeff

--047d7b2e15df7632d404fd122b5b-- From nobody Mon Jun 30 11:57:44 2014 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 892B01A03D0 for ; Mon, 30 Jun 2014 11:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 WqaoGz2eW_ox for ; Mon, 30 Jun 2014 11:57:39 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DFFC81A02DE for ; Mon, 30 Jun 2014 11:57:38 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9CC0FC3F4; Mon, 30 Jun 2014 14:57:38 -0400 (EDT) Date: Mon, 30 Jun 2014 14:57:38 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140630185738.GD11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> <20140630184522.GC11842@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/S1FN1auLKX93_onpUO61mOpUGYw Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 18:57:40 -0000 On Mon, Jun 30, 2014 at 08:53:06PM +0200, Robert Raszuk wrote: > Jeff, > > > My current thinking is that add-path - within the RR hierarchy only > > Just for clarity this is what I proposed earlier. I never seen a need to > run RTC SAFI with add-paths to the PEs. Ah, that detail wasn't clear to me. If you similarly made observations about shutting off the games with path attributes in the hierarchy, we're 100% in agreement. :-) -- Jeff From nobody Mon Jun 30 12:04:16 2014 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 EC8C31A0378 for ; Mon, 30 Jun 2014 12:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_X9B7JRZtNS for ; Mon, 30 Jun 2014 12:04:11 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C245E1A02E9 for ; Mon, 30 Jun 2014 12:04:11 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id tp5so7208089ieb.22 for ; Mon, 30 Jun 2014 12:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WnGOPsNPOm7latEucHbtnSk+irUYAvTyRBol/ZJT0lA=; b=JsuiVlvWOIKayTfaPSSMeXKO2LodNr8l8773942tcnlMfWiObC0xe4M0KEuWPjFjMY MKGpZhAwJPBbSh5KLifY4nvBEDRBOvrtL37uQpRFpX2CnQG6yQ7jiJ4XB8mmb/+Zv7fc +7Bjf1mKzD43XnikmDzA2vTbA09Ei+GrYXgHRgCvt9DZe6y4+KwRo8jFgvjwcCQH5yxJ t5oDcA/0TYKPoYuKVLjI1w0GYdWSi4SD8844kuaIa1hb4ihQ01ZsDgTB2J/51i72pwi/ pGHbgC543DFMXxj25miTnWuTnpb6HD/QwljPgWrwQp0/0eOtD1pt3PxdVoRIVxAlcM9B YAxw== MIME-Version: 1.0 X-Received: by 10.42.240.20 with SMTP id ky20mr3914513icb.97.1404155051071; Mon, 30 Jun 2014 12:04:11 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Mon, 30 Jun 2014 12:04:10 -0700 (PDT) In-Reply-To: <20140630185738.GD11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> <20140630184522.GC11842@pfrc> <20140630185738.GD11842@pfrc> Date: Mon, 30 Jun 2014 21:04:10 +0200 X-Google-Sender-Auth: exsV8CbGouD-hY16iQf_leh-ckA Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a113328f207876f04fd12538d Archived-At: http://mailarchive.ietf.org/arch/msg/idr/edcVVmJYW6tJaS-bHkXbUs9niSI Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 19:04:13 -0000 --001a113328f207876f04fd12538d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 30, 2014 at 8:57 PM, Jeffrey Haas wrote: > On Mon, Jun 30, 2014 at 08:53:06PM +0200, Robert Raszuk wrote: > > Jeff, > > > > > My current thinking is that add-path - within the RR hierarchy only > > > > Just for clarity this is what I proposed earlier. I never seen a need t= o > > run RTC SAFI with add-paths to the PEs. > > Ah, that detail wasn't clear to me. If you similarly made observations > about shutting off the games with path attributes in the hierarchy, > we're 100% in agreement. :-) > =E2=80=8BIndeed - no games with attributes is desired. Note I also made an observation that we could make this work with today's shipping RTC alone by sending default RT from top RRs to lower RRs. Someone claimed that it would need to be colored and suppressed from being send to PEs however most PEs I know do send all VPN routes to RRs they are peering with. So this would solve the issue we are facing too I believe. r. > > -- Jeff > --001a113328f207876f04fd12538d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 30, 2014 at 8:57 PM, Jeffrey Haas <= span dir=3D"ltr"><jh= aas@pfrc.org> wrote:
On Mon, Jun 30, 2014 at 08:5= 3:06PM +0200, Robert Raszuk wrote:
> Jeff,
>
> > My current thinking is that add-path - within the RR hierarchy on= ly
>
> Just for clarity this is what I proposed earlier. I never seen a need = to
> run RTC SAFI with add-paths to the PEs.

Ah, that detail wasn't clear to me. =C2=A0If you similarly made o= bservations
about shutting off the games with path attributes in the hierarchy,
we're 100% in agreement. :-)


=E2=80=8BIndeed - no games with attributes= is desired.=C2=A0

Note I also made = an observation that we could make this work with today's shipping RTC a= lone by sending default RT from top RRs to lower RRs.=C2=A0

Someone claimed t= hat it would need to be colored and suppressed from being send to PEs howev= er most PEs I know do send all VPN routes to RRs they are peering with. So = this would solve the issue we are facing too I believe.

r.







=C2=A0

-- Jeff

--001a113328f207876f04fd12538d-- From nobody Mon Jun 30 14:00:29 2014 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 6681C1A02FF for ; Mon, 30 Jun 2014 14:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 c3mNANG1cK5r for ; Mon, 30 Jun 2014 14:00:27 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD611A00DB for ; Mon, 30 Jun 2014 14:00:27 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 17A76C3F4; Mon, 30 Jun 2014 17:00:27 -0400 (EDT) Date: Mon, 30 Jun 2014 17:00:27 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140630210026.GE11842@pfrc> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> <20140630184522.GC11842@pfrc> <20140630185738.GD11842@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/e2N5JZvuEwdgYxfOnA3LwDF40bA Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 21:00:28 -0000 On Mon, Jun 30, 2014 at 09:04:10PM +0200, Robert Raszuk wrote: > ???Indeed - no games with attributes is desired. Ok. In that case we have a proposal and just need to wait until the relevant holes are poked in it. > Note I also made an observation that we could make this work with today's > shipping RTC alone by sending default RT from top RRs to lower RRs. > > Someone claimed that it would need to be colored and suppressed from being > send to PEs That would have been me. > however most PEs I know do send all VPN routes to RRs they are > peering with. So this would solve the issue we are facing too I believe. Depends on the deployment, especially for people who like "planes" of RRs. What's sort of interesting is that if the presumption is bulit-in that add-path must be part of the solution, an add-path default RT-C route with no-advertise might help. -- Jeff From nobody Mon Jun 30 17:29:32 2014 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 5A04E1A0388 for ; Mon, 30 Jun 2014 17:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DTaBSO0aHWe for ; Mon, 30 Jun 2014 17:29:27 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01AA1A01DC for ; Mon, 30 Jun 2014 17:29:26 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wp18so9788317obc.28 for ; Mon, 30 Jun 2014 17:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qcAQ37/RqDi0g5vcsyqXEcGGUrIBs7c/sg1FkSXo7Ak=; b=T3Ma+Hd3PaOEY24y9alCTFbpU8LcRXcqkfLfZMlYb9TrxDmMF08wB+6d8/BkffJkew SAXxtzTfZ6uXY9w4zfLWA/rmw1viaruaPFwXZEWp4Xxl9sFCNSQ8vSimjyp0uyo2hg+Q hA164QtEzgXBQ0zaaYbI3qImem5YYkdhtEME/68dXBN8sOFYsAa89n0ao58yRmJWW5/b XKp02jzHekOAuknvnbLxvmamsFdaN/ywSHKQJ4dhcnxvL0ceP7tq6A6AdgAmKuQBedfO jOPXkySYN7/c+vFqMC4RdJ7yUg34ND1EayLoodgr4zHl2sb3zBCH2VL8N5ZiFqFJGHgE yUhQ== MIME-Version: 1.0 X-Received: by 10.182.115.199 with SMTP id jq7mr7225776obb.70.1404174564761; Mon, 30 Jun 2014 17:29:24 -0700 (PDT) Received: by 10.76.113.238 with HTTP; Mon, 30 Jun 2014 17:29:24 -0700 (PDT) In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> References: <76CD132C3ADEF848BD84D028D243C9273367E4F4@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7CEA@EX01.swan.local> <61DC6BC4ABA10E4489D4A73EBABAC18B019C7D2A@EX01.swan.local> <76CD132C3ADEF848BD84D028D243C9273369B6B9@nkgeml512-mbx.china.huawei.com> <61DC6BC4ABA10E4489D4A73EBABAC18B019C8B0C@EX01.swan.local> Date: Mon, 30 Jun 2014 17:29:24 -0700 Message-ID: From: Shyam Sethuram To: =?UTF-8?Q?Vitkovsk=C3=BD_Adam?= Content-Type: multipart/alternative; boundary=047d7b67812022a3b104fd16de02 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/l72yOwb9354uOwjVtG3-HSp9KNg Cc: Robert Raszuk , "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 00:29:29 -0000 --047d7b67812022a3b104fd16de02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > In order to start learning the NRLIs RR has to advertise a desire to receive them and to do that we can use modified rule 3.2.ii. > > When advertising an RT membership NLRI to a client peer, if > the best path as selected by the path selection procedure > described in Section 9.1 of the base BGP specification [4] is a > route received from that client peer in particular, and if there is an > alternative path to the same destination from another client or a non-client, the > attributes of the other path are advertised to the peer. > > Now thinking about it only one rule for reflection of RT membership NLRI is enough I guess. > If you received RT membership NLRI from only one peer don't advertise it until you have received the RT membership NLRI with the same RT from another peer. > Then you can advertise the alternate (not the one that the peer sent you) RT membership NLRI to a given peer (simple split horizon). This sounds like best-external advertisement ? (Section 5, draft-ietf-idr-best-external-05) shyam On Fri, Jun 27, 2014 at 4:52 AM, Vitkovsk=C3=BD Adam wrote: > Hi folks, > > Regarding the rule 3.2.i of RFC4684. > > First consider scenario a): > a) > RR----PE1 > > Why would I want the RR to learn the PE's prefixes if there's no one > interested in them (no other clients interested to receive NRLI for given > RTs) as PE1 is the only one that advertised the Route Target membership > information to RR. > > Now let's consider scenario b): > b) > PE2----RR----PE1 > > Now there is another client (PE2) connected to the RR and it happens to b= e > interested in receiving NRLI for a given RT as designated by the advertis= ed > Route Target membership information for the given RT. > Ok now that there are interested receivers for a given NRLI on both > sessions - RR should start learning the NRLIs from clients so that it can > disseminate the information accordingly. > > In order to start learning the NRLIs RR has to advertise a desire to > receive them and to do that we can use modified rule 3.2.ii. > > When advertising an RT membership NLRI to a client peer, if > the best path as selected by the path selection procedure > described in Section 9.1 of the base BGP specification [4] is a > route received from that client peer in particular, and if there > is an > alternative path to the same destination from another client or a > non-client, the > attributes of the other path are advertised to the peer. > > Now thinking about it only one rule for reflection of RT membership NLRI > is enough I guess. > If you received RT membership NLRI from only one peer don't advertise it > until you have received the RT membership NLRI with the same RT from > another peer. > Then you can advertise the alternate (not the one that the peer sent you) > RT membership NLRI to a given peer (simple split horizon). > > Then there's no need to modify the update so that it can be accepted by > the originator (as in 3.2.i.). > And this also solves the hierarchical RR problem as well. > > > I'd like the think of it as with multicast flow where RR is like RP and > PEs are like Sources + Receivers. > There's no need for the RP (RR) to receive the mcast stream (e.g. VPN > Prefixes) when there's just one Source/Receiver (PE) connected to it. > A simple state on the RP saying there is a particular stream available at > this particular source is enough (i.e. RT membership NLRI on RR). > Once other source/receivers (PEs) are connected to the RP(RR) and signal > their desire to receive the stream (via RT membership NLRI). > Then RP (RR) decides the desire receive the stream (RT membership NLRI) i= s > worth spreading and disseminates the information to the interested > sources/receivers (PEs). > Once that happens sources/receivers (PEs) will start sending the mcast > stream (e.g. VPN Prefixes) towards the RP (RR) which than reflects this > mcase streams to all interested sources/receivers (PEs). > > > I believe the concerns presented in draft-dong-idr-rtc-hierarchical-rr-00 > could be resolved by add-path where at least one additional path is > advertised along with the best-path. > But still rule 3.2.i. in RFC4684 is very harmful in scenarios where RRs > are clients of other RRs (same level or different level). > > > > adam > > > > -----Original Message----- > > From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com] > > Sent: Monday, June 23, 2014 4:59 AM > > To: Vitkovsk=C3=BD Adam; Robert Raszuk > > Cc: idr@ietf.org > > Subject: RE: [Idr] New Version Notification for > draft-dong-idr-rtc-hierarchical- > > rr-00.txt > > > > Hi Adam, > > > > If RD is part of the RTC routes, this problem will not occur:) While as > analyzed > > in rfc 4684, this requires more RTC routes being exchanged and kept in > the > > local AS. > > > > I agree that add-path is a candidate solution to this problem, while wh= en > > enabling add-path on RTC AFI/SAFI, we still need to specify the rules o= f > which > > RTC routes should be advertised to solve this problem. Or we just updat= e > the > > rules of RTC advertisement as the other RTC related new drafts? > > > > Many thanks, > > Jie > > > > > -----Original Message----- > > > From: Vitkovsk=C3=BD Adam [mailto:adam.vitkovsky@swan.sk] > > > Sent: Sunday, June 22, 2014 3:20 AM > > > To: Robert Raszuk > > > Cc: Dongjie (Jimmy); idr@ietf.org > > > Subject: RE: [Idr] New Version Notification for > > > draft-dong-idr-rtc-hierarchical-rr-00.txt > > > > > > Aah I see :) > > > Well we could have that one solved if RD would be part of the RTC > > > routes :) (though I understand one could use RTC for non VPN routes a= s > > > well so...) Anyways so than as you mentioned add-path on the RTC AF > > > seems as the best option then. > > > > > > adam > > > > -----Original Message----- > > > > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of > > > > Robert Raszuk > > > > Sent: Saturday, June 21, 2014 7:52 PM > > > > To: Vitkovsk=C3=BD Adam > > > > Cc: Dongjie (Jimmy); idr@ietf.org > > > > Subject: Re: [Idr] New Version Notification for > > > > draft-dong-idr-rtc-hierarchical- rr-00.txt > > > > > > > > Hi Adam, > > > > > > > > Jie is describing RT routes not VPN routes. Your story does not > > > > apply to RT routes as format of RT NLRI is well defined by RFC ;) > > > > > > > > Besides MPLS network or not has nothing to do with it .... > > > > > > > > Best, > > > > R. > > > > > > > > On Sat, Jun 21, 2014 at 7:19 PM, Vitkovsk=C3=BD Adam > > > > > > > > wrote: > > > > > Hi Jie, > > > > > Well the correctly designed MPLS networks use unique per PE per > > > > > VRF RDs > > > > in form of RID:xxxxx. > > > > > Unique per PE RDs makes all copies of the same VPN prefix receive= d > > > > > from > > > > different PEs unique so RRs will select all as best path and > > > > distribute them accordingly, which solves this and many other issue= s. > > > > > > > > > > In other words if someone tries to shoot himself in the foot I > > > > > wouldn't > > > > develop bulletproof boots for him. > > > > > > > > > > adam > > > > >> -----Original Message----- > > > > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie > > > > >> (Jimmy) > > > > >> Sent: Friday, June 20, 2014 4:55 AM > > > > >> To: idr@ietf.org > > > > >> Subject: [Idr] FW: New Version Notification for > > > > >> draft-dong-idr-rtc- hierarchical-rr-00.txt > > > > >> > > > > >> Hi all, > > > > >> > > > > >> This is a short draft to make RTC applicable in hierarchical RR > scenario. > > > > >> > > > > >> Comments are welcome. > > > > >> > > > > >> Best regards, > > > > >> Jie > > > > >> > > > > >> > -----Original Message----- > > > > >> > > > > > >> > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.tx= t > > > > >> > has been successfully submitted by Jie Dong and posted to the > > > > >> > IETF > > > > >> repository. > > > > >> > > > > > >> > Name: draft-dong-idr-rtc-hierarchical-rr > > > > >> > Revision: 00 > > > > >> > Title: Extensions to RT-Constrain in Hierarchical > Route > > > Reflection > > > > >> > Scenarios > > > > >> > Document date: 2014-06-19 > > > > >> > Group: Individual Submission > > > > >> > Pages: 5 > > > > >> > URL: > > > > >> > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarc= h > > > > >> > ic > > > > >> > al > > > > >> > -rr > > > > >> > -00.txt > > > > >> > Status: > > > > >> > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchic= a > > > > >> > l- > > > > >> > rr > > > > >> > / > > > > >> > Htmlized: > > > > >> > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-= 0 > > > > >> > 0 > > > > >> > > > > > >> > > > > > >> > Abstract: > > > > >> > The Route Target (RT) Constrain mechanism specified in RFC > 4684 is > > > > >> > used to build a route distribution graph in order to > restrict the > > > > >> > propagation of Virtual Private Network (VPN) routes. In > network > > > > >> > scenarios where hierarchical route reflection (RR) is used, > the > > > > >> > existing RT-Constrain mechanism cannot build a correct rout= e > > > > >> > distribution graph. This document refines the route > distribution > > > > >> > rules of RT-Constrain to address the hierarchical RR > scenarios. > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > Please note that it may take a couple of minutes from the time > > > > >> > of submission until the htmlized version and diff are availabl= e > > > > >> > at > > > > tools.ietf.org. > > > > >> > > > > > >> > The IETF Secretariat > > > > >> > > > > >> _______________________________________________ > > > > >> Idr mailing list > > > > >> Idr@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/idr > > > > > > > > > > _______________________________________________ > > > > > Idr mailing list > > > > > Idr@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7b67812022a3b104fd16de02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> In order to start learning the NR= LIs RR has to advertise a desire to receive them and to do that we can use = modified rule 3.2.ii.
>=C2=A0
> =C2=A0 =C2=A0 =C2= =A0 =C2=A0When advertising an RT membership NLRI to a client peer, if
> =C2=A0 =C2=A0 =C2=A0 =C2=A0the best path as selected by the path = selection procedure
> =C2=A0 =C2=A0 =C2=A0 =C2=A0described in = Section 9.1 of the base BGP specification [4] is a
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0route received from that client peer in particular, and= if there is an
> =C2=A0 =C2=A0 =C2=A0 =C2=A0alternative path to the same destinati= on from another client or a non-client, the
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0attributes of the other path are advertised to the peer.
=
>=C2=A0
> Now thinking about it only one rule for refl= ection of RT membership NLRI is enough I guess.
> If you received RT membership NLRI from only one peer don't a= dvertise it until you have received the RT membership NLRI with the same RT= from another peer.
> Then you can advertise the alternate (no= t the one that the peer sent you) RT membership NLRI to a given peer (simpl= e split horizon).

This sounds like best-external advertisement ?
(Section 5,=C2=A0draft-ietf-idr-best-external-05)

shyam


On Fri, Jun 27, 2014 at 4:52 AM, Vitkovsk=C3=BD Adam = <adam.vitkov= sky@swan.sk> wrote:
Hi folks,

Regarding the rule 3.2.i of RFC4684.

First consider scenario a):
a)
RR----PE1

Why would I want the RR to learn the PE's prefixes if there's no on= e interested in them (no other clients interested to receive NRLI for given= RTs) as PE1 is the only one that advertised the Route Target membership in= formation to RR.

Now let's consider scenario b):
b)
PE2----RR----PE1

Now there is another client (PE2) connected to the RR and it happens to be = interested in receiving NRLI for a given RT as designated by the advertised= Route Target membership information for the given RT.
Ok now that there are interested receivers for a given NRLI on both session= s - RR should start learning the NRLIs from clients so that it can dissemin= ate the information accordingly.

In order to start learning the NRLIs RR has to advertise a desire to receiv= e them and to do that we can use modified rule 3.2.ii.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 When advertising an RT membership NLRI to a cli= ent peer, if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the best path as selected by the path selection= procedure
=C2=A0 =C2=A0 =C2=A0 =C2=A0 described in Section 9.1 of the base BGP specif= ication [4] is a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 route received from that client peer in particu= lar, and if there is an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 alternative path to the same destination from a= nother client or a non-client, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes of the other path are advertised to = the peer.

Now thinking about it only one rule for reflection of RT membership NLRI is= enough I guess.
If you received RT membership NLRI from only one peer don't advertise i= t until you have received the RT membership NLRI with the same RT from anot= her peer.
Then you can advertise the alternate (not the one that the peer sent you) R= T membership NLRI to a given peer (simple split horizon).

Then there's no need to modify the update so that it can be accepted by= the originator (as in 3.2.i.).
And this also solves the hierarchical RR problem as well.


I'd like the think of it as with multicast flow where RR is like RP and= PEs are like Sources + Receivers.
There's no need for the RP (RR) to receive the mcast stream (e.g. VPN P= refixes) when there's just one Source/Receiver (PE) connected to it. A simple state on the RP saying there is a particular stream available at t= his particular source is enough (i.e. RT membership NLRI on RR).
Once other source/receivers (PEs) are connected to the RP(RR) and signal th= eir desire to receive the stream (via RT membership NLRI).
Then RP (RR) decides the desire receive the stream (RT membership NLRI) is = worth spreading and disseminates the information to the interested sources/= receivers (PEs).
Once that happens sources/receivers (PEs) will start sending the mcast stre= am (e.g. VPN Prefixes) towards the RP (RR) which than reflects this mcase s= treams to all interested sources/receivers (PEs).


I believe the concerns presented in draft-dong-idr-rtc-hierarchical-rr-00 c= ould be resolved by add-path where at least one additional path is advertis= ed along with the best-path.
But still rule 3.2.i. in RFC4684 is very harmful in scenarios where RRs are= clients of other RRs (same level or different level).



=C2=A0adam


> -----Original Message-----
> From: Dongjie (Jimmy) [mailto:j= ie.dong@huawei.com]
> Sent: Monday, June 23, 2014 4:59 AM
> To: Vitkovsk=C3=BD Adam; Robert Raszuk
> Cc: idr@ietf.org
> Subject: RE: [Idr] New Version Notification for draft-dong-idr-rtc-hie= rarchical-
> rr-00.txt
>
> Hi Adam,
>
> If RD is part of the RTC routes, this problem will not occur:) While a= s analyzed
> in rfc 4684, this requires more RTC routes being exchanged and kept in= the
> local AS.
>
> I agree that add-path is a candidate solution to this problem, while w= hen
> enabling add-path on RTC AFI/SAFI, we still need to specify the rules = of which
> RTC routes should be advertised to solve this problem. Or we just upda= te the
> rules of RTC advertisement as the other RTC related new drafts?
>
> Many thanks,
> Jie
>
> > -----Original Message-----
> > From: Vitkovsk=C3=BD Adam [mailto:adam.vitkovsky@swan.sk]
> > Sent: Sunday, June 22, 2014 3:20 AM
> > To: Robert Raszuk
> > Cc: Dongjie (Jimmy); idr@ietf.org=
> > Subject: RE: [Idr] New Version Notification for
> > draft-dong-idr-rtc-hierarchical-rr-00.txt
> >
> > Aah I see :)
> > Well we could have that one solved if RD would be part of the RTC=
> > routes :) (though I understand one could use RTC for non VPN rout= es as
> > well so...) Anyways so than as you mentioned add-path on the RTC = AF
> > seems as the best option then.
> >
> > adam
> > > -----Original Message-----
> > > From: rraszuk@gmail.com= [mailto:rraszuk@gmail.com] On= Behalf Of
> > > Robert Raszuk
> > > Sent: Saturday, June 21, 2014 7:52 PM
> > > To: Vitkovsk=C3=BD Adam
> > > Cc: Dongjie (Jimmy); idr@iet= f.org
> > > Subject: Re: [Idr] New Version Notification for
> > > draft-dong-idr-rtc-hierarchical- rr-00.txt
> > >
> > > Hi Adam,
> > >
> > > Jie is describing RT routes not VPN routes. Your story does = not
> > > apply to RT routes as format of RT NLRI is well defined by R= FC ;)
> > >
> > > Besides MPLS network or not has nothing to do with it .... > > >
> > > Best,
> > > R.
> > >
> > > On Sat, Jun 21, 2014 at 7:19 PM, Vitkovsk=C3=BD Adam
> > > <adam.vitkovsky= @swan.sk>
> > > wrote:
> > > > Hi Jie,
> > > > Well the correctly designed MPLS networks use unique pe= r PE per
> > > > VRF RDs
> > > in form of RID:xxxxx.
> > > > Unique per PE RDs makes all copies of the same VPN pref= ix received
> > > > from
> > > different PEs unique so RRs will select all as best path and=
> > > distribute them accordingly, which solves this and many othe= r issues.
> > > >
> > > > In other words if someone tries to shoot himself in the= foot I
> > > > wouldn't
> > > develop bulletproof boots for him.
> > > >
> > > > adam
> > > >> -----Original Message-----
> > > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Dongjie
> > > >> (Jimmy)
> > > >> Sent: Friday, June 20, 2014 4:55 AM
> > > >> To: idr@ietf.org
> > > >> Subject: [Idr] FW: New Version Notification for
> > > >> draft-dong-idr-rtc- hierarchical-rr-00.txt
> > > >>
> > > >> Hi all,
> > > >>
> > > >> This is a short draft to make RTC applicable in hie= rarchical RR scenario.
> > > >>
> > > >> Comments are welcome.
> > > >>
> > > >> Best regards,
> > > >> Jie
> > > >>
> > > >> > -----Original Message-----
> > > >> >
> > > >> > A new version of I-D, draft-dong-idr-rtc-hiera= rchical-rr-00.txt
> > > >> > has been successfully submitted by Jie Dong an= d posted to the
> > > >> > IETF
> > > >> repository.
> > > >> >
> > > >> > Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 draft-dong-idr-rtc-hierarchical-rr
> > > >> > Revision: =C2=A0 00
> > > >> > Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Extensions to RT-Constrain in Hierarchical Route
> > Reflection
> > > >> > Scenarios
> > > >> > Document date: =C2=A0 =C2=A0 =C2=A02014-06-19<= br> > > > >> > Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Individual Submission
> > > >> > Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A05
> > > >> > URL:
> > > >> > http://www.ietf.org/interne= t-drafts/draft-dong-idr-rtc-hierarch
> > > >> > ic
> > > >> > al
> > > >> > -rr
> > > >> > -00.txt
> > > >> > Status:
> > > >> > https://datatracker.ietf.or= g/doc/draft-dong-idr-rtc-hierarchica
> > > >> > l-
> > > >> > rr
> > > >> > /
> > > >> > Htmlized:
> > > >> > http://tools.ietf.org/html/= draft-dong-idr-rtc-hierarchical-rr-0
> > > >> > 0
> > > >> >
> > > >> >
> > > >> > Abstract:
> > > >> > =C2=A0 =C2=A0The Route Target (RT) Constrain m= echanism specified in RFC 4684 is
> > > >> > =C2=A0 =C2=A0used to build a route distributio= n graph in order to restrict the
> > > >> > =C2=A0 =C2=A0propagation of Virtual Private Ne= twork (VPN) routes. =C2=A0In network
> > > >> > =C2=A0 =C2=A0scenarios where hierarchical rout= e reflection (RR) is used, the
> > > >> > =C2=A0 =C2=A0existing RT-Constrain mechanism c= annot build a correct route
> > > >> > =C2=A0 =C2=A0distribution graph. =C2=A0This do= cument refines the route distribution
> > > >> > =C2=A0 =C2=A0rules of RT-Constrain to address = the hierarchical RR scenarios.
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > Please note that it may take a couple of minut= es from the time
> > > >> > of submission until the htmlized version and d= iff are available
> > > >> > at
> > > tools.ie= tf.org.
> > > >> >
> > > >> > The IETF Secretariat
> > > >>
> > > >> _______________________________________________
> > > >> Idr mailing list
> > > >> Idr@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/idr
> > > >
> > > > _______________________________________________
> > > > Idr mailing list
> > > > Idr@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7b67812022a3b104fd16de02--