From nobody Wed Jun 1 03:02:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D20912D0F3 for ; Wed, 1 Jun 2016 03:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LS5U9uH1C8Vf for ; Wed, 1 Jun 2016 03:02:02 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B2512D096 for ; Wed, 1 Jun 2016 03:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2173; q=dns/txt; s=iport; t=1464775322; x=1465984922; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=UpR7XXWM9neCukFUOLintJav5IPVC2twim2EyyC2p2U=; b=AKqD2wWYW/7E0kVkpzkwNDAK8lEesmhF0P/8THsP3p/kjD5qZzzb3ZwP l/l2jaH1s85NeS2oDWkx4DoJ7FwjOzh7uN1lWsWAFeuRmrmJmiYCPFbiF fD8xKU+O9dwyAX/icSq+wnZ/1zHREsjKCSG4By1pE5Oq9KY7PdpNZk7xn M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AwC/sU5X/5ldJa1bgz1WfQauH4tvA?= =?us-ascii?q?Q2BeiSHGTgUAQEBAQEBAWUnhEUBAQQBOj0SAgEZAwECHxAhERsCCAIEE4gVAw8?= =?us-ascii?q?IDrwgDYQfAQEBAQEBAQMBAQEBAQEBAQEehieBdwiCToJDhSmCLgWNZYofMwGFf?= =?us-ascii?q?4J4gy+BeYFpToQBiGSGM4Exh2cBHgEBQoIGHBaBNW4BiTd/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,400,1459814400"; d="scan'208";a="279417248" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2016 10:02:01 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u51A20bF032172 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 1 Jun 2016 10:02:01 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 1 Jun 2016 06:02:00 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Wed, 1 Jun 2016 06:02:00 -0400 From: "Stefano Previdi (sprevidi)" To: idr wg Thread-Topic: New Version Notification for draft-gredler-idr-bgp-ls-segment-routing-ext-02.txt Thread-Index: AQHRu+v7UF4H67u1O0es2dVEuK1PzQ== Date: Wed, 1 Jun 2016 10:02:00 +0000 Message-ID: References: <20160601095714.16179.29074.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.89.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <468E6C5A8BA3C745B3251B470EB8738E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Idr] Fwd: New Version Notification for draft-gredler-idr-bgp-ls-segment-routing-ext-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 10:02:04 -0000 This is an update with the addition of the IPv6 Prefix-SID TLV. Also, the authors believe this draft is ready for WG adoption, also due to = multiple existing implementations. Thanks. s. >=20 > From: > Subject: New Version Notification for draft-gredler-idr-bgp-ls-segment-ro= uting-ext-02.txt > Date: June 1, 2016 at 11:57:14 AM GMT+2 > To: Mach Chen , "Mach Chen (Guoyi)" , "jefftant@gmail.com" , "Hannes Gredler" , Clarence Filsfils , Stefano Previdi , Peter Psenak , Jeff Tantsura >=20 >=20 > A new version of I-D, draft-gredler-idr-bgp-ls-segment-routing-ext-02.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-gredler-idr-bgp-ls-segment-routing-ext > Revision: 02 > Title: BGP Link-State extensions for Segment Routing > Document date: 2016-06-01 > Group: Individual Submission > Pages: 32 > URL: https://www.ietf.org/internet-drafts/draft-gredler-idr-bg= p-ls-segment-routing-ext-02.txt > Status: https://datatracker.ietf.org/doc/draft-gredler-idr-bgp-ls= -segment-routing-ext/ > Htmlized: https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segm= ent-routing-ext-02 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-gredler-idr-bgp= -ls-segment-routing-ext-02 >=20 > Abstract: > Segment Routing (SR) allows for a flexible definition of end-to-end > paths within IGP topologies by encoding paths as sequences of > topological sub-paths, called "segments". These segments are > advertised by the link-state routing protocols (IS-IS, OSPF and > OSPFv3). >=20 > This draft defines extensions to the BGP Link-state address-family in > order to carry segment information via BGP. >=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 >=20 From nobody Wed Jun 1 03:51:11 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B4612D098; Wed, 1 Jun 2016 03:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3ueIJjvdKn8; Wed, 1 Jun 2016 03:51:04 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1028512B027; Wed, 1 Jun 2016 03:51:04 -0700 (PDT) Received: by seele.lamehost.it (Postfix, from userid 33) id 570F574401; Wed, 1 Jun 2016 12:51:02 +0200 (CEST) To: Nick Hilliard X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Jun 2016 12:51:02 +0200 From: Marco Marzetti In-Reply-To: <574DB060.1000801@foobar.org> References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it> <574DB060.1000801@foobar.org> Message-ID: X-Sender: marco@lamehost.it User-Agent: Roundcube Webmail/1.1.5 Archived-At: Cc: Idr@ietf.org, ietf@ietf.org Subject: Re: [Idr] Last Call: (Internet Exchange BGP Route Server) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 10:51:06 -0000 On 2016-05-31 17:40, Nick Hilliard wrote: > Marco Marzetti wrote: >> Beside i agree on the most part of this draft i would like to >> underline >> how bullet 2.2.2 breaks the the nature of BGP itself. >> >> The exact part i am referring to is: >> """ >> As a route server does not participate in the process of forwarding >> data between client routers, and because modification of the >> AS_PATH >> attribute could affect route server client BGP Decision Process, >> the >> route server SHOULD NOT prepend its own AS number to the AS_PATH >> segment nor modify the AS_PATH segment in any other way. >> """ >> >> I firmly think that it really has to state "MUST NOT" instead of >> "SHOULD >> NOT". >> >> From a route-server client point of view that breaks the natural BGP >> best selection process and forces you to purely rely on >> LOCAL_PREFERENCE >> which in turns breaks your traffic engineering because it forces you >> to >> prefer/not-prefer the prefixes learned over the route server in place >> of >> those learned, for instance, over a private session or another IXP. > > It doesn't "break" the decision process mechanism. Localpref might be > ugly, but using it doesn't violate the bgp protocol. > > This statement needs to be "MUST NOT". Technically you can run a route > server even if you insert the intermediate ASN into the path. The only > absolute "MUST" is that you mustn't change the next-hop; otherwise you > end up with a router instead of a route server. > > RFC2119 is a pain because there is no way of differentiating between > "SHOULD NOT", meaning "on balance it would be a better idea not to do > X" > and "SHOULD NOT", meaning "if you even _think_ about doing X, you need > your head examined and the only reason we specified SHOULD NOT instead > of MUST NOT in this situation because of some technicality that > prevented us from doing so". The text in 2.2.2 veers slightly in the > direction of the latter interpretation. > > Nick Nick, I agree with you that you can run a route server and insert your ASn in the path, but i think that is a lack of common sense which brings only contraries and no benefits. About RFC2119: It says that "SHOULD NOT" implies a valid reason to accept a behavior, but i can't find any. Regards -- Marco From nobody Wed Jun 1 04:17:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BBA12D0BB; Wed, 1 Jun 2016 04:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYI18Qe6ILli; Wed, 1 Jun 2016 04:17:05 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE3912B027; Wed, 1 Jun 2016 04:17:04 -0700 (PDT) X-Envelope-To: Idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u51BH10j019777 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2016 12:17:01 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <574EC42C.3040500@foobar.org> Date: Wed, 01 Jun 2016 12:17:00 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Marco Marzetti References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it> <574DB060.1000801@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Idr@ietf.org, ietf@ietf.org Subject: Re: [Idr] Last Call: (Internet Exchange BGP Route Server) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 11:17:08 -0000 Marco Marzetti wrote: > I agree with you that you can run a route server and insert your ASn in > the path, but i think that is a lack of common sense which brings only > contraries and no benefits. > > About RFC2119: It says that "SHOULD NOT" implies a valid reason to > accept a behavior, but i can't find any. I agree that it is not a clever thing to do. The valid reason to accept the behaviour is that it works in practice: some IXPs have done this in production, in many cases for years. There is a secondary reason: some rs client bgp stacks don't support the option to accept an AS path from the RS where the leftmost entry on the AS path != peeras. These are not "good" reasons in the sense that they mandate behaviour which is suboptimal, but they are valid reasons. Nick From nobody Wed Jun 1 05:12:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AD112D190; Wed, 1 Jun 2016 05:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR7C5oVBBack; Wed, 1 Jun 2016 05:12:25 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6721D12D18F; Wed, 1 Jun 2016 05:12:24 -0700 (PDT) Received: by seele.lamehost.it (Postfix, from userid 33) id C5EFD74401; Wed, 1 Jun 2016 14:12:23 +0200 (CEST) To: Nick Hilliard X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Jun 2016 14:12:23 +0200 From: Marco Marzetti In-Reply-To: <574EC42C.3040500@foobar.org> References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it> <574DB060.1000801@foobar.org> <574EC42C.3040500@foobar.org> Message-ID: X-Sender: marco@lamehost.it User-Agent: Roundcube Webmail/1.1.5 Archived-At: Cc: Idr@ietf.org, ietf@ietf.org Subject: Re: [Idr] Last Call: (Internet Exchange BGP Route Server) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 12:12:28 -0000 On 2016-06-01 13:17, Nick Hilliard wrote: > Marco Marzetti wrote: >> I agree with you that you can run a route server and insert your ASn >> in >> the path, but i think that is a lack of common sense which brings only >> contraries and no benefits. >> >> About RFC2119: It says that "SHOULD NOT" implies a valid reason to >> accept a behavior, but i can't find any. > > I agree that it is not a clever thing to do. The valid reason to accept > the behaviour is that it works in practice: some IXPs have done this in > production, in many cases for years. > > There is a secondary reason: some rs client bgp stacks don't support > the > option to accept an AS path from the RS where the leftmost entry on the > AS path != peeras. > > These are not "good" reasons in the sense that they mandate behaviour > which is suboptimal, but they are valid reasons. > > Nick Nick, I think that we should define a standard that addresses and corrects those non-clever behaviors rather than embrace them. My point is: even if they work in the real world, they do because of the workarounds that other people put in place and they bring no benefits. Regards -- Marco From nobody Wed Jun 1 05:21:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC0412D18F; Wed, 1 Jun 2016 05:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bNsd0WAbizh; Wed, 1 Jun 2016 05:21:22 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C23112D184; Wed, 1 Jun 2016 05:21:22 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u51CLCZj014839 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2016 12:21:12 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u51CLBZO029275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2016 12:21:11 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u51CL8wr015603; Wed, 1 Jun 2016 12:21:10 GMT Received: from [21.9.110.26] (/172.56.35.57) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Jun 2016 05:21:08 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: David Huberman X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Wed, 1 Jun 2016 07:21:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it> <574DB060.1000801@foobar.org> <574EC42C.3040500@foobar.org> To: Marco Marzetti X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: Idr@ietf.org, ietf@ietf.org Subject: Re: [Idr] Last Call: (Internet Exchange BGP Route Server) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 12:21:24 -0000 Pardon the top post.=20 Marco, we do these things in the real world generally because we have to, no= t because we don't know any better. IX participants come in all kinds of fla= vors, and some have to turn some really weird BGP knobs to ensure everything= works. =20 I very much appreciate your position -- clean, optimal standards are a great= goal -- but real world operability is the true MUST HAVE of a standard. David > On Jun 1, 2016, at 7:12 AM, Marco Marzetti wrote: >=20 >> On 2016-06-01 13:17, Nick Hilliard wrote: >> Marco Marzetti wrote: >>> I agree with you that you can run a route server and insert your ASn in >>> the path, but i think that is a lack of common sense which brings only >>> contraries and no benefits. >>> About RFC2119: It says that "SHOULD NOT" implies a valid reason to >>> accept a behavior, but i can't find any. >> I agree that it is not a clever thing to do. The valid reason to accept >> the behaviour is that it works in practice: some IXPs have done this in >> production, in many cases for years. >> There is a secondary reason: some rs client bgp stacks don't support the >> option to accept an AS path from the RS where the leftmost entry on the >> AS path !=3D peeras. >> These are not "good" reasons in the sense that they mandate behaviour >> which is suboptimal, but they are valid reasons. >> Nick >=20 > Nick, >=20 > I think that we should define a standard that addresses and corrects those= non-clever behaviors rather than embrace them. >=20 > My point is: even if they work in the real world, they do because of the w= orkarounds that other people put in place and they bring no benefits. >=20 > Regards >=20 > --=20 > Marco >=20 From nobody Wed Jun 1 05:36:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2893012D1BE; Wed, 1 Jun 2016 05:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_cT_XxzofhP; Wed, 1 Jun 2016 05:35:52 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F07112D194; Wed, 1 Jun 2016 05:35:47 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id s64so11871567lfe.0; Wed, 01 Jun 2016 05:35:47 -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; bh=ITiN11Fem0OvwowyqX3LJ5CBFvit+9u11+Bg3YarUpE=; b=cx27ORTA2hqNtA7MoBLJvFbhmqx6hUPjsfAfftd9K/dKGtqEH1kfNJDzPYYPnc/Nhj mVgEh2mvLO7AATvINRm2ET21O+zrhS26MUHUJ1DsdLtGpfklMEN1T9l1KNZxzUq6FxnL xGV0DydDTc/tNF1nnKLC6pia14c8wRZwk72/r09bkN3VHL6Mf9WVP1JGlfnHl9/uNf+4 xptpcQnpwgZwtOy4KBtdoCtLQH/xrrciW9G6+/4457hM0IR/j6MOFU7wr6GLrxsA//5c /xknT6DJNj+oX55S08L7/B78CAwe9sHV3PRKe9fsVK4XqYvGEkQjTMMLrrOKMXc90S72 mM8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ITiN11Fem0OvwowyqX3LJ5CBFvit+9u11+Bg3YarUpE=; b=FtechE4JcYlLLvWE+DYPXSXG5WeSdAbN2baiJm2DVL3PfX2fW1hDQqj5XIwsSIer5n WBqBq8x6JT+uOPVkQDTQmqTV6mBexOQQGo1taaIBIGkp5iOcb2mFeg6QfREVPv1svsu1 THaI16JxKMIaG4LP09lTlh2/tT5TCMkyEF6dZnEoqzSs8rWgw8X831OrMWxT1vambMBh 23+/zI7TcPihQKyYc/Air28Y6goxiP8fDCjZgiCrjj2tr1ZYmUsCZ3tPjO2UztJLRkdE GQQZCs/WkCrqNmebWUxIoXIBdKPNDSuXr5o2vTAQ5hLu7YUex2RGWzaf3sc3HZhSiTZV TuKA== X-Gm-Message-State: ALyK8tI/xebNyQNYIUbQebyBzRB3rqO73/5AVUMAMevGji+CdFyuCkgnkqHRtu7bcSex2cxoIv7Z96hS/TVSrg== MIME-Version: 1.0 X-Received: by 10.46.5.145 with SMTP id 139mr1522605ljf.9.1464784545708; Wed, 01 Jun 2016 05:35:45 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Wed, 1 Jun 2016 05:35:45 -0700 (PDT) In-Reply-To: References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it> <574DB060.1000801@foobar.org> <574EC42C.3040500@foobar.org> Date: Wed, 1 Jun 2016 14:35:45 +0200 X-Google-Sender-Auth: 4awnEiv_Uk8EJBE3RRUCDOZg4TI Message-ID: From: Robert Raszuk To: Marco Marzetti Content-Type: multipart/alternative; boundary=001a114a8a1c84fdef053436baa3 Archived-At: Cc: idr wg , IETF Discussion Subject: Re: [Idr] Last Call: (Internet Exchange BGP Route Server) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 12:35:54 -0000 --001a114a8a1c84fdef053436baa3 Content-Type: text/plain; charset=UTF-8 Hi Marco, Let's also observe that route server we are defining here which effectively "reflects" between EBGP sessions has much more wider use then Internet Exchange points. There is more architectures which use EBGP and for scale full meshing them is a headache (at least till we progress the auto discovery proposal further). And some of those ASes may be private hence inserting your AS during private removal is rather a must. I would recommend that we focus on the recommendation how to build IX in the companion draft in GROW. Here in IDR we should rather accommodate all use cases. Many thx, Robert On Wed, Jun 1, 2016 at 2:12 PM, Marco Marzetti wrote: > On 2016-06-01 13:17, Nick Hilliard wrote: > >> Marco Marzetti wrote: >> >>> I agree with you that you can run a route server and insert your ASn in >>> the path, but i think that is a lack of common sense which brings only >>> contraries and no benefits. >>> >>> About RFC2119: It says that "SHOULD NOT" implies a valid reason to >>> accept a behavior, but i can't find any. >>> >> >> I agree that it is not a clever thing to do. The valid reason to accept >> the behaviour is that it works in practice: some IXPs have done this in >> production, in many cases for years. >> >> There is a secondary reason: some rs client bgp stacks don't support the >> option to accept an AS path from the RS where the leftmost entry on the >> AS path != peeras. >> >> These are not "good" reasons in the sense that they mandate behaviour >> which is suboptimal, but they are valid reasons. >> >> Nick >> > > Nick, > > I think that we should define a standard that addresses and corrects those > non-clever behaviors rather than embrace them. > > My point is: even if they work in the real world, they do because of the > workarounds that other people put in place and they bring no benefits. > > Regards > > -- > Marco > > --001a114a8a1c84fdef053436baa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Marco,

<= /div>
Let's also observe that route server we are def= ining here which effectively "reflects" between EBGP sessions has= much more wider use then Internet Exchange points.=C2=A0

There is more architectures which use= EBGP and for scale full meshing them is a headache (at least till we progr= ess the auto discovery proposal further). And some of those ASes may be pri= vate hence inserting your AS during private removal is rather a must.=C2=A0=

I would recommend tha= t we focus on the recommendation how to build IX in the companion draft in = GROW. Here in IDR we should rather accommodate all use cases.

Many thx,
Robert


On Wed, Jun 1, 2016 at 2:12 PM, Marco Marzetti &l= t;marco@lamehost.it<= /a>> wrote:
On= 2016-06-01 13:17, Nick Hilliard wrote:
Marco Marzetti wrote:
I agree with you that you can run a route server and insert your ASn in
the path, but i think that is a lack of common sense which brings only
contraries and no benefits.

About RFC2119: It says that "SHOULD NOT" implies a valid reason t= o
accept a behavior, but i can't find any.

I agree that it is not a clever thing to do. The valid reason to accept
the behaviour is that it works in practice: some IXPs have done this in
production, in many cases for years.

There is a secondary reason: some rs client bgp stacks don't support th= e
option to accept an AS path from the RS where the leftmost entry on the
AS path !=3D peeras.

These are not "good" reasons in the sense that they mandate behav= iour
which is suboptimal, but they are valid reasons.

Nick

 Nick,

I think that we should define a standard that addresses and corrects those = non-clever behaviors rather than embrace them.

My point is: even if they work in the real world, they do because of the wo= rkarounds that other people put in place and they bring no benefits.

Regards

--
Marco


--001a114a8a1c84fdef053436baa3-- From nobody Wed Jun 1 05:46:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4459412D1B8; Wed, 1 Jun 2016 05:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC-EtZc35c8h; Wed, 1 Jun 2016 05:46:20 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id E327D12D194; Wed, 1 Jun 2016 05:46:19 -0700 (PDT) Received: by seele.lamehost.it (Postfix, from userid 33) id 21C6A74401; Wed, 1 Jun 2016 14:46:19 +0200 (CEST) To: Robert Raszuk X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Jun 2016 14:46:19 +0200 From: Marco Marzetti In-Reply-To: References: <20160524224341.14017.96672.idtracker@ietfa.amsl.com> <6b69a7e81790d6bae23d39ea44ccb01f@lamehost.it> <574DB060.1000801@foobar.org> <574EC42C.3040500@foobar.org> Message-ID: <2ac9d4bb4775263e032842f21b4c8243@lamehost.it> X-Sender: marco@lamehost.it User-Agent: Roundcube Webmail/1.1.5 Archived-At: Cc: idr wg , rraszuk@gmail.com, IETF Discussion Subject: Re: [Idr] Last Call: (Internet Exchange BGP Route Server) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 12:46:21 -0000 On 2016-06-01 14:35, Robert Raszuk wrote: > Hi Marco, > > Let's also observe that route server we are defining here which > effectively "reflects" between EBGP sessions has much more wider use > then Internet Exchange points. > > There is more architectures which use EBGP and for scale full meshing > them is a headache (at least till we progress the auto discovery > proposal further). And some of those ASes may be private hence > inserting your AS during private removal is rather a must. > > I would recommend that we focus on the recommendation how to build IX > in the companion draft in GROW. Here in IDR we should rather > accommodate all use cases. > > Many thx, > Robert > > On Wed, Jun 1, 2016 at 2:12 PM, Marco Marzetti > wrote: > >> On 2016-06-01 13:17, Nick Hilliard wrote: >> Marco Marzetti wrote: >> I agree with you that you can run a route server and insert your >> ASn in >> the path, but i think that is a lack of common sense which brings >> only >> contraries and no benefits. >> >> About RFC2119: It says that "SHOULD NOT" implies a valid reason to >> accept a behavior, but i can't find any. >> >> I agree that it is not a clever thing to do. The valid reason to >> accept >> the behaviour is that it works in practice: some IXPs have done this >> in >> production, in many cases for years. >> >> There is a secondary reason: some rs client bgp stacks don't support >> the >> option to accept an AS path from the RS where the leftmost entry on >> the >> AS path != peeras. >> >> These are not "good" reasons in the sense that they mandate >> behaviour >> which is suboptimal, but they are valid reasons. >> >> Nick > > Nick, > > I think that we should define a standard that addresses and corrects > those non-clever behaviors rather than embrace them. > > My point is: even if they work in the real world, they do because of > the workarounds that other people put in place and they bring no > benefits. > > Regards > > -- > Marco Dear Robert, Noted, thanks. Hence "SHOULD NOT" is the right choice. Regards -- Marco From nobody Wed Jun 1 07:39:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDAF12D579 for ; Wed, 1 Jun 2016 07:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RgA4AoRpUYf for ; Wed, 1 Jun 2016 07:39:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00D812D523 for ; Wed, 1 Jun 2016 07:39:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLF10503; Wed, 01 Jun 2016 14:39:22 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 1 Jun 2016 15:39:04 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 1 Jun 2016 22:39:00 +0800 From: "Dongjie (Jimmy)" To: "idr@ietf.org" Thread-Topic: BGP-FlowSpec and BGP-LS in IETF96 Hackathon Thread-Index: AdG8E1SmjBxQ6ezXSRy83BEt5e/g4A== Date: Wed, 1 Jun 2016 14:38:59 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774E846C6@NKGEML515-MBS.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.109.109.77] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C92774E846C6NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.574EF39B.0032, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8ad9d460ecd16afe632ef05a45882b63 Archived-At: Subject: [Idr] BGP-FlowSpec and BGP-LS in IETF96 Hackathon X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 14:39:28 -0000 --_000_76CD132C3ADEF848BD84D028D243C92774E846C6NKGEML515MBSchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, BGP-FlowSpec and BGP-LS technology are included in the upcoming IETF 96 hac= kathon http://www.ietf.org/hackathon/96-hackathon.html The details of the BGP-FlowSpec/BGP-LS project is as below, and can also be= found at the hackathon wiki page: https://www.ietf.org/registration/Meetin= gWiki/wiki/96hackathon BGP-FlowSpec/BGP-LS =A7 Champion(s) =A7 TBD =A7 Project(s) =A7 BGP-LS =A7 Support for Segment Routing (SR) in BGP-LS =A7 BGP-Flowspec =A7 RPD in BGP-Flowspec =A7 For this project(s) we would be using ONOS platform (*) =A7 http://onosproject.org/ =A7 Detailed information at =A7 Google Drive =A7 GitHub Please consider participating and see you in Berlin. (*) There is a webinar planned for ONOS at the end of the month, in case yo= u are new to it. Best regards, Jie --_000_76CD132C3ADEF848BD84D028D243C92774E846C6NKGEML515MBSchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

BGP-FlowSpec and BGP-LS technology are in= cluded in the upcoming IETF 96 hackathon http://www.ietf= .org/hackathon/96-hackathon.html

 

The details of the BGP-FlowSpec/BGP-LS pr= oject is as below, and can also be found at the hackathon wiki page: = https://www.ietf.org/registration/MeetingWiki/wiki/96hackathon 

 

BGP-FlowSpec/BGP-LS<= /strong>

=A7  Champion(s)

=A7  TBD=

=A7  Project(s)=

=A7  BGP-LS

=A7  Support for Segment R= outing (SR) in BGP-LS

=A7  BGP-Flowspec

=A7  RPD in BGP-Flowspec

=A7  For this project(s) w= e would be using ONOS platform (*)

=A7  http://onosproject.org/

=A7  Detailed information = at

=A7  Google Drive

=A7  G= itHub

 

Please consider participating and see you= in Berlin.

 

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

 

 

Best regards,

Jie

--_000_76CD132C3ADEF848BD84D028D243C92774E846C6NKGEML515MBSchi_-- From nobody Wed Jun 1 08:01:09 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E829112D1EA; Wed, 1 Jun 2016 08:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRimk5vtOdVO; Wed, 1 Jun 2016 08:00:57 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7530F12D5BA; Wed, 1 Jun 2016 08:00:52 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u51F0kd3025676 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2016 16:00:46 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <574EF89D.6080206@inex.ie> Date: Wed, 01 Jun 2016 16:00:45 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Alvaro Retana (aretana)" References: <5723E3B4.4090103@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "idr-chairs@ietf.org" , "idr@ietf.org" , "shares@ndzh.com" , "draft-ietf-idr-ix-bgp-route-server@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-ix-bgp-route-server-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:01:09 -0000 Alvaro Retana (aretana) wrote: >> We deliberately steered clear of dealing with operational issues in this >> draft because its focus was on the bgp protocol. Several of the comments >> you make below are probably more relevant to >> draft-ietf-grow-ix-bgp-route-server-operations. We've marked them as such. > > Does that mean that you will update > draft-ietf-grow-ix-bgp-route-server-operations, or what? Just wondering. > It would be nice to have a reference from this document to > draft-ietf-grow-ix-bgp-route-server-operations. We thought about it and the bgp-route-server-operations operations draft references the bgp-route-server draft, but not the other way around. This was done because bgp-route-server is standards track and bgp-route-server-operations is informational. Also, it stops the chicken and egg problem. > I'm starting the IETF Last Call and will schedule the IESG review at the > next available Telechat. ok cool, thanks, Nick From nobody Wed Jun 1 11:17:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D374112D1C2; Wed, 1 Jun 2016 11:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG9QOIe1Ieo1; Wed, 1 Jun 2016 11:17:14 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2371912D0A8; Wed, 1 Jun 2016 11:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1340; q=dns/txt; s=iport; t=1464805034; x=1466014634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L9ac8X+peQc/W1Cw/Y45+LRRe82eipYWwIN/NAPFTfs=; b=JSWQ+5oPtTGL5reztL/ELWD6KzALaV2s+OpxWXWWi1kOudSZUwoCuj03 TiFOsTtNrlqFAyNj0hrINPZNNb0eDlPXMvEFewhko3zY0TGWu0XHPs32R lmmLMh571fC83s8gbq4So47Np+V7930yLmQshSbqaSfBR8ClwKN8gMPNS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgDCJU9X/5tdJa1dgz2BUwa6FgENg?= =?us-ascii?q?XqGEQKBMjgUAQEBAQEBAWUnhEYBAQQ6PxACAQgYHhAyJQIEDgWIL8FHAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBH4YnhE2EKoVwAQSTN4UAAY4fgWmNM4YziRgBHgEBQoNtb?= =?us-ascii?q?ok4fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,402,1459814400"; d="scan'208";a="279826101" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2016 18:17:13 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u51IHD8P027202 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Jun 2016 18:17:13 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 1 Jun 2016 13:17:12 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 1 Jun 2016 13:17:12 -0500 From: "Alvaro Retana (aretana)" To: Nick Hilliard Thread-Topic: AD Review of draft-ietf-idr-ix-bgp-route-server-09 Thread-Index: AQHRNFCzHRdSwT+uvUK1lt056oVbCA== Date: Wed, 1 Jun 2016 18:17:12 +0000 Message-ID: References: <5723E3B4.4090103@foobar.org> <574EF89D.6080206@inex.ie> In-Reply-To: <574EF89D.6080206@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , "idr@ietf.org" , "shares@ndzh.com" , "draft-ietf-idr-ix-bgp-route-server@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-ix-bgp-route-server-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:17:16 -0000 On 6/1/16, 11:00 AM, "Nick Hilliard" wrote: Nick: Hi! >Alvaro Retana (aretana) wrote: >>>We deliberately steered clear of dealing with operational issues in this >>>draft because its focus was on the bgp protocol. Several of the comments >>>you make below are probably more relevant to >>>draft-ietf-grow-ix-bgp-route-server-operations. We've marked them as >>>such. >>Does that mean that you will update >>draft-ietf-grow-ix-bgp-route-server-operations, or what? Just wondering. >>It would be nice to have a reference from this document to >>draft-ietf-grow-ix-bgp-route-server-operations. > >We thought about it and the bgp-route-server-operations operations draft >references the bgp-route-server draft, but not the other way around. >This was done because bgp-route-server is standards track and >bgp-route-server-operations is informational. Also, it stops the >chicken and egg problem. Those are not problems. Standards track documents point at Informational documents all the time, as long as the reference is not Normative, then it's ok. In this case, I think it would be beneficial to tell people reading draft-ietf-idr-ix-bgp-route-server that there are operational considerations (as an informational reference) somewhere else. I'll leave it up to you. Thanks! Alvaro. From nobody Wed Jun 1 17:13:47 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E8212D635; Wed, 1 Jun 2016 17:13:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160602001344.16196.49185.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2016 17:13:44 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-flowspec-label-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 00:13:45 -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 of the IETF. Title : Carrying Label Information for BGP FlowSpec Authors : Qiandeng Liang Susan Hares Jianjie You Robert Raszuk Dan Ma Filename : draft-ietf-idr-bgp-flowspec-label-00.txt Pages : 9 Date : 2016-06-01 Abstract: This document specifies a method in which the label mapping information for a particular FlowSpec rule is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the FlowSpec rule. Based on the proposed method, the Label Switching Routers (LSRs) (except the ingress LSR) on the Label Switched Path (LSP) can use label to indentify the traffic matching a particular FlowSpec rule; this facilitates monitoring and traffic statistics for FlowSpec rules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-label/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-label-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 3 08:10:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F7D12D1D4; Fri, 3 Jun 2016 08:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WitrCu-TUkmI; Fri, 3 Jun 2016 08:10:13 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623F4128E19; Fri, 3 Jun 2016 08:10:11 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u53FA5nF026126 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 16:10:05 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57519DCC.6050400@foobar.org> Date: Fri, 03 Jun 2016 16:10:04 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Alvaro Retana (aretana)" References: <5723E3B4.4090103@foobar.org> <574EF89D.6080206@inex.ie> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "idr-chairs@ietf.org" , "idr@ietf.org" , "shares@ndzh.com" , "draft-ietf-idr-ix-bgp-route-server@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-ix-bgp-route-server-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:10:16 -0000 Alvaro Retana (aretana) wrote: > Those are not problems. Standards track documents point at Informational > documents all the time, as long as the reference is not Normative, then > it's ok. In this case, I think it would be beneficial to tell people > reading draft-ietf-idr-ix-bgp-route-server that there are operational > considerations (as an informational reference) somewhere else. I'll put a link in then, and will update this in AUTH48. Thanks for the suggestion - there was conflicting information about circular references. Nick From nobody Mon Jun 6 09:34:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2104212D856 for ; Mon, 6 Jun 2016 09:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.439 X-Spam-Level: **** X-Spam-Status: No, score=4.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zewmDLHUSpZ4 for ; Mon, 6 Jun 2016 09:34:00 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335A712D150 for ; Mon, 6 Jun 2016 09:34:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86; From: "Susan Hares" To: Date: Mon, 6 Jun 2016 12:33:59 -0400 Message-ID: <012101d1c011$3a788910$af699b30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0122_01D1BFEF.B366E910" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHAEQYUXBRoExz8T+2Ksa0wCnvt6g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-ietf-idr-add-paths-guidelines-08.txt - 1 week call to confirm WG LC (5/24 to 5/31) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 16:34:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0122_01D1BFEF.B366E910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This closes the 1 week confirmation of the IDR WG LC on draft-ietf-idr-add-path-guidelines-08.txt. This draft will be forwarded to the IESG for publication. Sue Hares and John Scudder ------=_NextPart_000_0122_01D1BFEF.B366E910 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = closes the 1 week confirmation of the IDR WG LC on = draft-ietf-idr-add-path-guidelines-08.txt.  This draft will be = forwarded to the IESG for publication.

 

Sue Hares = and John Scudder

------=_NextPart_000_0122_01D1BFEF.B366E910-- From nobody Mon Jun 6 09:40:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD17212D0C0; Mon, 6 Jun 2016 09:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.439 X-Spam-Level: **** X-Spam-Status: No, score=4.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_9Q_AfKWsPQ; Mon, 6 Jun 2016 09:40:23 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8884612D5A3; Mon, 6 Jun 2016 09:40:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86; From: "Susan Hares" To: Date: Mon, 6 Jun 2016 12:40:19 -0400 Message-ID: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012F_01D1BFF0.95F5DF70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHAEXYm+R0yr9NBRVeLkrezdS25EQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" Subject: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 16:40:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012F_01D1BFF0.95F5DF70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy. You can find the draft at: https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/. In your comments on adopting this draft, please indicate: 1) "Support" or "no Support" 2) Do you feel this is a way to prevent route leaks? 3) Are there any deployment issues that might prevent deployment of this enhancement to BGP Open? 4) Does this interact with draft-ietf-idr-route-leak-detection-mitigation? Sue Hares and John Scudder ------=_NextPart_000_012F_01D1BFF0.95F5DF70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy. You = can find the draft at:

https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/.

 

In your comments on adopting this draft, please = indicate:

 

1)      = “Support” or “no = Support”

2)      = Do you feel this is a way to prevent route = leaks?

3)      = Are there any deployment issues that might = prevent deployment of this enhancement to BGP Open?

4)      = Does this interact with = draft-ietf-idr-route-leak-detection-mitigation?

 

Sue Hares = and John Scudder

 

------=_NextPart_000_012F_01D1BFF0.95F5DF70-- From nobody Mon Jun 6 10:00:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA43A12D150; Mon, 6 Jun 2016 10:00:46 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9GeH8FZQ23u; Mon, 6 Jun 2016 10:00:45 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A1912D1AA; Mon, 6 Jun 2016 10:00:45 -0700 (PDT) Received: from [216.82.250.99] by server-3.bemta-12.messagelabs.com id F1/DB-21945-C3CA5575; Mon, 06 Jun 2016 17:00:44 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-10.tower-126.messagelabs.com!1465232444!52932893!1 X-Originating-IP: [209.245.18.38] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8507 invoked from network); 6 Jun 2016 17:00:44 -0000 Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-10.tower-126.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Jun 2016 17:00:44 -0000 Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id DE0222DA47; Mon, 6 Jun 2016 17:00:43 +0000 (GMT) Received: from USIDCWVEMBX03.corp.global.level3.com ([fe80::e849:4e57:cb74:ed58]) by USIDCWVEHT01.corp.global.level3.com ([::1]) with mapi id 14.03.0279.002; Mon, 6 Jun 2016 11:00:43 -0600 From: "Osborne, Eric" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) Thread-Index: AdHAEXYm+R0yr9NBRVeLkrezdS25EQAAqhng Date: Mon, 6 Jun 2016 17:00:43 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5E@USIDCWVEMBX03.corp.global.level3.com> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> In-Reply-To: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.205] Content-Type: multipart/alternative; boundary="_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5EUSIDCWVEMBX03co_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 17:00:47 -0000 --_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5EUSIDCWVEMBX03co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1) I support solving the problem this draft set out, and this draft se= ems to be a good start at wrestling with the problem. 2) This works better on a white board than in real life. In particula= r, terms like Peer and Customer and Transit have commercial connotations as= well as technical ones. It may be that some operators have a Providers (f= iscal relationship) but with which they exchange routes as if it were a Pee= r. Or Customer/Peer, or Customer/Provider. I am a little concerned about = translating the strict rules in this doc into a more nuanced BGP policy whi= ch reflects business policy. I encourage anyone who implements this to not= just make it a "Role must match or I'm going to tear the neighbor down" so= rt of thing. 3) See #2 4) I just briefly skimmed detection-mitigation, and that seems like a = much more heavyweight way to implmement the same sort of end behavior. eric From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, June 06, 2016 12:40 PM To: idr@ietf.org Cc: draft-ietf-idr-route-leak-detection-mitigation@ietf.org; 'John G. Scudd= er' Subject: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/= 20/2016) This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy. Y= ou can find the draft at: https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/. In your comments on adopting this draft, please indicate: 1) "Support" or "no Support" 2) Do you feel this is a way to prevent route leaks? 3) Are there any deployment issues that might prevent deployment of th= is enhancement to BGP Open? 4) Does this interact with draft-ietf-idr-route-leak-detection-mitigat= ion? Sue Hares and John Scudder --_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5EUSIDCWVEMBX03co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1)&n= bsp;     I support solv= ing the problem this draft set out, and this draft seems to be a good start= at wrestling with the problem.

2)&n= bsp;     This works bet= ter on a white board than in real life.  In particular, terms like Pee= r and Customer and Transit have commercial connotations as well as technica= l ones.  It may be that some operators have a Providers (fiscal relationship) but with which they exchange routes= as if it were a Peer.  Or Customer/Peer, or Customer/Provider.  = I am a little concerned about translating the strict rules in this doc into= a more nuanced BGP policy which reflects business policy.  I encourage anyone who implements this to not just = make it a “Role must match or I’m going to tear the neighbor do= wn” sort of thing.

3)&n= bsp;     See #2

4)&n= bsp;     I just briefly= skimmed detection-mitigation, and that seems like a much more heavyweight = way to implmement the same sort of end behavior. 

 

 

 

 

eric=

 

 

From: Idr [mailto:idr-bounces@ietf.org] On= Behalf Of Susan Hares
Sent: Monday, June 06, 2016 12:40 PM
To: idr@ietf.org
Cc: draft-ietf-idr-route-leak-detection-mitigation@ietf.org; 'John G= . Scudder' <jgs@bgp.nu>
Subject: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/= 6 to 6/20/2016)

 

This begins a 2 week WG Adoption call for draft-ymbk= -idr-bgp-open-policy. You can find the draft at:

https://datatracker.ietf.org/doc/draft-ymbk-idr-bg= p-open-policy/.

 

In your comments on adopting this draft, please indi= cate:

 

1)      “Support” or “no Support” <= o:p>

2)      Do you feel this is a way to prevent route leaks? <= o:p>

3)      Are there any deployment issues that might prevent = deployment of this enhancement to BGP Open?

4)      Does this interact with draft-ietf-idr-route-leak-d= etection-mitigation?

 

Sue Hares and John Scudder

 

--_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5EUSIDCWVEMBX03co_-- From nobody Mon Jun 6 10:12:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E849412D0C8; Mon, 6 Jun 2016 10:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSH3fLy0vvue; Mon, 6 Jun 2016 10:11:59 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A73412D135; Mon, 6 Jun 2016 10:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9447; q=dns/txt; s=iport; t=1465233119; x=1466442719; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=zxfYYzn/WD/b2qcUFgRbecwR7991SXfCQS/B29BRZLE=; b=KAET/bROzBPOZavsyjpAuwMtDii8+O4tpfsJIP3IcBIg5jDKh96G3Upw 9dt+gVXelClh+1P8aET6uCzbXqqG76919QqEZjBv7TFGbbGbAASmIhG6c WSi8k6HmN7q2aU6c3KCckAZTuiIj1P0iakMYuin72onjMLkP0WAEaM9Ty 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAgAqrlVX/4MNJK1bgm5NVm8OBrVXh?= =?us-ascii?q?H2BeiKFcAKBMzgUAQEBAQEBAWUnhEUBAQEEgQkCAQgRAwECKAcyFAkIAgQBEog?= =?us-ascii?q?VAxcOuw4BAQEBAQEBAQEBAQEBAQEBAQEaBYp0gkOBTxEBPIU6BY4eiioBhgKII?= =?us-ascii?q?4FphFCIZY9ZAR42g25uAYhjNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,428,1459814400"; d="scan'208,217";a="281660352" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jun 2016 17:11:58 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u56HBw0w003955 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jun 2016 17:11:58 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 6 Jun 2016 13:11:57 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.009; Mon, 6 Jun 2016 13:11:57 -0400 From: "Ali Sajassi (sajassi)" To: "Ali Sajassi (sajassi)" , John E Drake , Thomas Morin , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi++kmVRnOfCCEaLlUJwLCbjV5+pXciAgAAV74CAABx8AIAAAd6AgAD40oCAAAcLgIAAlB8AgAAObQCAE5+SgIAAQjEAgAiAQYCAFRg5AA== Date: Mon, 6 Jun 2016 17:11:57 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.53] Content-Type: multipart/alternative; boundary="_000_D37AFB0E1A944Csajassiciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 17:12:02 -0000 --_000_D37AFB0E1A944Csajassiciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas, I updated and checked-in a new rev of this draft couple of weeks ago to add= ress the comments that came up on this email thread - the main changes were= outlined in my previous email. Can you please progress this draft for its = LC. If there is any issue preventing the progress of this draft, would you = let us know. Regards, Ali From: Cisco Employee > Date: Tuesday, May 24, 2016 at 12:04 AM To: John E Drake >, Thomas Mo= rin >, IDR >, BESS >, "d= raft-ietf-bess-evpn-overlay@tools.ietf.org" >, "Rabadan, Jorge (Nokia - US)" = >, "draft-ietf-idr-= tunnel-encap@tools.ietf.org" > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Resent-From: >, Cisco= Employee > Resent-To: Cisco Employee >, >, >, >,= >, >, > Resent-Date: Tuesday, May 24, 2016 at 12:05 AM Folks, I have updated and published rev03 of even-overlay draft. https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ The main changes are: 1. section 10.2 - DCI using ASBR 2. The setting of Ethernet tag and VNI fields - there were some inconsis= tencies in different sections. Section 5.1.3 captures the setting of these = fields for different type of services in pretty good details. All other sec= tions were cleaned up and now refer to section 5.1.3. Thomas, The draft is ready for its long-overdue WG LC considering how long its has = been around and its multi-vendor implementation status. Regards, Ali --_000_D37AFB0E1A944Csajassiciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <8952DB7AAC24A04C9ADF5E961512C770@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Thomas,

I updated and checked-in a new rev of this draft couple of weeks ago t= o address the comments that came up on this email thread – the main c= hanges were outlined in my previous email. Can you please progress this dra= ft for its LC. If there is any issue preventing the progress of this draft, would you let us know.

Regards,
Ali

From: Cisco Employee <sajassi@cisco.com>
Date: Tuesday, May 24, 2016 at 12:0= 4 AM
To: John E Drake <jdrake@juniper.net>, Thomas Morin <thomas.morin@orange.com>, IDR &= lt;idr@ietf.org>, BESS <bess@ietf.org>, "draft-ietf-bess-evp= n-overlay@tools.ietf.org" <draft-ietf-bess-evpn-overlay@tools.ietf.org&= gt;, "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>, "draft-ietf-idr-tunnel-encap@tools.ie= tf.org" <draft-ietf-idr-tunnel-encap@tools.ietf.org>
Subject: Re: [Idr] draft-ietf-bess-= evpn-overlay vs. draft-ietf-idr-tunnel-encaps
Resent-From: <alias-bounces@ietf.org>, Cisco Employee <= sajassi@cisco.com>
Resent-To: Cisco Employee <sajassi@cisco.com>, <jdrake@juniper.net>, <nabil.n.bitar@verizon.com>, <uttaro@att.com>, <wim.henderickx@alcatel-lucent= .com>, <aisaac@juniper.net<= /a>>, <draft= -ietf-bess-evpn-overlay@ietf.org>
Resent-Date: Tuesday, May 24, 2016 = at 12:05 AM


Folks,

I have updated and published rev03 of even-overlay draft. 

The main changes are:
  1. section 10.2 – DCI using ASBR
  2. The setting of Ethernet tag= and VNI fields – there were some inconsistencies in different sectio= ns. Section 5.1.3 captures the setting of these fields for different type o= f services in pretty good details. All other sections were cleaned up and n= ow refer to section 5.1.3.

Thomas,
The draft is ready for its long-overdue WG LC considering how long its= has been around and its multi-vendor implementation status. 

Regards,
Ali
 --_000_D37AFB0E1A944Csajassiciscocom_-- From nobody Mon Jun 6 10:38:41 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462B212D861 for ; Mon, 6 Jun 2016 10:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.439 X-Spam-Level: **** X-Spam-Status: No, score=4.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z65OIhd7c7ho for ; Mon, 6 Jun 2016 10:38:38 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B11512D106 for ; Mon, 6 Jun 2016 10:38:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86; From: "Susan Hares" To: Date: Mon, 6 Jun 2016 13:38:35 -0400 Message-ID: <017501d1c01a$41156960$c3403c20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0176_01D1BFF8.BA055000" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHAElYAB9sVfa6xQkej61auMDdHAw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 17:38:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0176_01D1BFF8.BA055000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG Adoption call for draft-keyupate-idr-bgp-attribute-announcement. You can find the draft at: https://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-attribute-announceme nt/ This draft defines attribute extensions that help confine the scope of Optional attributes within a given AS or a given BGP member-AS in Confederation. In your comments please include: 1) "Support" or "No support" for this draft as an IDR WG draft, 2) Experiences with debugging optional attributes errors that this draft would aid, 3) Deployments that use AS confederations where this draft's ability to confined scope of the optional attributes would help restrict errors, Sue Hares and John Scudder ------=_NextPart_000_0176_01D1BFF8.BA055000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG Adoption call for = draft-keyupate-idr-bgp-attribute-announcement.  You can find the = draft at:

https://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-a= ttribute-announcement/

 

This draft = defines attribute extensions that help confine the scope of Optional = attributes within a given AS or a given BGP member-AS in = Confederation.   In your comments please = include:

1)      = “Support” or “No = support” for this draft as an IDR WG draft,

2)      = Experiences with debugging optional attributes = errors that this draft would aid,

3)      = Deployments that use AS confederations where = this draft’s ability to confined scope of the optional attributes = would help restrict errors,

 

 

Sue Hares = and John Scudder  

 

 

 

------=_NextPart_000_0176_01D1BFF8.BA055000-- From nobody Mon Jun 6 10:43:00 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9470E12D88F; Mon, 6 Jun 2016 10:42:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160606174256.20813.91845.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 10:42:56 -0700 Archived-At: Subject: [Idr] The IDR WG has placed draft-keyupate-idr-bgp-attribute-announcement in state "Call For Adoption By WG Issued" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 17:42:56 -0000 The IDR WG has placed draft-keyupate-idr-bgp-attribute-announcement in state Call For Adoption By WG Issued (entered by Susan Hares) The document is available at https://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-attribute-announcement/ Comment: 6/6 to 6/20 From nobody Mon Jun 6 11:22:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2824412D0ED for ; Mon, 6 Jun 2016 11:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T3Kqfalj2ZB for ; Mon, 6 Jun 2016 11:22:53 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA0112B031 for ; Mon, 6 Jun 2016 11:22:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86; From: "Susan Hares" To: "'Robert Raszuk'" , "'Bruno Decraene'" References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> <13146_1464170675_574578B3_13146_4888_1_53C29892C857584299CBF5D05346208A0F8CD227@OPEXCLILM21.corporate.adroot.infra.ftgroup> <15012_1464254328_5746BF78_15012_699_1_53C29892C857584299CBF5D05346208A0F8D0469@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Mon, 6 Jun 2016 14:22:50 -0400 Message-ID: <01a901d1c020$6f66a760$4e33f620$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AA_01D1BFFE.E85814A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJm67g09Bh8eF9lBor3ExN3YMg19QJFIXVKANFFB9EBwQpgbwKA/yD1nnek50A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Keyur Patel \(keyupate\)'" , idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 18:22:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AA_01D1BFFE.E85814A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Robert and Bruno:=20 =20 https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-= implementations =20 is the location to put information regarding = draft-ietf-idr-bgp-extended-implementations. It is a wiki =E2=80=93 so = anyone can add details to it.=20 =20 The location of all implementation reports are now on the IDR wiki at:=20 =20 https://trac.tools.ietf.org/wg/idr/trac/wiki=20 =20 I will be asking the authors to fill this in and do a final spin of the = draft.=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Thursday, May 26, 2016 7:20 AM To: Bruno Decraene Cc: Keyur Patel (keyupate); idr@ietf.org; Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 = to 6/7) =20 Hi Bruno/all, =20 =E2=80=9CA protocol designer or network operator needing to advertise, = outside of its AS, a BGP route which size would require a BGP message = larger than 4096 octets should take into account that it has no = guarantee that its route will be propagated as expected as a downstream = BGP speaker might not be compliant or might not has enabled BGP extended = messages and hence will not propagate the route. This is especially the = case if one expect Internet wide propagation of its route, which seems = highly improbable until a few years/decades=E2=80=9D. =20 =20 =E2=80=8BThe above text which very true triggered few more observations: =20 =E2=80=8B- As this is WG last call implementation report (even on the = wiki should be available) Can we get a pointer to it ? I do not see it = on the IETF page: https://www.ietf.org/iesg/implementation-report.html =20 - Did implementation report (if even completed) included the set of test = cases say with large AS_PATH or long Extended Community (stuffing a lot = of RTs as described in RTC backwards compatibility work) to make sure = that most popular BGP implementation can handle such large attributes = without crashing ? Otherwise enabling this would be an excellent attack = vector in the Internet. =20 - Do we have an agreement that this will not be "ON" by default, but = will be enabled only with a knob ?=20 =20 - How do we detect if this is supported across the private AS/public = Internet zoo of routers ? Should we have a protocol tool which would = allow to detect support of extended messages at each BGP speaker and if = not report this as an error to the originator of the large message ? = Sending large BGP message if not supported by any remote peer by any BGP = speaker along the propagation would trigger reporting it back with new = ICMP error could be one approach. I am sure there would be others ... =20 Thx, r. =20 ------=_NextPart_000_01AA_01D1BFFE.E85814A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Robert and Bruno:

 

https://trac.tools.ietf.org/wg/idr/trac/wiki/dra= ft-ietf-idr-bgp-extended-implementations

 

is the location to put information regarding = draft-ietf-idr-bgp-extended-implementations.=C2=A0=C2=A0 It is a wiki = =E2=80=93 so anyone can add details to it.

 

The location of all implementation reports are now on the IDR wiki = at:

 

https://trac.tools.= ietf.org/wg/idr/trac/wiki

 

I will be asking the authors to fill this in and do a final spin of = the draft.

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert = Raszuk
Sent: Thursday, May 26, 2016 7:20 AM
To: = Bruno Decraene
Cc: Keyur Patel (keyupate); idr@ietf.org; Susan = Hares
Subject: Re: [Idr] = draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to = 6/7)

 

Hi = Bruno/all,

 

=E2=80=9CA protocol designer or network operator = needing to advertise, outside of its AS, a BGP route which size would = require a BGP message larger than 4096 octets should take into account = that it has no guarantee that its route will be propagated as expected = as a downstream BGP speaker might not be compliant or might not has = enabled BGP extended messages and hence will not propagate the route. = This is especially the case if one expect Internet wide propagation of = its route, which seems highly improbable until a few = years/decades=E2=80=9D.

 

 

=E2=80=8BThe above text which = very true triggered few more = observations:

 

=E2=80=8B- As this is WG last = call implementation report (even on the wiki should be available) Can we = get a pointer to it ? I do not see it on the IETF = page:

=

 

- Did = implementation report (if even completed) included the set of test cases = say with large AS_PATH or long Extended Community (stuffing a lot of RTs = as described in RTC backwards compatibility work) to make sure that most = popular BGP implementation can handle such large attributes without = crashing ? Otherwise enabling this would be an excellent attack vector = in the Internet.

 

- Do we have an agreement = that this will not be "ON" by default, but will be enabled = only with a knob ? 

 

- How do we detect if this is = supported across the private AS/public Internet zoo of routers ? Should = we have a protocol tool which would allow to detect support of extended = messages at each BGP speaker and if not report this as an error to the = originator of the large message ? Sending large BGP message if not = supported by any remote peer by any BGP speaker along the propagation = would trigger reporting it back with new ICMP error could be one = approach. I am sure there would be others = ...

 

Thx,

r.

=

 

------=_NextPart_000_01AA_01D1BFFE.E85814A0-- From nobody Mon Jun 6 12:02:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1612D7CF; Mon, 6 Jun 2016 12:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P22-mT4gsTuS; Mon, 6 Jun 2016 12:02:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C502812D7B6; Mon, 6 Jun 2016 12:02:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1b9zmy-0003oR-Uf; Mon, 06 Jun 2016 19:02:17 +0000 Date: Mon, 06 Jun 2016 12:02:16 -0700 Message-ID: From: Randy Bush To: "Susan Hares" In-Reply-To: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 19:02:21 -0000 this wg seems to have the strange convention of co-authors speaking for draft adoption, advancement, ... so i support this draft for adoption, though it is a bit embarrassing to do so. randy From nobody Mon Jun 6 12:09:20 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6120412D8E4; Mon, 6 Jun 2016 12:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nl_IwicgzZ7i; Mon, 6 Jun 2016 12:09:09 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D5E12B02A; Mon, 6 Jun 2016 12:09:09 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86; From: "Susan Hares" To: "'Randy Bush'" References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> In-Reply-To: Date: Mon, 6 Jun 2016 15:09:01 -0400 Message-ID: <021401d1c026$e2d3b2f0$a87b18d0$@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: AQF7c7sVleQLlnYVEOfAIkuoqhZdLAK2zILgoHOvlMA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 19:09:18 -0000 Randy, Eugene, Alexander: Would you please indicate whether you know of IPR on draft-ymbk-idr-bgp-open-policy? I forgot to add this to the WG adoption call. Sue Hares -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, June 06, 2016 3:02 PM To: Susan Hares Cc: idr@ietf.org; draft-ietf-idr-route-leak-detection-mitigation@ietf.org; 'John G. Scudder' Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) this wg seems to have the strange convention of co-authors speaking for draft adoption, advancement, ... so i support this draft for adoption, though it is a bit embarrassing to do so. randy From nobody Mon Jun 6 12:15:07 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6287D12D529 for ; Mon, 6 Jun 2016 12:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nemEgPkagAJz for ; Mon, 6 Jun 2016 12:15:02 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D3412D1CA for ; Mon, 6 Jun 2016 12:15:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86; From: "Susan Hares" To: References: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> In-Reply-To: <037f01d1b5fc$bfb596f0$3f20c4d0$@ndzh.com> Date: Mon, 6 Jun 2016 15:14:59 -0400 Message-ID: <021801d1c027$b8947690$29bd63b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0219_01D1C006.31845D30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJm67g09Bh8eF9lBor3ExN3YMg19Z6yd7cg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Keyur Patel \(keyupate\)'" , 'David Ward' Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 19:15:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0219_01D1C006.31845D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Randy, Keyur and Dave: This draft has receive several comment, but the support for publication is almost 100%. Once we have a revised version and implementation reports, we should be able to proceed. Would you do the following: 1) Publish a version of the draft with revision suggested on the list, 2) Update the wiki with implementation information https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-imp lementations After these are updated, we will confirm with the list that the issues have been addressed, and then proceed with the publication request. Sue Hares and John Scudder From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, May 24, 2016 4:42 PM To: idr@ietf.org Cc: 'Keyur Patel (keyupate)'; 'David Ward' Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7) This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ In your comments please provide the following information: 1) Support/"no-support" of this draft being ready for publication, 2) You know of an implementation for this draft, please report the implementation to the IDR Wiki https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-imp lementations 3) Do you have any concerns about extending the BGP messages. Sue Hares and John Scudder ------=_NextPart_000_0219_01D1C006.31845D30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Randy, Keyur and Dave: 

 

This draft has receive = several comment, but the support for publication is almost 100%. =   Once we have a revised = version and implementation reports, we should be able to = proceed.

 

Would you do the = following: 

 

1)      Publish a version of the draft with revision = suggested on the list, 

2)      Update the wiki with implementation = information 

https://trac.tools.ietf.org/wg/idr/trac/wiki/draft= -ietf-idr-bgp-extended-implementations

 

After these are updated, = we will confirm with the list that the issues have been addressed, and = then proceed with the publication request.

 

 Sue Hares = and John Scudder

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Tuesday, May 24, 2016 4:42 PM
To: = idr@ietf.org
Cc: 'Keyur Patel (keyupate)'; 'David = Ward'
Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 = WG LC (5/24 to 6/7)

 

This begins = a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to 6/7). = The draft can be found at:

 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messa= ges/

 

In your comments please provide the following = information:

1)      = Support/”no-support” of this draft = being ready for publication,

2)      = You know of an implementation for this draft, = please report the implementation to the IDR Wiki

 

https://trac.tools.ietf.org/wg/idr/trac/wiki/dra= ft-ietf-idr-bgp-extended-implementations

 

3)      = Do you have any concerns about extending the BGP = messages.

 

Sue Hares and John Scudder =

------=_NextPart_000_0219_01D1C006.31845D30-- From nobody Mon Jun 6 12:16:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E5212D534; Mon, 6 Jun 2016 12:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyVGaoalJIQ5; Mon, 6 Jun 2016 12:16:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B2C12D1CA; Mon, 6 Jun 2016 12:16:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bA00Y-0003te-6J; Mon, 06 Jun 2016 19:16:18 +0000 Date: Mon, 06 Jun 2016 12:16:17 -0700 Message-ID: From: Randy Bush To: "Susan Hares" In-Reply-To: <021401d1c026$e2d3b2f0$a87b18d0$@ndzh.com> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <021401d1c026$e2d3b2f0$a87b18d0$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 19:16:22 -0000 > Would you please indicate whether you know of IPR on > draft-ymbk-idr-bgp-open-policy? i am not aware of ipr on this draft randy From nobody Mon Jun 6 12:59:31 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF8A12D5D0; Mon, 6 Jun 2016 12:59:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160606195927.20801.61307.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 12:59:27 -0700 Archived-At: Cc: idr@ietf.org, Russ White , idr-chairs@ietf.org, The IESG , draft-ietf-idr-add-paths@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] Protocol Action: 'Advertisement of Multiple Paths in BGP' to Proposed Standard (draft-ietf-idr-add-paths-15.txt) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 19:59:27 -0000 The IESG has approved the following document: - 'Advertisement of Multiple Paths in BGP' (draft-ietf-idr-add-paths-15.txt) as Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ Technical Summary This document extends BGP so a BGP speaker can advertise multiple paths rather than a single best path to peers. It proposes a new NLRI encoding extension to carry a Path Identifier, and a new capability to negotiate the carrying of additional paths. These additional paths are intended to used to eliminate path oscillation, in a number of situations where advertising multiple paths can improve network convergence, and in a number of situations where BGP is used in "high fan out" equal cost multipath network topologies to provide optimal path availability. Working Group Summary The working group has reached consensus on moving this document forward at this point. Document Quality The extension to BGP is straightforward; while there has been some difficulty in coming to consensus on the benefits provided versus the difficulty in implementing the extensions, the value of the concept has been proven in deployment scenarios and use cases enough to justify moving forward with this document. The document has passed through ten revisions over a number of years, and has been discussed both on and off the relevant lists by a number of experts in the development and deployment of BGP. Personnel AD: Alia Atlas Shepherd: Russ White From nobody Mon Jun 6 13:18:37 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAA212D871; Mon, 6 Jun 2016 13:18:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160606201835.20781.55025.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 13:18:35 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-packet-rate-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:18:35 -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 of the IETF. Title : BGP Flow Specification Packet-Rate Action Authors : Wesley Eddy Justin Dailey Gilbert Clark Filename : draft-ietf-idr-flowspec-packet-rate-00.txt Pages : 5 Date : 2016-06-06 Abstract: This document defines a new type of traffic filtering action for the BGP flow specification. The new packet-rate action allows specifying a rate-limit in number of packets per second. This is intended to be used in combatting some types of denial of service attacks where the packet rate is more important than the raw bitrate of the attack traffic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-packet-rate/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-packet-rate-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 6 14:56:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0637E12B051 for ; Mon, 6 Jun 2016 14:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4E9Y4nveqd2 for ; Mon, 6 Jun 2016 14:56:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E75012B015 for ; Mon, 6 Jun 2016 14:56:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO lhreml705-cah.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQY56528; Mon, 06 Jun 2016 16:56:43 -0500 (CDT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 6 Jun 2016 22:56:38 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Mon, 6 Jun 2016 14:56:32 -0700 From: Linda Dunbar To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) Thread-Index: AdHAElYAB9sVfa6xQkej61auMDdHAwAK+4yA Date: Mon, 6 Jun 2016 21:56:31 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657EAFE4F@dfweml501-mbb> References: <017501d1c01a$41156960$c3403c20$@ndzh.com> In-Reply-To: <017501d1c01a$41156960$c3403c20$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.226] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657EAFE4Fdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 21:56:47 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657EAFE4Fdfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Linda Dunbar From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, June 06, 2016 12:39 PM To: idr@ietf.org Subject: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement= - 2 week WG Adoption call (6/6 to 6/20) This begins a 2 week WG Adoption call for draft-keyupate-idr-bgp-attribute-= announcement. You can find the draft at: https://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-attribute-announcem= ent/ This draft defines attribute extensions that help confine the scope of Opti= onal attributes within a given AS or a given BGP member-AS in Confederation= . In your comments please include: 1) "Support" or "No support" for this draft as an IDR WG draft, 2) Experiences with debugging optional attributes errors that this dra= ft would aid, 3) Deployments that use AS confederations where this draft's ability t= o confined scope of the optional attributes would help restrict errors, Sue Hares and John Scudder --_000_4A95BA014132FF49AE685FAB4B9F17F657EAFE4Fdfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Linda Dunbar

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, June 06, 2016 12:39 PM
To: idr@ietf.org
Subject: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-annou= ncement - 2 week WG Adoption call (6/6 to 6/20)

 

This begins a 2 week WG Adoption call for draft-keyu= pate-idr-bgp-attribute-announcement.  You can find the draft at:

https://datatracker.ietf.org/doc/dr= aft-keyupate-idr-bgp-attribute-announcement/

 

This draft defines attribute extensions that help co= nfine the scope of Optional attributes within a given AS or a given BGP mem= ber-AS in Confederation.   In your comments please include:<= /o:p>

 

1)      “Support” or “No support” f= or this draft as an IDR WG draft,

2)      Experiences with debugging optional attributes erro= rs that this draft would aid,

3)      Deployments that use AS confederations where this d= raft’s ability to confined scope of the optional attributes would hel= p restrict errors,

 

 

Sue Hares and John Scudder  

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657EAFE4Fdfweml501mbb_-- From nobody Mon Jun 6 15:50:35 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DC212D1D0 for ; Mon, 6 Jun 2016 15:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3txmcoB0PFUo for ; Mon, 6 Jun 2016 15:50:31 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A71F12D630 for ; Mon, 6 Jun 2016 15:50:31 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id z123so56766311itg.0 for ; Mon, 06 Jun 2016 15:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nct3vdnpEZojb2sKoO/el7jwzY+ZEv07sY16NmucPf8=; b=gyP5NJqgH4gzgICIullQT9aC/XvWEbgjEC9UgLlth18omPLnU4gl+gIycdNR0CIWIp RmOd4JpSUuuQGfQzumRIWN8sILcFZ0r6hmcV3WzY/6ZXsD+pJJYA7X7sSCUtfSpuWzOM oiU2Zvp6Hsf0uiGap+3jipcTAGxjQJ9XZPPHakd2q0Hf1/Cbvo3HLSSL7uDzjkVPEw9o 39JCodRmR01wQYAaZADZnum1AecC8xAokPWJf3Y0YE2gM56DX698rjwx2RFapWqI2ZlE CReA03sfZ5NkDbL0/exno5sTc249myBl+TzgztZ7Z9CAVBkRBMIP3VMZhB9yJ7YJCxk3 8FUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nct3vdnpEZojb2sKoO/el7jwzY+ZEv07sY16NmucPf8=; b=jnRRTpg9Q6o+zSQpHmk6NOotC9TbijYBB/ZU8RVfXLEBYBqhgDMw0kbcfsgsS+vcqG PVa7OFMVv6xvo+B54S8UD3uKKDC+nB051ae52p3eUmejPJkhdqhB3+Z+FWV8kt12Bm5V P3sogROTYi1hQoSSiDR3UvOA5Nr/U0JI4402BsWLoAnJI/0bDN5YkQ7gnxPIgt2Fkbdq vMqQWA8buOqx1qFANXtf4OKvdB+4DxCmq6wyNZDcXY/rp2xF3mZ7Z4gtHXLK0jguokNd YZ3pK8rA/hfAlU6xPrCFJuTlg+H/Mzm5FAKqCTHWrljIuHUoFj3HY2k4LxGdc3tV3L6f JxmA== X-Gm-Message-State: ALyK8tLDv4iarBmtI7crlM+6IqVzPq8OePO998PPf02XwdiaB0blhcrEcam766U6B8k5B/tFImUVeoWcq+ruFw== X-Received: by 10.107.27.18 with SMTP id b18mr24846132iob.163.1465253430360; Mon, 06 Jun 2016 15:50:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.28.81 with HTTP; Mon, 6 Jun 2016 15:49:51 -0700 (PDT) In-Reply-To: <017501d1c01a$41156960$c3403c20$@ndzh.com> References: <017501d1c01a$41156960$c3403c20$@ndzh.com> From: Tony Przygienda Date: Mon, 6 Jun 2016 15:49:51 -0700 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a1140a2a03923fd0534a3e616 Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 22:50:33 -0000 --001a1140a2a03923fd0534a3e616 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable support On Mon, Jun 6, 2016 at 10:38 AM, Susan Hares wrote: > This begins a 2 week WG Adoption call for > draft-keyupate-idr-bgp-attribute-announcement. You can find the draft at= : > > > https://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-attribute-announc= ement/ > > > > This draft defines attribute extensions that help confine the scope of > Optional attributes within a given AS or a given BGP member-AS in > Confederation. In your comments please include: > > 1) =E2=80=9CSupport=E2=80=9D or =E2=80=9CNo support=E2=80=9D for thi= s draft as an IDR WG draft, > > 2) Experiences with debugging optional attributes errors that this > draft would aid, > > 3) Deployments that use AS confederations where this draft=E2=80=99s= ability > to confined scope of the optional attributes would help restrict errors, > > > > > > Sue Hares and John Scudder > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --001a1140a2a03923fd0534a3e616 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
support

On Mon, Jun 6, 2016 at 10:38 AM, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 = week WG Adoption call for draft-keyupate-idr-bgp-attribute-announcement.=C2= =A0 You can find the draft at:

https://datatracker.ietf.org/doc/draft-keyu= pate-idr-bgp-attribute-announcement/

=C2=A0

This draft defines att= ribute extensions that help confine the scope of Optional attributes within= a given AS or a given BGP member-AS in Confederation.=C2=A0=C2=A0 In your = comments please include:

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9CSupport= =E2=80=9D or =E2=80=9CNo support=E2=80=9D for this draft as an IDR WG draft= ,

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Exper= iences with debugging optional attributes errors that this draft would aid,=

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Deploy= ments that use AS confederations where this draft=E2=80=99s ability to conf= ined scope of the optional attributes would help restrict errors,

=C2=A0

=C2=A0

Sue Hares and John Scudd= er =C2=A0

=C2=A0

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

=C2=A0


_________________________________________= ______
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr




--
=
We=E2=80=99ve heard that a million monkeys at a million keyboards c= ould produce the complete works of Shakespeare; now, thanks to the Internet= , we know that is not true.
= =E2=80=94Robert Wilensky
--001a1140a2a03923fd0534a3e616-- From nobody Mon Jun 6 15:53:08 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105A212D140 for ; Mon, 6 Jun 2016 15:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O__sB7-8cUiL for ; Mon, 6 Jun 2016 15:53:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F9212D100 for ; Mon, 6 Jun 2016 15:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7113; q=dns/txt; s=iport; t=1465253584; x=1466463184; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sGrHbZcX9Mu8bhYrpmBlloWzoXpZjazFu2og/G9jKas=; b=l2U59jTAoujOy/uc0OsjdMJkz9Fqi26T6tSydLfhCmVVfKo2+ifl3l06 oKL6IOlUuyQK2Vd8DrQRZbLrAfHxzMWtVpT+KNExqy1VGx5eKghgex7yV ykXhQEuPptyl/wJEv1QTf0lQccx4DQQjZ2xY+q+YCWHcZQA7IBG5++l9a E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BhAgB4/VVX/5pdJa1bgm5NVn0Grl6Ge?= =?us-ascii?q?4R9gXkXAQyFbwKBNDgUAQEBAQEBAWUnhEUBAQEEAQEBGlELEAIBCBEDAQIkBAc?= =?us-ascii?q?hBgsUCQgBAQQBDQWIFQMXDrYxDYQMAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ?= =?us-ascii?q?4RNgkOCHYU6BY4eiXY0AYYChimBeoFphFCIZYdvh2oBHjaCBxwWgTVuiRp/AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.26,429,1459814400"; d="scan'208,217";a="110462752" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2016 22:53:03 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u56Mr3uo018502 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jun 2016 22:53:03 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 6 Jun 2016 18:53:02 -0400 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1104.009; Mon, 6 Jun 2016 18:53:02 -0400 From: "Anoop Kapoor (ankapoor)" To: Tony Przygienda , Susan Hares Thread-Topic: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) Thread-Index: AdHAElYAB9sVfa6xQkej61auMDdHAwAVO0SA//+LiAA= Date: Mon, 6 Jun 2016 22:53:02 +0000 Message-ID: References: <017501d1c01a$41156960$c3403c20$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.119.53] Content-Type: multipart/alternative; boundary="_000_D37B4CC317DB21ankapoorciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 22:53:07 -0000 --_000_D37B4CC317DB21ankapoorciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support From: Idr > on behalf of = Tony Przygienda > Date: Monday, June 6, 2016 at 3:49 PM To: Susan Hares > Cc: "idr@ietf.org" > Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announce= ment - 2 week WG Adoption call (6/6 to 6/20) support On Mon, Jun 6, 2016 at 10:38 AM, Susan Hares > wrote: This begins a 2 week WG Adoption call for draft-keyupate-idr-bgp-attribute-= announcement. You can find the draft at: https://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-attribute-announcem= ent/ This draft defines attribute extensions that help confine the scope of Opti= onal attributes within a given AS or a given BGP member-AS in Confederation= . In your comments please include: 1) "Support" or "No support" for this draft as an IDR WG draft, 2) Experiences with debugging optional attributes errors that this dra= ft would aid, 3) Deployments that use AS confederations where this draft's ability t= o confined scope of the optional attributes would help restrict errors, Sue Hares and John Scudder _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr -- We've heard that a million monkeys at a million keyboards could produce the= complete works of Shakespeare; now, thanks to the Internet, we know that i= s not true. -Robert Wilensky --_000_D37B4CC317DB21ankapoorciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <8EBA5B4B09477E478EE5D3962F99AAE2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support

From: Idr <idr-bounces@ietf.org> on behalf of Tony Przygiend= a <tonysietf@gmail.com> Date: Monday, June 6, 2016 at 3:49 = PM
To: Susan Hares <shares@ndzh.com>
Cc: "idr@ietf.org" <idr@ietf.= org>
Subject: Re: [Idr] WG Adoption of d= raft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6= to 6/20)

support

On Mon, Jun 6, 2016 at 10:38 AM, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week WG Adoption call for draft-keyu= pate-idr-bgp-attribute-announcement.  You can find the draft at:

https://datatrack= er.ietf.org/doc/draft-keyupate-idr-bgp-attribute-announcement/

 

This draft defines attribute extensions that help co= nfine the scope of Optional attributes within a given AS or a given BGP mem= ber-AS in Confederation.   In your comments please include:

1)      “Support” or “No support” for = this draft as an IDR WG draft,

2)      Experiences with debugging optional attributes errors = that this draft would aid,

3)      Deployments that use AS confederations where this draf= t’s ability to confined scope of the optional attributes would help r= estrict errors,

 

 

Sue Hares and John Scudder  

 

 

 


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr




--
We’ve heard that a million monkeys at a million keyboards coul= d produce the complete works of Shakespeare; now, thanks to the Internet, w= e know that is not true.=
—Robert Wilensky
--_000_D37B4CC317DB21ankapoorciscocom_-- From nobody Mon Jun 6 16:21:34 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F25512D954 for ; Mon, 6 Jun 2016 16:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiMeApjPnUIf for ; Mon, 6 Jun 2016 16:21:32 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27DC812D668 for ; Mon, 6 Jun 2016 16:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11850; q=dns/txt; s=iport; t=1465255292; x=1466464892; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=I5rA1h2OsJ51knqp37Cyk0HjPgs1ibxQM/t4lyuY4gM=; b=DbtxOdBOGRpJPCJjKeNWFlyCLJlHYaJvJ2A+pCMaiHYaAC8+5ETKvOP4 rKSpUluIx2Klzm4IxWe1typ100E50zXAav8QNZxEuOleUX4sGSM1S8aqu MjXK9gS8sPk9p6kxjsxk5hT6Z4X4MldAWc1Nywy3kkNk4we9xjo+Tpdu+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAgBGBFZX/5pdJa1bgm5NVn0GtVmEf?= =?us-ascii?q?YF5FwEMhW8CHIEYOBQBAQEBAQEBZSeERgEBBAEBARoGSwsQAgEIDi0EAwICAiU?= =?us-ascii?q?LFBEBAQQOBYgvDqkhkS4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYgeCIJOh0Erg?= =?us-ascii?q?i4FmEgBhgKIIwqBX4RQiGWPWQEeNoIHHBaBNW6JGn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,429,1459814400"; d="scan'208,217";a="110477498" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2016 23:21:31 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u56NLUJF001084 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jun 2016 23:21:31 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 6 Jun 2016 19:21:30 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 6 Jun 2016 19:21:30 -0400 From: "Acee Lindem (acee)" To: Susan Hares Thread-Topic: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) Thread-Index: AdHAElYAB9sVfa6xQkej61auMDdHAwAWVj4A Date: Mon, 6 Jun 2016 23:21:30 +0000 Message-ID: References: <017501d1c01a$41156960$c3403c20$@ndzh.com> In-Reply-To: <017501d1c01a$41156960$c3403c20$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: multipart/alternative; boundary="_000_EFCF14239C7E4F2A87793A938970A934ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 23:21:33 -0000 --_000_EFCF14239C7E4F2A87793A938970A934ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NClRoYW5rcywNCkFjZWUNCg0KT24gSnVuIDYsIDIwMTYsIGF0IDE6MzggUE0sIFN1 c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+IHdyb3Rl Og0KDQpUaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1rZXl1 cGF0ZS1pZHItYmdwLWF0dHJpYnV0ZS1hbm5vdW5jZW1lbnQuICBZb3UgY2FuIGZpbmQgdGhlIGRy YWZ0IGF0Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2V5dXBhdGUt aWRyLWJncC1hdHRyaWJ1dGUtYW5ub3VuY2VtZW50Lw0KDQpUaGlzIGRyYWZ0IGRlZmluZXMgYXR0 cmlidXRlIGV4dGVuc2lvbnMgdGhhdCBoZWxwIGNvbmZpbmUgdGhlIHNjb3BlIG9mIE9wdGlvbmFs IGF0dHJpYnV0ZXMgd2l0aGluIGEgZ2l2ZW4gQVMgb3IgYSBnaXZlbiBCR1AgbWVtYmVyLUFTIGlu IENvbmZlZGVyYXRpb24uICAgSW4geW91ciBjb21tZW50cyBwbGVhc2UgaW5jbHVkZToNCjEpICAg ICAg4oCcU3VwcG9ydOKAnSBvciDigJxObyBzdXBwb3J04oCdIGZvciB0aGlzIGRyYWZ0IGFzIGFu IElEUiBXRyBkcmFmdCwNCjIpICAgICAgRXhwZXJpZW5jZXMgd2l0aCBkZWJ1Z2dpbmcgb3B0aW9u YWwgYXR0cmlidXRlcyBlcnJvcnMgdGhhdCB0aGlzIGRyYWZ0IHdvdWxkIGFpZCwNCjMpICAgICAg RGVwbG95bWVudHMgdGhhdCB1c2UgQVMgY29uZmVkZXJhdGlvbnMgd2hlcmUgdGhpcyBkcmFmdOKA mXMgYWJpbGl0eSB0byBjb25maW5lZCBzY29wZSBvZiB0aGUgb3B0aW9uYWwgYXR0cmlidXRlcyB3 b3VsZCBoZWxwIHJlc3RyaWN0IGVycm9ycywNCg0KDQpTdWUgSGFyZXMgYW5kIEpvaG4gU2N1ZGRl cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0K --_000_EFCF14239C7E4F2A87793A938970A934ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <04B58DCCB7BB1B459AD08966507A7481@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KU3VwcG9ydC4mbmJzcDsNCjxkaXYg Y2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BY2VlPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVuIDYsIDIwMTYsIGF0IDE6MzggUE0sIFN1c2FuIEhh cmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIiBjbGFzcz0iIj5zaGFyZXNA bmR6aC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBz dHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgQWRvcHRpb24g Y2FsbCBmb3IgZHJhZnQta2V5dXBhdGUtaWRyLWJncC1hdHRyaWJ1dGUtYW5ub3VuY2VtZW50LiZu YnNwOyBZb3UgY2FuIGZpbmQgdGhlIGRyYWZ0IGF0OjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rZXl1cGF0ZS1pZHItYmdwLWF0dHJpYnV0ZS1h bm5vdW5jZW1lbnQvIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7IiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1r ZXl1cGF0ZS1pZHItYmdwLWF0dHJpYnV0ZS1hbm5vdW5jZW1lbnQvPC9hPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NClRoaXMgZHJhZnQgZGVmaW5lcyBhdHRyaWJ1dGUgZXh0ZW5z aW9ucyB0aGF0IGhlbHAgY29uZmluZSB0aGUgc2NvcGUgb2YgT3B0aW9uYWwgYXR0cmlidXRlcyB3 aXRoaW4gYSBnaXZlbiBBUyBvciBhIGdpdmVuIEJHUCBtZW1iZXItQVMgaW4gQ29uZmVkZXJhdGlv bi4mbmJzcDsmbmJzcDsgSW4geW91ciBjb21tZW50cyBwbGVhc2UgaW5jbHVkZTo8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0IDAuNWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyB0ZXh0LWluZGVudDogLTAuMjVpbjsiIGNsYXNzPSIiPg0KPHNwYW4gY2xh c3M9IiI+MSk8c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3NwYW4+4oCcU3VwcG9ydOKAnSBvciDigJxObw0K IHN1cHBvcnTigJ0gZm9yIHRoaXMgZHJhZnQgYXMgYW4gSURSIFdHIGRyYWZ0LDxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAuNWluOyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyB0ZXh0LWluZGVu dDogLTAuMjVpbjsiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+Mik8c3BhbiBzdHlsZT0iZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48L3NwYW4+RXhwZXJpZW5jZXMgd2l0aA0KIGRlYnVnZ2luZyBvcHRpb25hbCBhdHRyaWJ1dGVz IGVycm9ycyB0aGF0IHRoaXMgZHJhZnQgd291bGQgYWlkLDxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0IDAuNWluOyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyB0ZXh0LWluZGVudDogLTAuMjVpbjsi IGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+Myk8c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250 LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3NwYW4+RGVw bG95bWVudHMgdGhhdA0KIHVzZSBBUyBjb25mZWRlcmF0aW9ucyB3aGVyZSB0aGlzIGRyYWZ04oCZ cyBhYmlsaXR5IHRvIGNvbmZpbmVkIHNjb3BlIG9mIHRoZSBvcHRpb25hbCBhdHRyaWJ1dGVzIHdv dWxkIGhlbHAgcmVzdHJpY3QgZXJyb3JzLDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpw IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQpTdWUgSGFyZXMgYW5kIEpvaG4gU2N1ZGRlciAmbmJzcDs8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBm bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SWRyDQogbWFpbGluZyBsaXN0PC9z cGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86SWRyQGll dGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPklkckBpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs YXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZHIiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHI8 L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_EFCF14239C7E4F2A87793A938970A934ciscocom_-- From nobody Mon Jun 6 17:29:40 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D55912D976; Mon, 6 Jun 2016 17:29:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607002936.13635.87266.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 17:29:36 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-aspath-orf-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 00:29:36 -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 of the IETF. Title : Analysis of Existing work for I2NSF Authors : Susan Hares Keyur Patel Filename : draft-ietf-idr-aspath-orf-11.txt Pages : 7 Date : 2016-06-06 Abstract: This document defines a new Outbound Router Filter type for BGP, termed "Aspath Outbound Route Filter", that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-aspath-orf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-aspath-orf-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 Mon Jun 6 23:59:58 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F9012D1BD; Mon, 6 Jun 2016 23:59:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607065957.13786.68330.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 23:59:57 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-eag-distribution-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 06:59:57 -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 of the IETF. Title : Distribution of MPLS-TE Extended admin Group Using BGP Authors : Zitao Wang Qin Wu Jeff Tantsura Filename : draft-ietf-idr-eag-distribution-02.txt Pages : 5 Date : 2016-06-06 Abstract: As MPLS-TE network grows, administrative Groups advertised as a fixed-length 32-bit Bitmask is quite constraining. "Extended Administrative Group" IGP TE extensions sub-TLV defined in [RFC7308] is introduced to provide for additional administrative groups (link colors) beyond the current limit of 32. This document describes extensions to BGP protocol, that can be used to distribute extended administrative groups in MPLS-TE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-eag-distribution/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-eag-distribution-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-eag-distribution-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 7 15:02:43 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F31012D094; Tue, 7 Jun 2016 15:02:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607220238.13804.82231.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 15:02:38 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:02:38 -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 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-07.txt Pages : 7 Date : 2016-06-07 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 or the Hold Time expires. 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: https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-gr-notification-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 7 15:09:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE19A12D89A; Tue, 7 Jun 2016 15:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY9YVtfmODck; Tue, 7 Jun 2016 15:09:01 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0099.outbound.protection.outlook.com [23.103.200.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5630F12D5FC; Tue, 7 Jun 2016 15:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h3n043cocQ6vgJHBfRDQOsffZFL04DBzg4wqtskdKXw=; b=AgrkxIDnAeSNXqcK2Uf/kP5GFzk8K3CSjfFbgohLWKcVw/VQjIz0AkhUbi21nlDgqwMPVBFNUrzoCZA8OWuko/HLlTQ5wjBoU27veSrLLFamuuhq7Qt683XawvXxS/W6PftROWwSQDraeeelRaYC7PAHbsbyp076GPj/sUaWiqk= Received: from BL2PR09MB1123.namprd09.prod.outlook.com (10.167.102.151) by BL2PR09MB1121.namprd09.prod.outlook.com (10.167.102.149) with Microsoft SMTP Server (TLS) id 15.1.511.8; Tue, 7 Jun 2016 22:08:43 +0000 Received: from BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) by BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) with mapi id 15.01.0511.010; Tue, 7 Jun 2016 22:08:43 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Susan Hares , "idr@ietf.org" Thread-Topic: WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) Thread-Index: AdHAEXYm+R0yr9NBRVeLkrezdS25EQA9XwKQ Date: Tue, 7 Jun 2016 22:08:43 +0000 Message-ID: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> In-Reply-To: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: c1fb5d25-b0ff-4561-e528-08d38f204a3f x-microsoft-exchange-diagnostics: 1; BL2PR09MB1121; 5:t44lXflmmqOM8BDMNt+FW7aNnaz66TD48HqPaBfXWgCqsUAFUdl3chNiSWGEt/9Os+YvfLXwhB3m7rT96f/SAa8vfqtIb7WL+yyVw59jpq8iOz/JIBGVCeDsC3lYXy8iACDNreL2pN0QfA6IkLyLBg==; 24:9SUawoYqb25ESYRs5Mhb9V5jdyWMtelXn1jtu0FhhbL9Xc0ZJOj918+jYt57x9zejd9jsM5pEf3E+xNomwyaT54cRnQgTfEQPJguAy2tMaI=; 7:YIaiczMHwVxFrSfIeRhDH6juKOmbCiVolc3k6s1lpSfSNJ7yiT9q+jFCKtRWmfte+UdiaCsQqsc5d7/YyYX42tBGF4LJpG5D9wppIwrKQv2xBZlD10llu5W5LiPWuBmF9vmN81JPkuaoa2i/msmzBsrKMrMIDRqd2d84WdB1vyMlpU+0UTVrH1ZSRGIFSz9fZmBp3ZnxnRm/5PyYS+o0bgXYpUIv5Rum1Df4bndVxJ8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR09MB1121; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BL2PR09MB1121; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB1121; x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(5423002)(9686002)(230783001)(101416001)(561944003)(5004730100002)(99286002)(86362001)(19580395003)(54356999)(50986999)(76176999)(68736007)(87936001)(5003600100002)(105586002)(790700001)(19625215002)(3846002)(5008740100001)(6116002)(16236675004)(102836003)(76576001)(586003)(66066001)(33656002)(2906002)(4326007)(11100500001)(3280700002)(106356001)(5002640100001)(10400500002)(3660700001)(189998001)(2900100001)(15975445007)(74316001)(2950100001)(81166006)(8936002)(8676002)(81156014)(19300405004)(122556002)(2501003)(92566002)(5001770100001)(97736004)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB1121; H:BL2PR09MB1123.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR09MB11233AF9434057E641967E9E845D0BL2PR09MB1123namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 22:08:43.5704 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB1121 Archived-At: Cc: "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:09:04 -0000 --_000_BL2PR09MB11233AF9434057E641967E9E845D0BL2PR09MB1123namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not support WG adoption of the draft in its current form. I have read the draft. This draft has two parts: (1) modification of BGP Open to include BGP role, and (2) a proposal for route leak detection/mitigation/prevention. I would encourage the first part to be written as a separate draft in itsel= f. This effort may have broader utility besides assisting with route leaks solution. Route leak detection-mitigation draft can (should) refer to the BGP open policy draft, and should say how the BGP role info can be utilized in the solution. The above mentioned second part seems to be a compromised subset of the proposal in the existing WG draft [ietf-idr-route-leak-detection-mitiga= tion]. The bgp-open-policy draft proposes a single OTC flag per update (as opposed to one flag per AS-hop). This lacks efficacy as explained with examples in Section 5.5 of [ietf-idr-route-leak-detection-mitigation] and also in ref [1] noted below. In contrast, [ietf-idr-route-leak-detection-mitigation] proposes an RLP flag per AS-hop, which is shown to work well (i.e. more robust in the presence of errors and partial deployment) for route leak detection (see Section 5.5 for details). The IDR and SIDR WGs have discussed the solution mechanisms over the past three or more years. The exiting WG draft factors in those discussions and feedback, and also documents the discussions in detail in Section 5 (design rationale). The bgp-open-policy draft seems to overlook one key design principle as noted above. Also, the bgp-open-policy draft mixes up detection and mitigation into one combined algorithm. (Mitigation belongs largely in the operator policy space.) In contrast, [ietf-idr-route-leak-detection-mitigation] describes the RLP encoding and detection separately. It leaves the mitigation method entirely to the operator, while providing only an example of a mitigation policy. The operator uses the detection algorithm as a tool to inform their own policy when it comes to mitigation. Further, the existing WG draft offers a description of a common practice (followed by major ISPs) for an intra-AS route tagging (see Section 3.2). This mechanism conveys from ingress to egress routers the peering info necessary to prevent route leaks that are under control of the AS locally. Sriram [1] see slides 5-9 of https://www.ietf.org/proceedings/95/slides/slides-95-= idr-13.pdf --_000_BL2PR09MB11233AF9434057E641967E9E845D0BL2PR09MB1123namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do= not support WG adoption of the draft in its current form.

 

I ha= ve read the draft.

This= draft has two parts: (1) modification of BGP Open to include BGP role,

and = (2) a proposal for route leak detection/mitigation/prevention.

 

I wo= uld encourage the first part to be written as a separate draft in itself.

This= effort may have broader utility besides assisting with

rout= e leaks solution. Route leak detect= ion-mitigation draft can (should)

refer to the BGP= open policy draft, and should

say how the BGP = role info can be utilized in the solution.

&nbs= p;

The = above mentioned second part seems to be a compromised subset of

the = proposal in the existing WG draft [ietf-idr-route-leak-detection-mitigation= ].

The = bgp-open-policy draft proposes a single OTC flag per update

(as = opposed to one flag per AS-hop).

This= lacks efficacy as explained with examples in Section 5.5 of

[iet= f-idr-route-leak-detection-mitigation] and also in ref [1] noted below.

In c= ontrast, [ietf-idr-route-leak-detection-mitigation] proposes

an R= LP flag per AS-hop, which is shown to work well

(i.e= . more robust in the presence of errors and partial deployment)

for = route leak detection (see Section 5.5 for details). 

 

The = IDR and SIDR WGs have discussed the solution mechanisms

over= the past three or more years. The exiting WG draft factors in

thos= e discussions and feedback, and also documents the discussions

in d= etail in Section 5 (design rationale). The bgp-open-policy draft

seem= s to overlook one key design principle as noted above.  

 

Also= , the bgp-open-policy draft mixes up detection and mitigation

into= one combined algorithm.

(Mit= igation belongs largely in the operator policy space.)

In c= ontrast, [ietf-idr-route-leak-detection-mitigation] describes

the = RLP encoding and detection separately.

It l= eaves the mitigation method entirely to the operator,

whil= e providing only an example of a mitigation policy.

The = operator uses the detection algorithm as a tool to

info= rm their own policy when it comes to mitigation.

 

Furt= her, the existing WG draft offers a description of a common practice

(fol= lowed by major ISPs) for an intra-AS route tagging (see Section 3.2).

This= mechanism conveys from ingress to egress routers the peering info

nece= ssary to prevent route leaks that are under control of the AS locally. = ; 

 

Srir= am

 

[1] = see slides 5-9 of https://www.ietf.org/proceedings/95/slides/slides-95-idr-= 13.pdf

 

 

 

--_000_BL2PR09MB11233AF9434057E641967E9E845D0BL2PR09MB1123namp_-- From nobody Tue Jun 7 15:16:52 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 389AB12D8A6; Tue, 7 Jun 2016 15:16:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607221651.13645.16458.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 15:16:51 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-enhanced-gr-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:16:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Accelerated Routing Convergence for BGP Graceful Restart Authors : Keyur Patel Enke Chen Rex Fernando John Scudder Filename : draft-ietf-idr-enhanced-gr-06.txt Pages : 9 Date : 2016-06-07 Abstract: In this document we specify extensions to BGP graceful restart in order to avoid unnecessary transmission of the routing information preserved across a session restart, thus accelerating the routing convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-enhanced-gr/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-enhanced-gr-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-enhanced-gr-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 7 16:18:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787F812D129; Tue, 7 Jun 2016 16:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e462qr7olF-e; Tue, 7 Jun 2016 16:17:33 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0106.outbound.protection.outlook.com [23.103.201.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E60912D8C7; Tue, 7 Jun 2016 16:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Zq7MHLT3RcTOac6ny22Zom+iLLyLfuM1SOpQaOHaWrc=; b=N7jlMqV/0Lv91R1VCCG8YAxJccU3SDQHJKC087VXVFqqyey6nMQWTQXgFIdSI7uiEAJqtvIdTL4m8WxnJR1bEElYPUkMU6YVstgtTzPehR7ki3F4gdtq0jiXpBzXuIItY7KsyDv1gPiORf8NBcnyHrDe/XzAuTQirP3sfO2duBQ= Received: from BL2PR09MB1123.namprd09.prod.outlook.com (10.167.102.151) by BL2PR09MB1121.namprd09.prod.outlook.com (10.167.102.149) with Microsoft SMTP Server (TLS) id 15.1.511.8; Tue, 7 Jun 2016 23:14:06 +0000 Received: from BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) by BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) with mapi id 15.01.0511.010; Tue, 7 Jun 2016 23:14:06 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "Osborne, Eric" , Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) Thread-Index: AdHAEXYm+R0yr9NBRVeLkrezdS25EQAAqhngAD9OpKA= Date: Tue, 7 Jun 2016 23:14:06 +0000 Message-ID: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5E@USIDCWVEMBX03.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5E@USIDCWVEMBX03.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: a50b3eb8-4c4b-4a56-af34-08d38f296c95 x-microsoft-exchange-diagnostics: 1; BL2PR09MB1121; 5:uJ4HWJ8AMXpL7uRACan9bD7MvNSwHOY9qga4F1k7+4L+KOaWZlsdLvsnsL9c7BU0JzvGlFoOmRIczoNkOQtP+IfIHOTsf9wooReS1GcBAkMSblPSIpnex1HSj5x6pByaYNcjQOrNOWX4JTFiqpHVDg==; 24:Mk7UXl8Zu5oRSizh9MhevTZHQVZWMFNdu89Z+ubrQdJubcz7CvPs0DaIWuYTCssTDHKfTtSxzDBfIcaOb8cJsf1aGhO+q2PUFdr0Gw1IvpY=; 7:5FJE2+/lgFWvchbUuzOMI7ERPvCvbCwJpZy7DG2tHMnLrV04foYN0LeDQCGLoyL4dh4uzTblfG+9iW4O8VNuWOZST0iT60AQllN9UHLDL3caIvzJZNzauRrWIuVJHJxYZaDHCjLIRsGKbtGFnRdBWbW28TRENu33la9wR361d2VH3wo6DCBeS8B+LavKXLvfnJTrp4Y1/6AkPVQzVb98I4UPBouwqqUBy1YRJSrrIkg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR09MB1121; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BL2PR09MB1121; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB1121; x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(5423002)(230783001)(9686002)(101416001)(561944003)(5004730100002)(99286002)(86362001)(19580395003)(54356999)(50986999)(76176999)(68736007)(87936001)(5003600100002)(105586002)(790700001)(19625215002)(3846002)(5008740100001)(6116002)(102836003)(16236675004)(76576001)(586003)(66066001)(33656002)(2906002)(4326007)(11100500001)(3280700002)(106356001)(5002640100001)(10400500002)(3660700001)(189998001)(15975445007)(2950100001)(74316001)(2900100001)(19617315012)(8936002)(81166006)(8676002)(81156014)(19300405004)(122556002)(2501003)(92566002)(5001770100001)(97736004)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB1121; H:BL2PR09MB1123.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR09MB112327B7295773B20DF5C63F845D0BL2PR09MB1123namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 23:14:06.3489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB1121 Archived-At: Cc: "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 23:17:48 -0000 --_000_BL2PR09MB112327B7295773B20DF5C63F845D0BL2PR09MB1123namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, >4) I just briefly skimmed detection-mitigation, and that seems like a >much more heavyweight way to implement the same sort of end behavior. On what basis? The OTC flag (one for the whole update) in the bgp-open-policy draft has in essence the same semantics as the RLP flag (one per AS-hop). In both cases, by setting the flag the sender is indicating that the route is being sent to a customer or a lateral peer, and hence SHOULD NOT be sent by the receiving AS or another AS down the path to its provider or lateral peer. So hard to say that one proposal is more heavy weight than the other in principle. Also, please see the point made in my other post about the inefficacy of a single OTC flag for the whole update (as proposed in bgp-open-policy): http://www.ietf.org/mail-archive/web/idr/current/msg15745.html You may also see a detailed discussion in Section 5.5 of https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-= 03 Sriram --_000_BL2PR09MB112327B7295773B20DF5C63F845D0BL2PR09MB1123namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 

>4) I just briefly skimmed detection-mitigatio= n, and that seems like a

>much more heavyweight way to implement the sa= me sort of end behavior. 

 

On what basis?

The OTC flag (one for the whole update) in the bg= p-open-policy draft

has in essence the same semantics as the RLP flag= (one per AS-hop).

In both cases, by setting the flag the sender is = indicating that

the route is being sent to a customer or a latera= l peer, and hence

SHOULD NOT be sent by the receiving AS or another= AS down the path

to its provider or lateral peer.

So hard to say that one proposal is more heavy we= ight

than the other in principle.

 

Also, please see the point made in my other post = about the inefficacy

of a single OTC flag for the whole update (as pro= posed in bgp-open-policy):

http://www.ietf.org/mail-archive/web/idr/current/= msg15745.html

You may also see a detailed discussion in Section= 5.5 of

https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-= mitigation-03

 

Srir= am

 

--_000_BL2PR09MB112327B7295773B20DF5C63F845D0BL2PR09MB1123namp_-- From nobody Wed Jun 8 06:26:11 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D3112D0E0; Wed, 8 Jun 2016 06:26:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160608132609.19947.65371.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2016 06:26:09 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 13:26: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 of the IETF. Title : Applying BGP flowspec rules on a specific interface set Authors : Stephane Litkowski Adam Simpson Keyur Patel Jeff Haas Filename : draft-ietf-idr-flowspec-interfaceset-01.txt Pages : 14 Date : 2016-06-08 Abstract: BGP Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP Flow-spec where flow specifications are used to maintain some access control lists at network boundary. BGP Flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP Flow-spec ([RFC5575]) introduces the notion of flow specification (which describes the matching criterion) and traffic filtering actions. The flow specification is encoded as part of the NLRI while the traffic filtering actions are encoded as extended communities. The combination of a flow specification and one or more actions is known as a flow specification rule. [RFC5575] does not detail where the flow specification rules need to be applied. Besides the flow specification and traffic filtering actions, this document introduces the notion of traffic filtering scope in order to drive where a particular rule must be applied. In particular, this document introduces the "interface-set" traffic filtering scope that could be used in parallel of traffic filtering actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers about groups of interfaces where the rule must be applied. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-interfaceset-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 Wed Jun 8 06:29:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D031F12D0C9 for ; Wed, 8 Jun 2016 06:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqcd3AHHvJjq for ; Wed, 8 Jun 2016 06:29:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D4E12B03D for ; Wed, 8 Jun 2016 06:29:22 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id D0E7C3B493A for ; Wed, 8 Jun 2016 15:29:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B4CC635C097 for ; Wed, 8 Jun 2016 15:29:20 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0294.000; Wed, 8 Jun 2016 15:29:20 +0200 From: To: "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt Thread-Index: AQHRwYlWKLZD+NLIGEG6YM0mvKsgaJ/fj6NA Date: Wed, 8 Jun 2016 13:29:19 +0000 Message-ID: <2211_1465392560_57581DB0_2211_5567_1_9E32478DFA9976438E7A22F69B08FF921BC4661E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20160608132609.19947.65371.idtracker@ietfa.amsl.com> In-Reply-To: <20160608132609.19947.65371.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.8.125417 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 13:29:25 -0000 Hi IDR, This is a new version of the interface-set flowspec extension. As there was some misinterpretation of what the interface-set is (it is not= a match (as not part of NLRI) and it is not an action), we defined the not= ion of traffic filtering scope. Interface-set would be the first traffic fi= ltering scope defined, and nothing prevents to create new ones if required. Best Regards, Stephane -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Wednesday, June 08, 2016 15:26 To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Applying BGP flowspec rules on a specific interfa= ce set Authors : Stephane Litkowski Adam Simpson Keyur Patel Jeff Haas Filename : draft-ietf-idr-flowspec-interfaceset-01.txt Pages : 14 Date : 2016-06-08 Abstract: BGP Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP Flow-spec where flow specifications are used to maintain some access control lists at network boundary. BGP Flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP Flow-spec ([RFC5575]) introduces the notion of flow specification (which describes the matching criterion) and traffic filtering actions. The flow specification is encoded as part of the NLRI while the traffic filtering actions are encoded as extended communities. The combination of a flow specification and one or more actions is known as a flow specification rule. [RFC5575] does not detail where the flow specification rules need to be applied. Besides the flow specification and traffic filtering actions, this document introduces the notion of traffic filtering scope in order to drive where a particular rule must be applied. In particular, this document introduces the "interface-set" traffic filtering scope that could be used in parallel of traffic filtering actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers about groups of interfaces where the rule must be applied. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-flowspec-interfaceset-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 Wed Jun 8 09:02:45 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C53412D77B; Wed, 8 Jun 2016 09:02:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2831Q5M49rZT; Wed, 8 Jun 2016 09:02:29 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E1312DA0E; Wed, 8 Jun 2016 09:02:07 -0700 (PDT) Received: from [216.82.242.131] by server-14.bemta-8.messagelabs.com id CF/22-29672-D7148575; Wed, 08 Jun 2016 16:02:05 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-7.tower-76.messagelabs.com!1465401724!53782478!1 X-Originating-IP: [209.245.18.37] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18657 invoked from network); 8 Jun 2016 16:02:05 -0000 Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-7.tower-76.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jun 2016 16:02:05 -0000 Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id 94C611DEBC; Wed, 8 Jun 2016 16:02:04 +0000 (GMT) Received: from USIDCWVEQCCAS01.corp.global.level3.com (4.72.133.42) by USIDCWVEHT01.corp.global.level3.com (10.1.142.31) with Microsoft SMTP Server (TLS) id 14.3.279.2; Wed, 8 Jun 2016 10:02:04 -0600 Received: from USIDCWVEMBX03.corp.global.level3.com ([fe80::e849:4e57:cb74:ed58]) by USIDCWVEQCCAS01.corp.global.level3.com ([::1]) with mapi id 14.03.0279.002; Wed, 8 Jun 2016 10:02:03 -0600 From: "Osborne, Eric" To: "Sriram, Kotikalapudi (Fed)" , Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) Thread-Index: AQHRwRJMgil6Oa8w7kqPKG95vvnvsp/fuVJg Date: Wed, 8 Jun 2016 16:02:03 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEB0B5@USIDCWVEMBX03.corp.global.level3.com> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5E@USIDCWVEMBX03.corp.global.level3.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.207] Content-Type: multipart/alternative; boundary="_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEB0B5USIDCWVEMBX03co_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 16:02:31 -0000 --_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEB0B5USIDCWVEMBX03co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On the basis that detection-mitigation adds an attribute to every route (po= tentially per AS hop), whereas bgp-open keeps it to the neighbor relationsh= ip. One attribute per route * 600k routes * N hops seems like a lot if I c= an do the same thing with an open message. I'm also concerned about how mu= ch I should trust the RLP bit from an AS a few hops away. Getting it from = my directly connected neighbor is one thing, but if I can trust the source = to do the right thing with the RLP bit, why can't I just assume they won't = leak YouTube-ish things to begin with? It feels a little like "...you SHOU= LD not rob this bank, but if you're going to rob the bank you MUST NOT wear= a mask". At least with my directly connected neighbor I have some underst= anding of what the policy should be, and a phone number I can call if thing= s are super-hosed. I didn't see a discussion of scale anywhere in detection-mitigation. This = seems like such an obvious scale difference to me that I worry that "hard t= o say that one proposal is more heavy weight than the other in principle" m= eans I'm missing something. Feel free to enlighten me as needed. eric From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sriram@nist.gov] Sent: Tuesday, June 07, 2016 7:14 PM To: Osborne, Eric ; Susan Hares ;= idr@ietf.org Cc: draft-ietf-idr-route-leak-detection-mitigation@ietf.org; 'John G. Scudd= er' Subject: RE: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 t= o 6/20/2016) Eric, >4) I just briefly skimmed detection-mitigation, and that seems like a >much more heavyweight way to implement the same sort of end behavior. On what basis? The OTC flag (one for the whole update) in the bgp-open-policy draft has in essence the same semantics as the RLP flag (one per AS-hop). In both cases, by setting the flag the sender is indicating that the route is being sent to a customer or a lateral peer, and hence SHOULD NOT be sent by the receiving AS or another AS down the path to its provider or lateral peer. So hard to say that one proposal is more heavy weight than the other in principle. Also, please see the point made in my other post about the inefficacy of a single OTC flag for the whole update (as proposed in bgp-open-policy): http://www.ietf.org/mail-archive/web/idr/current/msg15745.html You may also see a detailed discussion in Section 5.5 of https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-= 03 Sriram --_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEB0B5USIDCWVEMBX03co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On the basis that dete= ction-mitigation adds an attribute to every route (potentially per AS hop),= whereas bgp-open keeps it to the neighbor relationship.  One attribut= e per route * 600k routes * N hops seems like a lot if I can do the same thing with an open message.  I’= m also concerned about how much I should trust the RLP bit from an AS a few= hops away.  Getting it from my directly connected neighbor is one thi= ng, but if I can trust the source to do the right thing with the RLP bit, why can’t I just assume they won’t lea= k YouTube-ish things to begin with?  It feels a little like “...= you SHOULD not rob this bank, but if you’re going to rob the bank you= MUST NOT wear a mask”.  At least with my directly connected neighbor I have some understanding of what the policy should be, and a pho= ne number I can call if things are super-hosed.

 

I didn’t see = a discussion of scale anywhere in detection-mitigation.  This seems li= ke such an obvious scale difference to me that I worry that “h= ard to say that one proposal is more heavy weight than the other in principle” means I’= m missing something.  Feel free to enlighten me as needed.=

 

 

 

eric=

 

 

From: Sriram, Kotikalapudi (Fed) [mailto:koti= kalapudi.sriram@nist.gov]
Sent: Tuesday, June 07, 2016 7:14 PM
To: Osborne, Eric <eric.osborne@level3.com>; Susan Hares <s= hares@ndzh.com>; idr@ietf.org
Cc: draft-ietf-idr-route-leak-detection-mitigation@ietf.org; 'John G= . Scudder' <jgs@bgp.nu>
Subject: RE: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy -= (6/6 to 6/20/2016)

 

Eric,

 

>4) I just briefly skimmed detection-mitigatio= n, and that seems like a

>much more heavyweight way to implement the sa= me sort of end behavior. 

 

On what basis?

The OTC flag (one for the whole update) in the bg= p-open-policy draft

has in essence the same semantics as the RLP flag= (one per AS-hop).

In both cases, by setting the flag the sender is = indicating that

the route is being sent to a customer or a latera= l peer, and hence

SHOULD NOT be sent by the receiving AS or another= AS down the path

to its provider or lateral peer.

So hard to say that one proposal is more heavy we= ight

than the other in principle.

 

Also, please see the point made in my other post = about the inefficacy

of a single OTC flag for the whole update (as pro= posed in bgp-open-policy):

http://www.ietf.org/mail-archive/web/idr/current/= msg15745.html

You may also see a detailed discussion in Section= 5.5 of

https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-= mitigation-03

 

Srir= am

 

--_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEB0B5USIDCWVEMBX03co_-- From nobody Wed Jun 8 12:21:13 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7829312D5D1 for ; Wed, 8 Jun 2016 12:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qatM0Bx9pZjh for ; Wed, 8 Jun 2016 12:21: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 AA29812B053 for ; Wed, 8 Jun 2016 12:21:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQL51744; Wed, 08 Jun 2016 19:21:05 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 8 Jun 2016 20:21:05 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Wed, 8 Jun 2016 12:21:02 -0700 From: Lucy yong To: "stephane.litkowski@orange.com" , "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt Thread-Index: AQHRwYlWKLZD+NLIGEG6YM0mvKsgaJ/fj6NAgAA+7fA= Date: Wed, 8 Jun 2016 19:21:02 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57296547@dfweml501-mbb> References: <20160608132609.19947.65371.idtracker@ietfa.amsl.com> <2211_1465392560_57581DB0_2211_5567_1_9E32478DFA9976438E7A22F69B08FF921BC4661E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <2211_1465392560_57581DB0_2211_5567_1_9E32478DFA9976438E7A22F69B08FF921BC4661E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.123] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D57296547dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.57587022.0313, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ac895ac9c52c2015985f3cdf9c13dbd6 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 19:21:11 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D57296547dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephane, et al, I read this draft and have some comments. * I like this approach to treat interfaceset as FS scope, not as ma= tching, nor as action. * Instead of using group-identifier to express interfaceset in the = EC, IMO: it is better to use interface type to identify the interfaceset an= d have IANA registry for each interface type. This will make interworking/a= utomation easier. Any thought on that? * IMO: Content in Sn 6 is very useful, however it does not belong t= o this draft. These rules for processing permanent configured and BGP FS ap= ply to all BGP FS. It should be documented in one draft and apply to all BG= P FS drafts. FS ACL is just one type of BGP FS, there are others as well. T= he rules should be described in general term. * I am not clear what first sentence means in Sn 7. Does it say tha= t some interfaces may not be able to support the rules? Pls explain. Thanks, Lucy -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: Wednesday, June 08, 2016 8:29 AM To: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt Hi IDR, This is a new version of the interface-set flowspec extension. As there was some misinterpretation of what the interface-set is (it is not= a match (as not part of NLRI) and it is not an action), we defined the not= ion of traffic filtering scope. Interface-set would be the first traffic fi= ltering scope defined, and nothing prevents to create new ones if required. Best Regards, Stephane -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Wednesday, June 08, 2016 15:26 To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Applying BGP flowspec rules on a specific interfa= ce set Authors : Stephane Litkowski Adam Simpson Keyur Patel Jeff Haas Filename : draft-ietf-idr-flowspec-interfaceset-01.txt Pages : 14 Date : 2016-06-08 Abstract: BGP Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP Flow-spec where flow specifications are used to maintain some access control lists at network boundary. BGP Flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP Flow-spec ([RFC5575]) introduces the notion of flow specification (which describes the matching criterion) and traffic filtering actions. The flow specification is encoded as part of the NLRI while the traffic filtering actions are encoded as extended communities. The combination of a flow specification and one or more actions is known as a flow specification rule. [RFC5575] does not detail where the flow specification rules need to be applied. Besides the flow specification and traffic filtering actions, this document introduces the notion of traffic filtering scope in order to drive where a particular rule must be applied. In particular, this document introduces the "interface-set" traffic filtering scope that could be used in parallel of traffic filtering actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers about groups of interfaces where the rule must be applied. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-flowspec-interfaceset-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_2691CE0099834E4A9C5044EEC662BB9D57296547dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephane, et al,

 

I read this draft and have some comments.

·         I like this approach to treat interfaceset a= s FS scope, not as matching, nor as action.

·         Instead of using group-identifier to express= interfaceset in the EC, IMO: it is better to use interface type to identif= y the interfaceset and have IANA registry for each interface type. This wil= l make interworking/automation easier. Any thought on that?

·         IMO: Content in Sn 6 is very useful, however= it does not belong to this draft. These rules for processing permanent con= figured and BGP FS apply to all BGP FS. It should be documented in one draf= t and apply to all BGP FS drafts. FS ACL is just one type of BGP FS, there are others as well. The rules sho= uld be described in general term.

·         I am not clear what first sentence means in = Sn 7. Does it say that some interfaces may not be able to support the rules= ? Pls explain.

 

Thanks,

Lucy

 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com
Sent: Wednesday, June 08, 2016 8:29 AM
To: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt<= /p>

 

Hi IDR,

 

This is a new version of the interface-set flowsp= ec extension.

 

As there was some misinterpretation of what the i= nterface-set is (it is not a match (as not part of NLRI) and it is not an a= ction), we defined the notion of traffic filtering scope. Interface-set wou= ld be the first traffic filtering scope defined, and nothing prevents to create new ones if required.

 

Best Regards,

 

Stephane

 

 

-----Original Message-----

From: Idr [mailto:idr-bounces@= ietf.org] On Behalf Of internet-drafts@ietf.org

Sent: Wednesday, June 08, 2016 15:26

To: i-d-announce@ietf.org

Cc: idr@ietf.org

Subject: [Idr] I-D Action: draft-ietf-idr-flowspe= c-interfaceset-01.txt

 

 

A New Internet-Draft is available from the on-lin= e Internet-Drafts directories.

This draft is a work item of the Inter-Domain Rou= ting of the IETF.

 

        Title&= nbsp;          : Applying BGP = flowspec rules on a specific interface set

        Author= s         : Stephane Litkowski=

        &= nbsp;           &nbs= p;     Adam Simpson

        &= nbsp;           &nbs= p;     Keyur Patel

        &= nbsp;           &nbs= p;     Jeff Haas

      Filename &nbs= p;      : draft-ietf-idr-flowspec-interfaceset-01.= txt

      Pages  &= nbsp;        : 14

      Date  &n= bsp;         : 2016-06-08

 

Abstract:

   BGP Flow-spec is an extension to BGP= that allows for the

   dissemination of traffic flow specif= ication rules.  The primary

   application of this extension is DDo= S mitigation where the flowspec

   rules are applied in most cases to a= ll peering routers of the

   network.

 

   This document will present another u= se case of BGP Flow-spec where

   flow specifications are used to main= tain some access control lists at

   network boundary.  BGP Flowspec= is a very efficient distributing

   machinery that can help in saving OP= EX while deploying/updating ACLs.

   This new application requires flow s= pecification rules to be applied

   only on a specific subset of interfa= ces and in a specific direction.

 

   The current specification of BGP Flo= w-spec ([RFC5575]) introduces the

   notion of flow specification (which = describes the matching criterion)

   and traffic filtering actions. = The flow specification is encoded as

   part of the NLRI while the traffic f= iltering actions are encoded as

   extended communities.  The comb= ination of a flow specification and

   one or more actions is known as a fl= ow specification rule.  [RFC5575]

   does not detail where the flow speci= fication rules need to be

   applied.

 

   Besides the flow specification and t= raffic filtering actions, this

   document introduces the notion of tr= affic filtering scope in order to

   drive where a particular rule must b= e applied.  In particular, this

   document introduces the "interf= ace-set" traffic filtering scope that

   could be used in parallel of traffic= filtering actions (marking,

   rate-limiting ...).  The purpos= e of this extension is to inform

   remote routers about groups of inter= faces where the rule must be

   applied.

 

   This extension can also be used in a= DDoS mitigation context where a

   provider wants to apply the filterin= g only on specific peers.

 

 

 

The IETF datatracker status page for this draft i= s:

https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-inter= faceset/

 

There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-= 01

 

A diff from the previous version is available at:=

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-flowsp= ec-interfaceset-01

 

 

Please note that it may take a couple of minutes = from the time of submission until the htmlized version and diff are availab= le at tools.ietf.org.

 

Internet-Drafts are also available by anonymous F= TP at:

<= span style=3D"color:windowtext;text-decoration:none">ftp://ftp.ietf.org/int= ernet-drafts/

 

_______________________________________________

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 et= re diffuses, exploites ou copies sans autorisation. Si vous avez recu ce me= ssage par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant susceptibles d'alteration, Orange decline toute responsa= bilite si ce message a ete altere, deforme ou falsifie. Merci.

 

This message and its attachments may contain conf= idential or privileged information that may be protected by law; they shoul= d 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 fo= r messages that have been modified, changed or falsified.

Thank you.

 

_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf= .org/mailman/listinfo/idr

--_000_2691CE0099834E4A9C5044EEC662BB9D57296547dfweml501mbb_-- From nobody Thu Jun 9 06:55:34 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DA812D63A for ; Thu, 9 Jun 2016 06:55:32 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=highloadlab-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsH2CqCoSQsG for ; Thu, 9 Jun 2016 06:55:30 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4114812D18C for ; Thu, 9 Jun 2016 06:55:30 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id m62so38470941iof.0 for ; Thu, 09 Jun 2016 06:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highloadlab-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=om/g/IkG4+18CHWdrJeQ/ES7hyQmJ6w5mGzHwKFCHgo=; b=Saff2xZvGjQw6EwL51M6dPMKLvZS9P+Kke6VR/ofE7ELs6BtGDE3q9WDTaJVxgoOeW mMVO9HwIsL8b+XSSdJD2tHIKPdo4274db1xKTo2p80ob1/lIDv/MDc3ca7II0Wo30ZiU r5o3/+4y/W97N9ya9X5Bw51B+G/8breCd+6tdeD5Y3lMQq1DCu2iwTeZn0xemy3ge47/ eADXtqbqErOQ61lINQCQ2bJxE5uzsVcB9HZ32+xYobnzgoYIQkN4rwRqNVsKAqsdoYsC dRwWbsK60W2hG6Qau/bJsM+MbCU/42GkbD0obr+XfpE5k19suYBNESaU1H0N6uUZGFhc mv2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=om/g/IkG4+18CHWdrJeQ/ES7hyQmJ6w5mGzHwKFCHgo=; b=mqwvFrBYrIWOL6cSa+cSI3nez221FTIrk/8ipUnnuUu598mlNogH3+EGBPUXtffG0s XcudSYmvexvYb6iq/YdwMskFDMzUhGVBsY8rYitf91PqyyNGB3f+vnMy/h6RBi7LlKeL 9hZECfYqP/kFaG9NxTSFpKj7oTxCMHcHibFXdb2FcE14XGfKnPEeJ+C98J9hDWDCEr30 6QHoMUzppGprHPQM+M8lWZKmbJsVCG6RQQY5P6Lg+rXNFIlz6uu9qey9nH/ILWbnd13t s7d2GAi+jyNwqg9Tv5gqNzvlJ4EwbESoxrmbljhWCqvjLbl7ZyBPItL7TdjZjCotCAf3 NhfA== X-Gm-Message-State: ALyK8tLVaCyM8t5WiZpBQZV7o+TBybJc76QGdVPJuyBf+x0ShpJEjm8EP8avBK6Uax4rxCLq2AnmTPH8w7Gy6g== X-Received: by 10.107.9.144 with SMTP id 16mr17122830ioj.196.1465480529409; Thu, 09 Jun 2016 06:55:29 -0700 (PDT) MIME-Version: 1.0 Sender: aa@highloadlab.com Received: by 10.64.146.129 with HTTP; Thu, 9 Jun 2016 06:55:28 -0700 (PDT) X-Originating-IP: [176.110.121.30] In-Reply-To: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> From: Alexander Azimov Date: Thu, 9 Jun 2016 16:55:28 +0300 X-Google-Sender-Auth: ux7dSTS2lFxudLvtfBFSuWmq1nY Message-ID: To: "idr@ietf.org" Content-Type: multipart/alternative; boundary=001a113f95f26196180534d8c679 Archived-At: Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 13:55:33 -0000 --001a113f95f26196180534d8c679 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Copy of my yesterday's email, just in case, if it was not delivered: Dear Sriram, Thank you for your input, but I think most of your concerns come out of confusion. Let me clarify them one by one. My comments are included in text below 2016-06-08 1:08 GMT+03:00 Sriram, Kotikalapudi (Fed) < kotikalapudi.sriram@nist.gov>: The above mentioned second part seems to be a compromised subset of > the proposal in the existing WG draft > [ietf-idr-route-leak-detection-mitigation]. > > The bgp-open-policy draft proposes a single OTC flag per update > > (as opposed to one flag per AS-hop). > > This lacks efficacy as explained with examples in Section 5.5 of > > [ietf-idr-route-leak-detection-mitigation] and also in ref [1] noted belo= w. > > In contrast, [ietf-idr-route-leak-detection-mitigation] proposes > > an RLP flag per AS-hop, which is shown to work well > > (i.e. more robust in the presence of errors and partial deployment) > > for route leak detection (see Section 5.5 for details). > RLP, as its proposed could not be used on =E2=80=9Cper update basis=E2=80= =9D. But OTC, with use of proposed roles, does not share these limitations. This is an excerpt from [ietf-idr-route-leak-detection-mitigation] draft section 5.5: +-----+ +-----+ peer to peer (p2p) relation +-----+ p--| AS1 |-------->| AS2 |----------------------------->| AS3 | +-----+ +-----+ Update --> +-----+ Method B: {p [AS2 AS1] RLP=3D1} In our proposal, AS2 would set OTC flag only if AS3 is not supporting roles, and this can easily be retrieved from OPEN message. So the problem is not with per-update basis approach, but with RLP attribute itself. I'd like to mention, that well designed per-update attribute has one more obvious advantage: fixed size. > Also, the bgp-open-policy draft mixes up detection and mitigation > > into one combined algorithm. > > (Mitigation belongs largely in the operator policy space.) > > In contrast, [ietf-idr-route-leak-detection-mitigation] describes > > the RLP encoding and detection separately. > > It leaves the mitigation method entirely to the operator, > > while providing only an example of a mitigation policy. > > The operator uses the detection algorithm as a tool to > > inform their own policy when it comes to mitigation. > When dealing with route leaks it=E2=80=99s important to solve the problem. = Not just detect it. What do you think is easier - to prevent leaking or to track down route leak and stop it propagation? I think there is no real choice - create or not to create route leak, likewise it is now with community usage. That is why our draft, with help of roles, proposes full automation for both leak prevention inside AS and leak detection for leaks that are made by third parties. I believe it could provide complex approach to solve the problem. --001a113f95f26196180534d8c679 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= Copy of my yesterday's email, just in case, if it was not delivered:

<= /div>

Dear Sriram,

Thank you for your input, but = I think most of your concerns come out of confusion. Let me clarify them on= e by one. My comments are included in text below

= 2016-06-08 1:08 GMT+03:00 Sriram, Kotikalapudi (Fed)=C2= =A0<kotikalapudi.sriram@nist.gov>:
=C2=A0= The above mentioned second part = seems to be a compromised subset of

the proposal in the existing WG draft [ietf-idr-route-leak-det= ection-mitigation].

The bgp-open-policy draft proposes a single OTC flag per upd= ate

(= as opposed to one flag per AS-hop).

This lacks efficacy as explained with examp= les in Section 5.5 of

[ietf-idr-route-leak-detection-mitigation] and also in ref= [1] noted below.

In contrast, [ietf-idr-route-leak-detection-mitigation] propos= es

an= RLP flag per AS-hop, which is shown to work well

<= p>(i.e. more robust in the prese= nce of errors and partial deployment)

for route leak detection (see Section 5.5 = for details).=C2=A0

RLP, as its pr= oposed could not be used on =E2=80=9Cper update basis=E2=80=9D. But OTC, wi= th use of proposed roles, does not share these limitations. This is an exce= rpt from [ietf-idr-route-leak-detection-mitigation] draft section 5.5:

        +-----+         +---=
--+  peer to peer (p2p) relation +-----+
     p--| AS1 |-------->| AS2 |----------------------------->| AS3 |
        +-----+         +-----+            Update -->        +-----+=C2=
=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Method B: {p [AS2 AS1] RLP=3D1}

In our proposal, AS2 would set OTC flag only if AS3 is not supporting= roles, and this can easily be retrieved from OPEN message. So the problem = is not with per-update basis approach, but with RLP attribute itself. I'= ;d like to mention, that well designed per-update attribute has one more ob= vious advantage: fixed size.=C2= =A0

= Also, the bgp-open-policy draft mixes up detection and mitigation=

into one combi= ned algorithm.

(Mitigation belongs largely in the operator policy space.)=

In contrast= , [ietf-idr-route-leak-detection-mitigation] describes=

the RLP encoding and dete= ction separately.

It leaves the mitigation method entirely to the operator,

while pro= viding only an example of a mitigation policy.

<= span style=3D"font-size:12pt;color:black">The operator uses the detection a= lgorithm as a tool to

inform their own policy when it comes to mitigation.

When dealing with route leaks it=E2=80= =99s important to solve the problem. Not just detect it. What do you think = is easier - to prevent leaking or to track down route leak and stop it prop= agation? I think there is no real choice - create or not to create route le= ak, likewise it is now with community usage. That is why our draft, with he= lp of roles, proposes full automation for both leak prevention inside AS an= d leak detection for leaks that are made by third parties. I believe it cou= ld provide complex approach to solve the problem.
--001a113f95f26196180534d8c679-- From nobody Thu Jun 9 07:00:41 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A1312D09F for ; Thu, 9 Jun 2016 07:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=highloadlab-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScLDZE6kRUOg for ; Thu, 9 Jun 2016 07:00:37 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FACA12D65F for ; Thu, 9 Jun 2016 07:00:35 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id m62so38608748iof.0 for ; Thu, 09 Jun 2016 07:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highloadlab-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GIy4DM82sbRxH3jYVXV4KigRyN2e91g9TklvcV7t+Ss=; b=0xNq/bEvIj5DUxT0065ocznWEkYwNF8xx/V1s9GahJdPZrUY5Qilat0FOsZ3bFg3G8 6NB1a14DQSxgrZ9ZUI3sgpU6l1avMl8pi//rf3YNjavnBNf1+sDCygHx87QikwcX0cpm r86gfS6ibMQUCpruvkruTDlpGipRirkYThug60TVRNrMe5y0Qb2gIvn2MNRSvilPiHD2 PleoC0zxftruHBveTzYReAEXhZ3M4Ri+3jaDOU+sXqQkt55gMOHEsP4hUBHl6bC0AkBM J6hEOTWxam51sdyBgQ/Jww/cYq2HIcUkDt6HS0wTu2Wxswk7UKodZts27gTdHDxRdfCr MmMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GIy4DM82sbRxH3jYVXV4KigRyN2e91g9TklvcV7t+Ss=; b=HDDZRp2//aXpXt/ig4KtOGaQeky11tP/7ux53DyHSw25levJKPZt9UvCUua25MjI2R ISpv57LLU+JaB1s6rrTP1Glg1W87UN5O0bxJ1ZTrzK8j6TYrjEIUMpjc7jPxqq3ZAsf9 QXDrQtS9hXQyZpVO4gD6oJePoeWqyxEPTGXnr9liBBE/Kx6Ig5NwCK+8b5JfEUCen2ZQ 5fGPURBQEO0+VHvKvgqrWUQQmEMAq9cNSSBjTQXNerVU6Pqwdw5Xui4WUtleB0a+hHOJ gNOIbKZCD/IUocchvod5T72GtRzyaaD0snEp538hJf0x8qERobs+zbO2kWvq/lZrpoZ7 Et9g== X-Gm-Message-State: ALyK8tKLQWocmNVJzkw3DyM5rl4C3EpgddDrwDHg8NAar7bEMgICRoPc6P/8PCrWhNy7xifZFiTlUjo3DqziJA== X-Received: by 10.107.9.144 with SMTP id 16mr17163937ioj.196.1465480833091; Thu, 09 Jun 2016 07:00:33 -0700 (PDT) MIME-Version: 1.0 Sender: aa@highloadlab.com Received: by 10.64.146.129 with HTTP; Thu, 9 Jun 2016 07:00:32 -0700 (PDT) X-Originating-IP: [176.110.121.30] In-Reply-To: <021401d1c026$e2d3b2f0$a87b18d0$@ndzh.com> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <021401d1c026$e2d3b2f0$a87b18d0$@ndzh.com> From: Alexander Azimov Date: Thu, 9 Jun 2016 17:00:32 +0300 X-Google-Sender-Auth: R421jlDtiXf-L5wufsvvV6Rr6wI Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a113f95f27b709e0534d8d85b Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "John G. Scudder" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 14:00:40 -0000 --001a113f95f27b709e0534d8d85b Content-Type: text/plain; charset=UTF-8 Dear Susan, As far as I understand your question, there is IPR on this draft. 2016-06-06 22:09 GMT+03:00 Susan Hares : > Randy, Eugene, Alexander: > > Would you please indicate whether you know of IPR on > draft-ymbk-idr-bgp-open-policy? I forgot to add this to the WG adoption > call. > > Sue Hares > > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, June 06, 2016 3:02 PM > To: Susan Hares > Cc: idr@ietf.org; draft-ietf-idr-route-leak-detection-mitigation@ietf.org; > 'John G. Scudder' > Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 > to > 6/20/2016) > > this wg seems to have the strange convention of co-authors speaking for > draft adoption, advancement, ... so i support this draft for adoption, > though it is a bit embarrassing to do so. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@qrator.net | visit: www.qrator.net --001a113f95f27b709e0534d8d85b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Susan,

As far as I understand your= question, there is IPR on this draft.

2016-06-06 22:09 GMT+03:00 Susan Hares <sha= res@ndzh.com>:
Randy,=C2=A0= =C2=A0Eugene,=C2=A0 =C2=A0Alexander:

Would you please indicate whether you know of IPR on
draft-ymbk-idr-bgp-open-policy?=C2=A0 I forgot to add this to the WG adopti= on
call.

Sue Hares

-----Original Message-----
From: Randy Bush [mailto:randy@psg.com= ]
Sent: Monday, June 06, 2016 3:02 PM
To: Susan Hares
Cc: idr@ietf.org; draft-ietf-idr-route-= leak-detection-mitigation@ietf.org;
'John G. Scudder'
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 t= o
6/20/2016)

this wg seems to have the st= range convention of co-authors speaking for
draft adoption, advancement, ...=C2=A0 so i support this draft for adoption= ,
though it is a bit embarrassing to do so.

randy

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr



--
=
| Alexander Azimov =C2=A0| HLL l QRATOR<= /font>
| tel.: +7 499 241 81 92
=
| mob.: +7 915 360 08 86
| skype: mitradir
| m= ailto:=C2=A0aa@qrator.ne= t
| visit:=C2=A0www.qrator.net
--001a113f95f27b709e0534d8d85b-- From nobody Thu Jun 9 07:23:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BED112D7FF; Thu, 9 Jun 2016 07:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aisaxbuVhZgW; Thu, 9 Jun 2016 07:23:35 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B9E12D7FB; Thu, 9 Jun 2016 07:23:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86; From: "Susan Hares" To: "'Alexander Azimov'" References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <021401d1c026$e2d3b2f0$a87b18d0$@ndzh.com> In-Reply-To: Date: Thu, 9 Jun 2016 10:23:36 -0400 Message-ID: <004401d1c25a$833d8fb0$89b8af10$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01D1C238.FC2D0120" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF7c7sVleQLlnYVEOfAIkuoqhZdLAK2zILgAng4sXEBYZTCE6BZSKcw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 14:23:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0045_01D1C238.FC2D0120 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alexander:=20 =20 Thank you for letting us know there is IPR on this draft.=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alexander Azimov Sent: Thursday, June 09, 2016 10:01 AM To: Susan Hares Cc: idr@ietf.org; = draft-ietf-idr-route-leak-detection-mitigation@ietf.org; John G. Scudder Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - = (6/6 to 6/20/2016) =20 Dear Susan, =20 As far as I understand your question, there is IPR on this draft. =20 2016-06-06 22:09 GMT+03:00 Susan Hares : Randy, Eugene, Alexander: Would you please indicate whether you know of IPR on draft-ymbk-idr-bgp-open-policy? I forgot to add this to the WG adoption call. Sue Hares -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, June 06, 2016 3:02 PM To: Susan Hares Cc: idr@ietf.org; = draft-ietf-idr-route-leak-detection-mitigation@ietf.org; 'John G. Scudder' Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - = (6/6 to 6/20/2016) this wg seems to have the strange convention of co-authors speaking for draft adoption, advancement, ... so i support this draft for adoption, though it is a bit embarrassing to do so. randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 --=20 | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@qrator.net | visit: www.qrator.net =20 ------=_NextPart_000_0045_01D1C238.FC2D0120 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Alexander:

 

Thank you for letting us know there is IPR on this draft. =

 

Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alexander = Azimov
Sent: Thursday, June 09, 2016 10:01 AM
To: = Susan Hares
Cc: idr@ietf.org; = draft-ietf-idr-route-leak-detection-mitigation@ietf.org; John G. = Scudder
Subject: Re: [Idr] WG Adoption call = draft-ymbk-idr-bgp-open-policy - (6/6 to = 6/20/2016)

 

Dear = Susan,

 

As far as I understand your question, there is IPR on = this draft.

 

2016-06-06 22:09 GMT+03:00 Susan Hares <shares@ndzh.com>:

Randy,  =  Eugene,   Alexander:

Would you please indicate = whether you know of IPR on
draft-ymbk-idr-bgp-open-policy?  I = forgot to add this to the WG adoption
call.

Sue = Hares

-----Original Message-----
From: Randy Bush [mailto:randy@psg.com]
Sent: Monday, June 06, 2016 3:02 PM
To: Susan Hares
Cc: idr@ietf.org; d= raft-ietf-idr-route-leak-detection-mitigation@ietf.org;
'John G. Scudder'
Subject: Re: = [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 = to
6/20/2016)

this wg seems to have the strange convention of = co-authors speaking for
draft adoption, advancement, ...  so i = support this draft for adoption,
though it is a bit embarrassing to = do = so.

randy

_______________________________________________Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr



 

-- =

| Alexander Azimov  | HLL l QRATOR

| tel.: +7 499 241 81 92

| mob.: +7 915 360 08 86

| skype: mitradir

| mailto: aa@qrator.net

| visit: www.qrator.net

------=_NextPart_000_0045_01D1C238.FC2D0120-- From nobody Thu Jun 9 07:29:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A593912D756 for ; Thu, 9 Jun 2016 07:29:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=highloadlab-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO1r-3_EVXQR for ; Thu, 9 Jun 2016 07:29:48 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E5112D740 for ; Thu, 9 Jun 2016 07:29:47 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id z189so155619508itg.0 for ; Thu, 09 Jun 2016 07:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highloadlab-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fComM6edhgX+pS4s6b98rXcv329bcfKX7CGXjSJnzBk=; b=IasJvUPYa9F3lNlQHLO2Rca80AjRYEelRyWv7Zo3bE1nsyaNj/zTEo82jP/3L1NWg6 CMT5G1jn6y3BbbWBDNS3er9aGCGfiyDT4EbZiD2+bEg5F1o5bBlWLQfEslOrP1WdwNqB FlZX/MV4XHUrd58Rh1ZRS5TyZ7wmWz8uBLAs3HZjhcDvmN3b16iq1HlDC7uBfVWW2VAl 4rCZRFq+DENciYhxlbbYV9r7RKUbSxpnCnEcXaN4fJMmn2pBS62SjKAAJwmpc0185/Mp uJ51ahrv3qJx1sb1whsRzXwyOOzuSmLI8f/ShZkILpsbfCrjvuAz4d/z6NwfH2PggqJ9 rOnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fComM6edhgX+pS4s6b98rXcv329bcfKX7CGXjSJnzBk=; b=CgwQqVshSkJ/YctcFq4tSXYxIcTCZrVAqTjebWx3nsr74pRSrRlCEc8IXpD+ZIaAO6 T6s4UHoR26oNIx6fhWemuI3lVEy+I8CNXuVCwB56S/fTe0Sa/a5Q6Gjshwdm2bpMC7cM M28OAzCpSdKd79j8A+9yq4K2xGj27rLhADaEj63osuEnqc0MXWzGmbDDR2vwSRI9qC0Z 52oVRWuFh0XxTfMq+Bof3QI3zNShgzTGpzNVS/Z4JRC50LvmA05nUSBhaPB6Ylk81QkF VvMaOk+xeLtXqNVA6w826emKSwGa+yikBb6jwI0UlEISbKqlHKM+rAO/hmd14TeHwycf 3QEA== X-Gm-Message-State: ALyK8tIcrzWM1A9mwRZbW8W9yXtGb+jekuLG2HhQKZal0amQydUh3c8L7Ih05ghmxYn3UfiEH8+y2DBp7seIAw== X-Received: by 10.36.61.199 with SMTP id n190mr18639333itn.64.1465482587141; Thu, 09 Jun 2016 07:29:47 -0700 (PDT) MIME-Version: 1.0 Sender: aa@highloadlab.com Received: by 10.64.146.129 with HTTP; Thu, 9 Jun 2016 07:29:46 -0700 (PDT) X-Originating-IP: [176.110.121.30] In-Reply-To: <004401d1c25a$833d8fb0$89b8af10$@ndzh.com> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <021401d1c026$e2d3b2f0$a87b18d0$@ndzh.com> <004401d1c25a$833d8fb0$89b8af10$@ndzh.com> From: Alexander Azimov Date: Thu, 9 Jun 2016 17:29:46 +0300 X-Google-Sender-Auth: Kg1HBvWFK13meoGuODuPTGRTDhM Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a11445222081a960534d94117 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "John G. Scudder" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 14:29:50 -0000 --001a11445222081a960534d94117 Content-Type: text/plain; charset=UTF-8 Ow, wow, NO IPR. Sorry. 2016-06-09 17:23 GMT+03:00 Susan Hares : > Alexander: > > > > Thank you for letting us know there is IPR on this draft. > > > > Sue > > > > *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Alexander Azimov > *Sent:* Thursday, June 09, 2016 10:01 AM > > *To:* Susan Hares > *Cc:* idr@ietf.org; > draft-ietf-idr-route-leak-detection-mitigation@ietf.org; John G. Scudder > *Subject:* Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - > (6/6 to 6/20/2016) > > > > Dear Susan, > > > > As far as I understand your question, there is IPR on this draft. > > > > 2016-06-06 22:09 GMT+03:00 Susan Hares : > > Randy, Eugene, Alexander: > > Would you please indicate whether you know of IPR on > draft-ymbk-idr-bgp-open-policy? I forgot to add this to the WG adoption > call. > > Sue Hares > > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, June 06, 2016 3:02 PM > To: Susan Hares > Cc: idr@ietf.org; draft-ietf-idr-route-leak-detection-mitigation@ietf.org; > 'John G. Scudder' > Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 > to > 6/20/2016) > > this wg seems to have the strange convention of co-authors speaking for > draft adoption, advancement, ... so i support this draft for adoption, > though it is a bit embarrassing to do so. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > > > -- > > | Alexander Azimov | HLL l QRATOR > > | tel.: +7 499 241 81 92 > > | mob.: +7 915 360 08 86 > > | skype: mitradir > > | mailto: aa@qrator.net > > | visit: www.qrator.net > -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@qrator.net | visit: www.qrator.net --001a11445222081a960534d94117 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ow, wow, NO IPR. Sorry.
2016-06-09 17:23 GMT+03:00 Susan Hares <shares@= ndzh.com>:

Alexander:

= =C2=A0

Thank you for letting us know there is IPR= on this draft.

=C2=A0

Sue

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

From: Idr [mailto:idr-bounces@ietf.org] On= Behalf Of Alexander Azimov
Sent: Thursday, June 09, 2016 10:= 01 AM


To: Susan Hares
Cc:= idr@ietf.org; draft-ietf-idr-route-leak-detection-mitigation@ietf.org= ; John G. Scudder
Subject: Re: [Idr] WG Adoption call draft-ymbk-= idr-bgp-open-policy - (6/6 to 6/20/2016)

=C2=A0

Dear Susan,

=C2=A0

As far as I un= derstand your question, there is IPR on this draft.

=

=C2=A0

2016-06-06 22:09 GMT+03:00 Susan Hares <shares@ndzh.com>:

<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Randy,=C2=A0 =C2=A0Eug= ene,=C2=A0 =C2=A0Alexander:

Would you please indicate whether you kn= ow of IPR on
draft-ymbk-idr-bgp-open-policy?=C2=A0 I forgot to add this = to the WG adoption
call.

Sue Hares

-----Original Mes= sage-----
From: Randy Bush [mailto:randy@psg.com]
Sent: Monday,= June 06, 2016 3:02 PM
To: Susan Hares
Cc: = idr@ietf.org; draft-ietf-idr-route-leak-detection-mitigation@ietf.org;
'John G. Scudder'
Subject: Re: [Idr] = WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to
6= /20/2016)

this wg = seems to have the strange convention of co-authors speaking for
draft ad= option, advancement, ...=C2=A0 so i support this draft for adoption,
tho= ugh it is a bit embarrassing to do so.

randy

________________= _______________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman= /listinfo/idr



=C2=A0

--

| Alexander Azim= ov =C2=A0| HLL l QRATOR

=

| tel.: +7 499 241 = 81 92

| mob.: +7 915 360 08 86

| skype: mitradir

| mai= lto:=C2=A0aa@qrator.net<= /a>




--
| Alexander Azimov =C2=A0| HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype:= mitradir
| mailto:=C2=A0aa@qrator.net
| visit:=C2=A0www.qrator.net
--001a11445222081a960534d94117-- From nobody Thu Jun 9 09:04:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D367012D85B; Thu, 9 Jun 2016 09:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUGNmqIJSFQX; Thu, 9 Jun 2016 09:04:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C8412D1DD; Thu, 9 Jun 2016 09:04:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bB2RA-0001Dr-Vu; Thu, 09 Jun 2016 16:04:05 +0000 Date: Thu, 09 Jun 2016 09:04:04 -0700 Message-ID: From: Randy Bush To: Alexander Azimov In-Reply-To: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <021401d1c026$e2d3b2f0$a87b18d0$@ndzh.com> <004401d1c25a$833d8fb0$89b8af10$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "John G. Scudder" , Susan Hares Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 16:04:09 -0000 > Ow, wow, NO IPR. Sorry. whew! From nobody Thu Jun 9 09:32:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F5D12D87C for ; Thu, 9 Jun 2016 09:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbonRDJ6mMtk for ; Thu, 9 Jun 2016 09:32:47 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BF712D861 for ; Thu, 9 Jun 2016 09:32:46 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id v199so115223252wmv.0 for ; Thu, 09 Jun 2016 09:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YYH3f438f8+F2Cckpb6ptz14JLrygX1Nj6eD4+Q6kDU=; b=GKWvw9uqYoybLY8MbgWgH303uBjioHLJL2ApdwYREJ7s8885dT/J1XwaJbojYhJSgY uJF87ADieg7oeTl5ISwIXz5fl1PaSc+qvuMtuVnzaStPmvzHzO47EZaxxu6wUVZV1E+d 7ONpn+z5Nani+1t+L4Mk9lwBN9MNw44Ug6auY0A+Ba/4DSReE3b93pQ/opUyb+L72Rb2 qyLWJK2L1NuyQDHxi3DuTVhzLfTiLK88eqk2sePEZ6XzV6SGBWMhN16nYlFycIPPA8Bn /EKFkrKzHeTzYTGezTKRYFMA8Zt3WcRA72D/PAS6LhbcohFFHKm3J3F8IA6v3WON6Kjs LpSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YYH3f438f8+F2Cckpb6ptz14JLrygX1Nj6eD4+Q6kDU=; b=UHYS7rysJCoqlYGfyIJ6ZW+mi0m5geDSjh5z0a7SPAHUeV9doB9V9t8hGgWCsZ8EjX DpzG2E0LoTcahORnZXeYG3WmsgsegFEGPangy5SK7puyeeRP7wX/tZaa30cXhR/DTnXD DJhtGmdZ0ScDfk3brnh5w0srzfQwjzfr5Upa3bj+2RyIXCDcu1ukC8rF7RoYgheLZkEJ +tsAzAii8Gh/yP4iF98BPnWsUeZklspcHTjLEDBLEnQi7NxCwLWctL3YP+130VSzybuC dH6lp9KLlBhRML7NHmIQtWp3IZwSPJ+Phb1SJJxk5U7OzLQH1nLTeKSlSkXey+O+3XCi cGxA== X-Gm-Message-State: ALyK8tIzQNr7ie9EjsgyBzllejCIy9+05g6CfdjRA+PwjSmzo7zdpMqU+aBh9cseGVooKg== X-Received: by 10.28.46.71 with SMTP id u68mr10581786wmu.97.1465489964425; Thu, 09 Jun 2016 09:32:44 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:f948:e3f7:3d8c:2db8]) by smtp.gmail.com with ESMTPSA id u70sm21423517wmd.4.2016.06.09.09.32.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jun 2016 09:32:43 -0700 (PDT) Date: Thu, 9 Jun 2016 18:32:25 +0200 From: Job Snijders To: Susan Hares Message-ID: <20160609163225.GC2524@Vurt.local> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 16:32:49 -0000 Dear Authors, IDR group, I'd like to start by thanking you for putting thought and time into the route leak problem space. It is encouring to see fellow operators engage with the IETF community to address actual, day to day issues. On Mon, Jun 06, 2016 at 12:40:19PM -0400, Susan Hares wrote: > This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy. > You can find the draft at: > > https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/. > > In your comments on adopting this draft, please indicate: > > 1) "Support" or "no Support" No support. > 2) Do you feel this is a way to prevent route leaks? It certainly is a way. > 3) Are there any deployment issues that might prevent deployment > of this enhancement to BGP Open? I do not think that the OPEN moment in the lifecycle of a BGP session is the appropiate place for policy constructs like this. In practise it is probably not an issue when you have to flap a BGP session to change the relation between two ASNs, but it would be nice if this is not required (like today on most platforms). Secondly (and more importantly), the roles are not necessarily a BGP session-specific characteristic, but rather a prefix-specific property. The proposed OPEN method does not provide for this level granularity if I am reading it correctly. The method would affect all prefixes exchange over a BGP session, without exception. > 4) Does this interact with > draft-ietf-idr-route-leak-detection-mitigation? Yes, in terms of the problem being addressed. Kind regards, Job From nobody Thu Jun 9 10:15:49 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E0312D8BD for ; Thu, 9 Jun 2016 10:15: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=highloadlab-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyO-ixshrBbS for ; Thu, 9 Jun 2016 10:15:44 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69F512D8C1 for ; Thu, 9 Jun 2016 10:15:44 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id z189so159990954itg.0 for ; Thu, 09 Jun 2016 10:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highloadlab-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=csS2w8dYbHzGPQj12h837Wja2e/82ZRaa74hJCaWyP4=; b=bPGkwFz3yuey2bG5Rl+43EVH2egKtGhx0pQQgDu61H+d/NFIpC0/PgYtwoXKnSeVoe zRHgrGk862OhgArNN31LYZz4nRln2pgIrupGQb/pGvxmYT1uSFO+U7BHWpAXL9qB6rv3 vMNwMMGNQDFJZs99fjScRVJUfZrDWEj+nfqVHA4uEsTTeu0hkRuK7eUWsatd1oeH8XAr +Zv70xe6J/Xxu3w9b/YL1sUCNDL1GtCDWeZ5BRd3nJR8ia+HpvX9cD3OBLWYCmry20BD fk/3O9tpsl+lRBIduVehS6CrWR+ge4qwiFixgVhwL9r5eJp2WYaRPXGUgarPRBzjdvyB 9gFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=csS2w8dYbHzGPQj12h837Wja2e/82ZRaa74hJCaWyP4=; b=b2KSnKC2LkkApxj3M8FQAAYxvMrjSAwQEo2Fg7TVoYIm9u4TjzMm9GHX4oYPf41BEb 3Y2wtfLDn3orN0ixIHcbqt5HrgA61PXStMgaIF5NoSenZc+l/HAYFK7s7YZicnm6+YOR ba3KG8Vk86TMckphEgNmnOrVQO+iEcsW/okN8qBrUiEma5HUCpj5AuDufrQT62ULjgOh e8QK6ck61021PNDlbGRtfXsF0czoqeCoqvrACMEpc9KUns/j7DMdT3Iu1Vdih9H/9MF/ FJlMyBxYiX7TEOTG/ShII7aVikrXekXWGGoFdqHy2m8mFS1Vk+vQEHRT23xjDvRUERlF b7HQ== X-Gm-Message-State: ALyK8tKJSdXJXcAuF/Qh4VjBehMvkJfsiBT/CX9B1l0ToHSCtS4sQGbo28CtCsJpbtRDn6yCayJDGZm5u9FPQw== X-Received: by 10.36.104.2 with SMTP id v2mr24743976itb.64.1465492543830; Thu, 09 Jun 2016 10:15:43 -0700 (PDT) MIME-Version: 1.0 Sender: aa@highloadlab.com Received: by 10.64.146.129 with HTTP; Thu, 9 Jun 2016 10:15:43 -0700 (PDT) X-Originating-IP: [176.110.121.30] In-Reply-To: <20160609163225.GC2524@Vurt.local> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160609163225.GC2524@Vurt.local> From: Alexander Azimov Date: Thu, 9 Jun 2016 20:15:43 +0300 X-Google-Sender-Auth: 9oUp0-47Y-G4Fibd-ctA_wuE6dU Message-ID: To: Job Snijders Content-Type: multipart/alternative; boundary=001a11449c067f22440534db9206 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "John G. Scudder" , Susan Hares Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 17:15:48 -0000 --001a11449c067f22440534db9206 Content-Type: text/plain; charset=UTF-8 Dear Job, Thank you for joining discussion! I can't imagine situation when there would be changes in roles between two neighbors on regular basis. So, we should not suffer from lots of BGP flaps caused by roles. In second point you've highlighted most common concern about different prefix-based route policies in same BGP session. There are at least two workarounds: 1. Add 'custom' role and give in such sessions access to manual OTC configuration (there would be new appropriate pair of roles custom-custom) 2. Split such BGP sessions into two with different roles For myself I do prefer second option - I would like to see route leak mitigation as built in and fully automated mechanism, with no opportunity for 'fat fingers' get inside. This could bring additional work for NOC teams in short term, but in long term benefit from controlling neighbor configuration (especially in case of new ISPs) will fully cover the spent time. But what do you think according to your operational experience? 2016-06-09 19:32 GMT+03:00 Job Snijders : > Dear Authors, IDR group, > > I'd like to start by thanking you for putting thought and time into the > route leak problem space. It is encouring to see fellow operators engage > with the IETF community to address actual, day to day issues. > > On Mon, Jun 06, 2016 at 12:40:19PM -0400, Susan Hares wrote: > > This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy. > > You can find the draft at: > > > > https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/. > > > > In your comments on adopting this draft, please indicate: > > > > 1) "Support" or "no Support" > > No support. > > > 2) Do you feel this is a way to prevent route leaks? > > It certainly is a way. > > > 3) Are there any deployment issues that might prevent deployment > > of this enhancement to BGP Open? > > I do not think that the OPEN moment in the lifecycle of a BGP session is > the appropiate place for policy constructs like this. In practise it is > probably not an issue when you have to flap a BGP session to change the > relation between two ASNs, but it would be nice if this is not required > (like today on most platforms). > > Secondly (and more importantly), the roles are not necessarily a BGP > session-specific characteristic, but rather a prefix-specific property. > The proposed OPEN method does not provide for this level granularity if > I am reading it correctly. The method would affect all prefixes exchange > over a BGP session, without exception. > > > 4) Does this interact with > > draft-ietf-idr-route-leak-detection-mitigation? > > Yes, in terms of the problem being addressed. > > Kind regards, > > Job > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@qrator.net | visit: www.qrator.net --001a11449c067f22440534db9206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Job,

Thank you for joining discuss= ion!

I can't imagine situation when there= would be changes in roles between two neighbors on regular basis. So, we s= hould not suffer from lots of BGP flaps caused by roles.

In second point you've highlighted most common concern= about different prefix-based route policies in same BGP session. There are= at least two workarounds:
  1. Add 'custom' role= and give in such sessions access to manual OTC configuration (there would = be new appropriate pair of roles custom-custom)
  2. Split such BGP = sessions into two with different roles
= For myself I do prefer second option - I would like to see route leak mitig= ation as built in and fully automated mechanism, with no opportunity for &#= 39;fat fingers' get inside. This could bring additional work for NOC te= ams in short term, but in long term benefit from controlling neighbor confi= guration (especially in case of new ISPs) will fully cover the spent time. = But what do you think according to your operational experience?
<= br>

2016-06-09 19:32 GMT+03:00 Job Snijders = <job@instituut.ne= t>:
Dear Authors, IDR group,

I'd like to start by thanking you for putting thought and time into the=
route leak problem space. It is encouring to see fellow operators engage with the IETF community to address actual, day to day issues.

On Mon, Jun 06, 2016 at 12:40:19PM -0400, Susan Hares wrote:
> This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-poli= cy.
> You can find the draft at:
>
> https://datatracker.ietf.org/do= c/draft-ymbk-idr-bgp-open-policy/.
>
> In your comments on adopting this draft, please indicate:
>
> 1)=C2=A0 =C2=A0 =C2=A0 "Support" or "no Support"
No support.

> 2)=C2=A0 =C2=A0 =C2=A0 Do you feel this is a way to prevent route leak= s?

It certainly is a way.

> 3)=C2=A0 =C2=A0 =C2=A0 Are there any deployment issues that might prev= ent deployment
> of this enhancement to BGP Open?

I do not think that the OPEN moment in the lifecycle of a BGP sessio= n is
the appropiate place for policy constructs like this. In practise it is
probably not an issue when you have to flap a BGP session to change the
relation between two ASNs, but it would be nice if this is not required
(like today on most platforms).

Secondly (and more importantly), the roles are not necessarily a BGP
session-specific characteristic, but rather a prefix-specific property.
The proposed OPEN method does not provide for this level granularity if
I am reading it correctly. The method would affect all prefixes exchange over a BGP session, without exception.

> 4) Does this interact with
> draft-ietf-idr-route-leak-detection-mitigation?

Yes, in terms of the problem being addressed.

Kind regards,

Job

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr



--
=
| Alexander Azimov =C2=A0| HLL l QRATOR<= /font>
| tel.: +7 499 241 81 92
=
| mob.: +7 915 360 08 86
| skype: mitradir
| m= ailto:=C2=A0aa@qrator.ne= t
| visit:=C2=A0www.qrator.net
--001a11449c067f22440534db9206-- From nobody Thu Jun 9 10:28:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FF612B03F; Thu, 9 Jun 2016 10:27:59 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL109Px0Usy6; Thu, 9 Jun 2016 10:27:56 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A68512D188; Thu, 9 Jun 2016 10:27:56 -0700 (PDT) Received: from [216.82.241.195] by server-7.bemta-8.messagelabs.com id 79/96-14830-B17A9575; Thu, 09 Jun 2016 17:27:55 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-16.tower-119.messagelabs.com!1465493274!42814851!1 X-Originating-IP: [209.245.18.37] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18560 invoked from network); 9 Jun 2016 17:27:54 -0000 Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-16.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jun 2016 17:27:54 -0000 Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com [10.1.142.32]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client CN "USIDCWVEHT02.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id 4337E1DEBE; Thu, 9 Jun 2016 17:27:54 +0000 (GMT) Received: from USIDCWVEQCCAS04.corp.global.level3.com (4.72.133.44) by USIDCWVEHT02.corp.global.level3.com (10.1.142.32) with Microsoft SMTP Server (TLS) id 14.3.279.2; Thu, 9 Jun 2016 11:27:54 -0600 Received: from USIDCWVEMBX03.corp.global.level3.com ([fe80::e849:4e57:cb74:ed58]) by USIDCWVEQCCAS04.corp.global.level3.com ([4.72.133.44]) with mapi id 14.03.0279.002; Thu, 9 Jun 2016 11:27:53 -0600 From: "Osborne, Eric" To: Alexander Azimov , Job Snijders Thread-Topic: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) Thread-Index: AQHRwmyTIh9xLxm6hkqQUlM8iRp1op/hxNeA//+eFHA= Date: Thu, 9 Jun 2016 17:27:52 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEF772@USIDCWVEMBX03.corp.global.level3.com> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160609163225.GC2524@Vurt.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.206] Content-Type: multipart/alternative; boundary="_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEF772USIDCWVEMBX03co_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" , Susan Hares , "John G. Scudder" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 17:27:59 -0000 --_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEF772USIDCWVEMBX03co_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IGxpa2UgIzIuICBJdCBkb2VzbuKAmXQgbWFrZSBzZW5zZSB0byBtZSDigJMgYSBz aW5nbGUgbmVpZ2hib3IgbWF5IGhhdmUgc29tZSBjdXN0b21lciBhc3BlY3RzIGFuZCBzb21lIHBl ZXIgYXNwZWN0cywgYW5kIHNwbGl0dGluZyBhIHNpbmdsZSBCR1Agc2Vzc2lvbiBpbnRvIHR3byBp cyBjb25jZXB0dWFsbHkgd2VpcmQgYW5kIGFsc28gYSBodWdlIGNvZGUgdXBsaWZ0IG9uIGJvdGgg ZW5kcy4NCg0KIzEgbWFrZXMgc2Vuc2UgYW5kIGlzIGFsb25nIHRoZSBsaW5lcyBvZiB3aGF0IEkg d2FzIGhpbnRpbmcgYXQgaW4gbXkg4oCYc3VwcG9ydOKAmSDigJMgZG9u4oCZdCBqdXN0IGdpdmUg bWUgcGFzcy9mYWlsLCBnaXZlIG1lIGZsZXhpYmxlIGtub2JzIGluIGFuIGltcGxlbWVudGF0aW9u LiAgSSByZWFsaXplIHRoYXQgZG9pbmcgdGhpcyBwZXItcHJlZml4IGlzIGFub3RoZXQgd2F5IHRv IGRvIGl0LCBidXQgc2VlIG15IG90aGVyIGVtYWlsIHRvIFNyaXJhbSBmb3Igd2h5IEkgZG9u4oCZ dCBsaWtlIHBhdGggc3RhdGUgbXVjaC4NCg0KSSBzdXBwb3NlIEkgY291bGQgc2VlIG5vbi10cmFu c2l0aXZlIHBlci1wcmVmaXggYXMgYW5vdGhlciB3YXkgdG8gZG8gdGhpczsgaWYgaXQgd2FzIHRo YXQgdnMgb3BlbiBtZXNzYWdlLCB0aGVyZSBhcmUgZ29vZCBhcmd1bWVudHMgZWl0aGVyIHdheS4N Cg0KDQoNCg0KZXJpYw0KDQpGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEFsZXhhbmRlciBBemltb3YNClNlbnQ6IFRodXJzZGF5LCBKdW5lIDA5LCAy MDE2IDE6MTYgUE0NClRvOiBKb2IgU25pamRlcnMgPGpvYkBpbnN0aXR1dXQubmV0Pg0KQ2M6IGlk ckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pZHItcm91dGUtbGVhay1kZXRlY3Rpb24tbWl0aWdhdGlv bkBpZXRmLm9yZzsgSm9obiBHLiBTY3VkZGVyIDxqZ3NAYmdwLm51PjsgU3VzYW4gSGFyZXMgPHNo YXJlc0BuZHpoLmNvbT4NClN1YmplY3Q6IFJlOiBbSWRyXSBXRyBBZG9wdGlvbiBjYWxsIGRyYWZ0 LXltYmstaWRyLWJncC1vcGVuLXBvbGljeSAtICg2LzYgdG8gNi8yMC8yMDE2KQ0KDQpEZWFyIEpv YiwNCg0KVGhhbmsgeW91IGZvciBqb2luaW5nIGRpc2N1c3Npb24hDQoNCkkgY2FuJ3QgaW1hZ2lu ZSBzaXR1YXRpb24gd2hlbiB0aGVyZSB3b3VsZCBiZSBjaGFuZ2VzIGluIHJvbGVzIGJldHdlZW4g dHdvIG5laWdoYm9ycyBvbiByZWd1bGFyIGJhc2lzLiBTbywgd2Ugc2hvdWxkIG5vdCBzdWZmZXIg ZnJvbSBsb3RzIG9mIEJHUCBmbGFwcyBjYXVzZWQgYnkgcm9sZXMuDQoNCkluIHNlY29uZCBwb2lu dCB5b3UndmUgaGlnaGxpZ2h0ZWQgbW9zdCBjb21tb24gY29uY2VybiBhYm91dCBkaWZmZXJlbnQg cHJlZml4LWJhc2VkIHJvdXRlIHBvbGljaWVzIGluIHNhbWUgQkdQIHNlc3Npb24uIFRoZXJlIGFy ZSBhdCBsZWFzdCB0d28gd29ya2Fyb3VuZHM6DQoNCiAgMS4gIEFkZCAnY3VzdG9tJyByb2xlIGFu ZCBnaXZlIGluIHN1Y2ggc2Vzc2lvbnMgYWNjZXNzIHRvIG1hbnVhbCBPVEMgY29uZmlndXJhdGlv biAodGhlcmUgd291bGQgYmUgbmV3IGFwcHJvcHJpYXRlIHBhaXIgb2Ygcm9sZXMgY3VzdG9tLWN1 c3RvbSkNCiAgMi4gIFNwbGl0IHN1Y2ggQkdQIHNlc3Npb25zIGludG8gdHdvIHdpdGggZGlmZmVy ZW50IHJvbGVzDQpGb3IgbXlzZWxmIEkgZG8gcHJlZmVyIHNlY29uZCBvcHRpb24gLSBJIHdvdWxk IGxpa2UgdG8gc2VlIHJvdXRlIGxlYWsgbWl0aWdhdGlvbiBhcyBidWlsdCBpbiBhbmQgZnVsbHkg YXV0b21hdGVkIG1lY2hhbmlzbSwgd2l0aCBubyBvcHBvcnR1bml0eSBmb3IgJ2ZhdCBmaW5nZXJz JyBnZXQgaW5zaWRlLiBUaGlzIGNvdWxkIGJyaW5nIGFkZGl0aW9uYWwgd29yayBmb3IgTk9DIHRl YW1zIGluIHNob3J0IHRlcm0sIGJ1dCBpbiBsb25nIHRlcm0gYmVuZWZpdCBmcm9tIGNvbnRyb2xs aW5nIG5laWdoYm9yIGNvbmZpZ3VyYXRpb24gKGVzcGVjaWFsbHkgaW4gY2FzZSBvZiBuZXcgSVNQ cykgd2lsbCBmdWxseSBjb3ZlciB0aGUgc3BlbnQgdGltZS4gQnV0IHdoYXQgZG8geW91IHRoaW5r IGFjY29yZGluZyB0byB5b3VyIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2U/DQoNCg0KMjAxNi0wNi0w OSAxOTozMiBHTVQrMDM6MDAgSm9iIFNuaWpkZXJzIDxqb2JAaW5zdGl0dXV0Lm5ldDxtYWlsdG86 am9iQGluc3RpdHV1dC5uZXQ+PjoNCkRlYXIgQXV0aG9ycywgSURSIGdyb3VwLA0KDQpJJ2QgbGlr ZSB0byBzdGFydCBieSB0aGFua2luZyB5b3UgZm9yIHB1dHRpbmcgdGhvdWdodCBhbmQgdGltZSBp bnRvIHRoZQ0Kcm91dGUgbGVhayBwcm9ibGVtIHNwYWNlLiBJdCBpcyBlbmNvdXJpbmcgdG8gc2Vl IGZlbGxvdyBvcGVyYXRvcnMgZW5nYWdlDQp3aXRoIHRoZSBJRVRGIGNvbW11bml0eSB0byBhZGRy ZXNzIGFjdHVhbCwgZGF5IHRvIGRheSBpc3N1ZXMuDQoNCk9uIE1vbiwgSnVuIDA2LCAyMDE2IGF0 IDEyOjQwOjE5UE0gLTA0MDAsIFN1c2FuIEhhcmVzIHdyb3RlOg0KPiBUaGlzIGJlZ2lucyBhIDIg d2VlayBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC15bWJrLWlkci1iZ3Atb3Blbi1wb2xpY3ku DQo+IFlvdSBjYW4gZmluZCB0aGUgZHJhZnQgYXQ6DQo+DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXltYmstaWRyLWJncC1vcGVuLXBvbGljeS8uDQo+DQo+IEluIHlv dXIgY29tbWVudHMgb24gYWRvcHRpbmcgdGhpcyBkcmFmdCwgcGxlYXNlIGluZGljYXRlOg0KPg0K PiAxKSAgICAgICJTdXBwb3J0IiBvciAibm8gU3VwcG9ydCINCg0KTm8gc3VwcG9ydC4NCg0KPiAy KSAgICAgIERvIHlvdSBmZWVsIHRoaXMgaXMgYSB3YXkgdG8gcHJldmVudCByb3V0ZSBsZWFrcz8N Cg0KSXQgY2VydGFpbmx5IGlzIGEgd2F5Lg0KDQo+IDMpICAgICAgQXJlIHRoZXJlIGFueSBkZXBs b3ltZW50IGlzc3VlcyB0aGF0IG1pZ2h0IHByZXZlbnQgZGVwbG95bWVudA0KPiBvZiB0aGlzIGVu aGFuY2VtZW50IHRvIEJHUCBPcGVuPw0KDQpJIGRvIG5vdCB0aGluayB0aGF0IHRoZSBPUEVOIG1v bWVudCBpbiB0aGUgbGlmZWN5Y2xlIG9mIGEgQkdQIHNlc3Npb24gaXMNCnRoZSBhcHByb3BpYXRl IHBsYWNlIGZvciBwb2xpY3kgY29uc3RydWN0cyBsaWtlIHRoaXMuIEluIHByYWN0aXNlIGl0IGlz DQpwcm9iYWJseSBub3QgYW4gaXNzdWUgd2hlbiB5b3UgaGF2ZSB0byBmbGFwIGEgQkdQIHNlc3Np b24gdG8gY2hhbmdlIHRoZQ0KcmVsYXRpb24gYmV0d2VlbiB0d28gQVNOcywgYnV0IGl0IHdvdWxk IGJlIG5pY2UgaWYgdGhpcyBpcyBub3QgcmVxdWlyZWQNCihsaWtlIHRvZGF5IG9uIG1vc3QgcGxh dGZvcm1zKS4NCg0KU2Vjb25kbHkgKGFuZCBtb3JlIGltcG9ydGFudGx5KSwgdGhlIHJvbGVzIGFy ZSBub3QgbmVjZXNzYXJpbHkgYSBCR1ANCnNlc3Npb24tc3BlY2lmaWMgY2hhcmFjdGVyaXN0aWMs IGJ1dCByYXRoZXIgYSBwcmVmaXgtc3BlY2lmaWMgcHJvcGVydHkuDQpUaGUgcHJvcG9zZWQgT1BF TiBtZXRob2QgZG9lcyBub3QgcHJvdmlkZSBmb3IgdGhpcyBsZXZlbCBncmFudWxhcml0eSBpZg0K SSBhbSByZWFkaW5nIGl0IGNvcnJlY3RseS4gVGhlIG1ldGhvZCB3b3VsZCBhZmZlY3QgYWxsIHBy ZWZpeGVzIGV4Y2hhbmdlDQpvdmVyIGEgQkdQIHNlc3Npb24sIHdpdGhvdXQgZXhjZXB0aW9uLg0K DQo+IDQpIERvZXMgdGhpcyBpbnRlcmFjdCB3aXRoDQo+IGRyYWZ0LWlldGYtaWRyLXJvdXRlLWxl YWstZGV0ZWN0aW9uLW1pdGlnYXRpb24/DQoNClllcywgaW4gdGVybXMgb2YgdGhlIHByb2JsZW0g YmVpbmcgYWRkcmVzc2VkLg0KDQpLaW5kIHJlZ2FyZHMsDQoNCkpvYg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRy QGlldGYub3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcg0KDQoNCg0KLS0NCnwgQWxleGFuZGVyIEF6aW1vdiAgfCBITEwgbCBR UkFUT1INCnwgdGVsLjogKzcgNDk5IDI0MSA4MSA5Mg0KfCBtb2IuOiArNyA5MTUgMzYwIDA4IDg2 DQp8IHNreXBlOiBtaXRyYWRpcg0KfCBtYWlsdG86IGFhQHFyYXRvci5uZXQ8bWFpbHRvOmFhQHFy YXRvci5uZXQ+DQp8IHZpc2l0OiB3d3cucXJhdG9yLm5ldDxodHRwOi8vd3d3LnFyYXRvci5uZXQv Pg0K --_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEF772USIDCWVEMBX03co_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDoxOTM1MDQzMTMzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDYxNDc4ODYw O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IGxpa2UgIzIuJm5ic3A7IEl0IGRv ZXNu4oCZdCBtYWtlIHNlbnNlIHRvIG1lIOKAkyBhIHNpbmdsZSBuZWlnaGJvciBtYXkgaGF2ZSBz b21lIGN1c3RvbWVyIGFzcGVjdHMgYW5kIHNvbWUgcGVlciBhc3BlY3RzLCBhbmQgc3BsaXR0aW5n IGEgc2luZ2xlIEJHUCBzZXNzaW9uIGludG8NCiB0d28gaXMgY29uY2VwdHVhbGx5IHdlaXJkIGFu ZCBhbHNvIGEgaHVnZSBjb2RlIHVwbGlmdCBvbiBib3RoIGVuZHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4jMSBtYWtlcyBzZW5zZSBhbmQgaXMgYWxvbmcgdGhl IGxpbmVzIG9mIHdoYXQgSSB3YXMgaGludGluZyBhdCBpbiBteSDigJhzdXBwb3J04oCZIOKAkyBk b27igJl0IGp1c3QgZ2l2ZSBtZSBwYXNzL2ZhaWwsIGdpdmUgbWUgZmxleGlibGUga25vYnMgaW4g YW4gaW1wbGVtZW50YXRpb24uJm5ic3A7IEkNCiByZWFsaXplIHRoYXQgZG9pbmcgdGhpcyBwZXIt cHJlZml4IGlzIGFub3RoZXQgd2F5IHRvIGRvIGl0LCBidXQgc2VlIG15IG90aGVyIGVtYWlsIHRv IFNyaXJhbSBmb3Igd2h5IEkgZG9u4oCZdCBsaWtlIHBhdGggc3RhdGUgbXVjaC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgc3VwcG9zZSBJIGNvdWxkIHNlZSBu b24tdHJhbnNpdGl2ZSBwZXItcHJlZml4IGFzIGFub3RoZXIgd2F5IHRvIGRvIHRoaXM7IGlmIGl0 IHdhcyB0aGF0IHZzIG9wZW4gbWVzc2FnZSwgdGhlcmUgYXJlIGdvb2QgYXJndW1lbnRzIGVpdGhl ciB3YXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5lcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbGV4YW5kZXIgQXppbW92PGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBKdW5lIDA5LCAyMDE2IDE6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IEpvYiBTbmlq ZGVycyAmbHQ7am9iQGluc3RpdHV1dC5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBpZHJAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtaWRyLXJvdXRlLWxlYWstZGV0ZWN0aW9uLW1pdGlnYXRpb25AaWV0Zi5v cmc7IEpvaG4gRy4gU2N1ZGRlciAmbHQ7amdzQGJncC5udSZndDs7IFN1c2FuIEhhcmVzICZsdDtz aGFyZXNAbmR6aC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWRyXSBXRyBBZG9w dGlvbiBjYWxsIGRyYWZ0LXltYmstaWRyLWJncC1vcGVuLXBvbGljeSAtICg2LzYgdG8gNi8yMC8y MDE2KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgSm9iLDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciBq b2luaW5nIGRpc2N1c3Npb24hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNhbid0IGltYWdpbmUgc2l0dWF0aW9uIHdoZW4gdGhl cmUgd291bGQgYmUgY2hhbmdlcyBpbiByb2xlcyBiZXR3ZWVuIHR3byBuZWlnaGJvcnMgb24gcmVn dWxhciBiYXNpcy4gU28sIHdlIHNob3VsZCBub3Qgc3VmZmVyIGZyb20gbG90cyBvZiBCR1AgZmxh cHMgY2F1c2VkIGJ5IHJvbGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHNlY29uZCBwb2ludCB5b3UndmUgaGlnaGxpZ2h0 ZWQgbW9zdCBjb21tb24gY29uY2VybiBhYm91dCBkaWZmZXJlbnQgcHJlZml4LWJhc2VkIHJvdXRl IHBvbGljaWVzIGluIHNhbWUgQkdQIHNlc3Npb24uIFRoZXJlIGFyZSBhdCBsZWFzdCB0d28gd29y a2Fyb3VuZHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0 PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KQWRkICdjdXN0b20nIHJvbGUgYW5kIGdpdmUgaW4gc3VjaCBzZXNzaW9ucyBhY2Nl c3MgdG8gbWFudWFsIE9UQyBjb25maWd1cmF0aW9uICh0aGVyZSB3b3VsZCBiZSBuZXcgYXBwcm9w cmlhdGUgcGFpciBvZiByb2xlcyBjdXN0b20tY3VzdG9tKTxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClNwbGl0IHN1Y2ggQkdQ IHNlc3Npb25zIGludG8gdHdvIHdpdGggZGlmZmVyZW50IHJvbGVzPG86cD48L286cD48L2xpPjwv b2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Rm9yIG15c2VsZiBJIGRvIHByZWZlciBzZWNvbmQgb3B0aW9uIC0gSSB3b3VsZCBsaWtl IHRvIHNlZSByb3V0ZSBsZWFrIG1pdGlnYXRpb24gYXMgYnVpbHQgaW4gYW5kIGZ1bGx5IGF1dG9t YXRlZCBtZWNoYW5pc20sIHdpdGggbm8gb3Bwb3J0dW5pdHkgZm9yICdmYXQgZmluZ2VycycgZ2V0 IGluc2lkZS4gVGhpcyBjb3VsZCBicmluZyBhZGRpdGlvbmFsIHdvcmsgZm9yIE5PQyB0ZWFtcyBp biBzaG9ydCB0ZXJtLA0KIGJ1dCBpbiBsb25nIHRlcm0gYmVuZWZpdCBmcm9tIGNvbnRyb2xsaW5n IG5laWdoYm9yIGNvbmZpZ3VyYXRpb24gKGVzcGVjaWFsbHkgaW4gY2FzZSBvZiBuZXcgSVNQcykg d2lsbCBmdWxseSBjb3ZlciB0aGUgc3BlbnQgdGltZS4gQnV0IHdoYXQgZG8geW91IHRoaW5rIGFj Y29yZGluZyB0byB5b3VyIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2U/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4yMDE2LTA2LTA5IDE5OjMyIEdNVCYjNDM7MDM6MDAgSm9iIFNuaWpkZXJzICZsdDs8YSBo cmVmPSJtYWlsdG86am9iQGluc3RpdHV1dC5uZXQiIHRhcmdldD0iX2JsYW5rIj5qb2JAaW5zdGl0 dXV0Lm5ldDwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRlYXIgQXV0aG9ycywgSURSIGdyb3VwLDxicj4NCjxicj4NCkknZCBsaWtlIHRv IHN0YXJ0IGJ5IHRoYW5raW5nIHlvdSBmb3IgcHV0dGluZyB0aG91Z2h0IGFuZCB0aW1lIGludG8g dGhlPGJyPg0Kcm91dGUgbGVhayBwcm9ibGVtIHNwYWNlLiBJdCBpcyBlbmNvdXJpbmcgdG8gc2Vl IGZlbGxvdyBvcGVyYXRvcnMgZW5nYWdlPGJyPg0Kd2l0aCB0aGUgSUVURiBjb21tdW5pdHkgdG8g YWRkcmVzcyBhY3R1YWwsIGRheSB0byBkYXkgaXNzdWVzLjxicj4NCjxicj4NCk9uIE1vbiwgSnVu IDA2LCAyMDE2IGF0IDEyOjQwOjE5UE0gLTA0MDAsIFN1c2FuIEhhcmVzIHdyb3RlOjxicj4NCiZn dDsgVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQteW1iay1p ZHItYmdwLW9wZW4tcG9saWN5Ljxicj4NCiZndDsgWW91IGNhbiBmaW5kIHRoZSBkcmFmdCBhdDo8 YnI+DQomZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC15bWJrLWlkci1iZ3Atb3Blbi1wb2xpY3kvIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15bWJrLWlkci1iZ3Atb3Blbi1w b2xpY3kvPC9hPi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiB5b3VyIGNvbW1lbnRzIG9uIGFkb3B0 aW5nIHRoaXMgZHJhZnQsIHBsZWFzZSBpbmRpY2F0ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAxKSZu YnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O1N1cHBvcnQmcXVvdDsgb3IgJnF1b3Q7bm8gU3VwcG9y dCZxdW90Ozxicj4NCjxicj4NCk5vIHN1cHBvcnQuPGJyPg0KPGJyPg0KJmd0OyAyKSZuYnNwOyAm bmJzcDsgJm5ic3A7IERvIHlvdSBmZWVsIHRoaXMgaXMgYSB3YXkgdG8gcHJldmVudCByb3V0ZSBs ZWFrcz88YnI+DQo8YnI+DQpJdCBjZXJ0YWlubHkgaXMgYSB3YXkuPGJyPg0KPGJyPg0KJmd0OyAz KSZuYnNwOyAmbmJzcDsgJm5ic3A7IEFyZSB0aGVyZSBhbnkgZGVwbG95bWVudCBpc3N1ZXMgdGhh dCBtaWdodCBwcmV2ZW50IGRlcGxveW1lbnQ8YnI+DQomZ3Q7IG9mIHRoaXMgZW5oYW5jZW1lbnQg dG8gQkdQIE9wZW4/PGJyPg0KPGJyPg0KSSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgT1BFTiBtb21l bnQgaW4gdGhlIGxpZmVjeWNsZSBvZiBhIEJHUCBzZXNzaW9uIGlzPGJyPg0KdGhlIGFwcHJvcGlh dGUgcGxhY2UgZm9yIHBvbGljeSBjb25zdHJ1Y3RzIGxpa2UgdGhpcy4gSW4gcHJhY3Rpc2UgaXQg aXM8YnI+DQpwcm9iYWJseSBub3QgYW4gaXNzdWUgd2hlbiB5b3UgaGF2ZSB0byBmbGFwIGEgQkdQ IHNlc3Npb24gdG8gY2hhbmdlIHRoZTxicj4NCnJlbGF0aW9uIGJldHdlZW4gdHdvIEFTTnMsIGJ1 dCBpdCB3b3VsZCBiZSBuaWNlIGlmIHRoaXMgaXMgbm90IHJlcXVpcmVkPGJyPg0KKGxpa2UgdG9k YXkgb24gbW9zdCBwbGF0Zm9ybXMpLjxicj4NCjxicj4NClNlY29uZGx5IChhbmQgbW9yZSBpbXBv cnRhbnRseSksIHRoZSByb2xlcyBhcmUgbm90IG5lY2Vzc2FyaWx5IGEgQkdQPGJyPg0Kc2Vzc2lv bi1zcGVjaWZpYyBjaGFyYWN0ZXJpc3RpYywgYnV0IHJhdGhlciBhIHByZWZpeC1zcGVjaWZpYyBw cm9wZXJ0eS48YnI+DQpUaGUgcHJvcG9zZWQgT1BFTiBtZXRob2QgZG9lcyBub3QgcHJvdmlkZSBm b3IgdGhpcyBsZXZlbCBncmFudWxhcml0eSBpZjxicj4NCkkgYW0gcmVhZGluZyBpdCBjb3JyZWN0 bHkuIFRoZSBtZXRob2Qgd291bGQgYWZmZWN0IGFsbCBwcmVmaXhlcyBleGNoYW5nZTxicj4NCm92 ZXIgYSBCR1Agc2Vzc2lvbiwgd2l0aG91dCBleGNlcHRpb24uPGJyPg0KPGJyPg0KJmd0OyA0KSBE b2VzIHRoaXMgaW50ZXJhY3Qgd2l0aDxicj4NCiZndDsgZHJhZnQtaWV0Zi1pZHItcm91dGUtbGVh ay1kZXRlY3Rpb24tbWl0aWdhdGlvbj88YnI+DQo8YnI+DQpZZXMsIGluIHRlcm1zIG9mIHRoZSBw cm9ibGVtIGJlaW5nIGFkZHJlc3NlZC48YnI+DQo8YnI+DQpLaW5kIHJlZ2FyZHMsPGJyPg0KPGJy Pg0KSm9iPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KSWRyIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZHJAaWV0Zi5vcmciPklk ckBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWRyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJh bGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojOTk5OTk5Ij58IEFsZXhhbmRlciBBemltb3YgJm5ic3A7fCBITEwg bCBRUkFUT1I8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojOTk5OTk5Ij58IHRlbC46ICYjNDM7NyA0OTkgMjQxIDgxIDkyPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5OTk5OSI+fCBtb2IuOiAmIzQzOzcg OTE1IDM2MCAwOCA4Njwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM5OTk5OTkiPnwgc2t5cGU6IG1pdHJhZGlyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5OTk5OSI+fCBtYWlsdG86Jm5ic3A7PGEgaHJl Zj0ibWFpbHRvOmFhQHFyYXRvci5uZXQiIHRhcmdldD0iX2JsYW5rIj5hYUBxcmF0b3IubmV0PC9h Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTk5 OTkiPnwgdmlzaXQ6Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5xcmF0b3IubmV0LyIgdGFyZ2V0 PSJfYmxhbmsiPnd3dy5xcmF0b3IubmV0PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEF772USIDCWVEMBX03co_-- From nobody Thu Jun 9 12:37:19 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F2712D97F; Thu, 9 Jun 2016 12:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10t7U-Ql3on9; Thu, 9 Jun 2016 12:37:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D41812D979; Thu, 9 Jun 2016 12:37:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bB5lP-000208-NA; Thu, 09 Jun 2016 19:37:11 +0000 Date: Thu, 09 Jun 2016 12:37:10 -0700 Message-ID: From: Randy Bush To: Job Snijders In-Reply-To: <20160609163225.GC2524@Vurt.local> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160609163225.GC2524@Vurt.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 19:37:18 -0000 > Secondly (and more importantly), the roles are not necessarily a BGP > session-specific characteristic, but rather a prefix-specific > property. The proposed OPEN method does not provide for this level > granularity if I am reading it correctly. The method would affect all > prefixes exchange over a BGP session, without exception. i can not be sure, as you lack example. but the example i commonly use is when A gives B local peering and also sells B global transit. today, this is two separate sessions. do you use another approach; not can think of, but actualy use? are there other real-world examples? just trying to understand. randy From nobody Thu Jun 9 12:47:11 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE4B12D990; Thu, 9 Jun 2016 12:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIAMe9b4lTeF; Thu, 9 Jun 2016 12:47:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682BE12D98D; Thu, 9 Jun 2016 12:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2507; q=dns/txt; s=iport; t=1465501628; x=1466711228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CdxKWVCspy0NTuPAUD+daHibMrXTIrNa1l05PfQ0MRk=; b=IUcsGYBFBOXd02VfpGn/1KFN0lwleqOk53tsymm2xmCZCUkb0ahyWsCU 9fpK4/6JLhAgKiIue034vEe+u1pCU39Zk/nHOZbqlW9hVijNU7ZZVUi3m LZ1hnPhp7EYiknAymnPoW4jehNNHwel150SFrcSn8/YhqTcNjKAWiyjw0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQDUxllX/5ldJa1egz5WfQa7FIF6I?= =?us-ascii?q?oVxAoE7OBQBAQEBAQEBZSeERQEBAQMBHVUHBQsCAQgYLjIlAgQBDQUUB4gMCA6?= =?us-ascii?q?+TgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhieETYoaBY4iijMBhgKIJIFphFKIZ?= =?us-ascii?q?Y9kAR42g25uiQl/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,446,1459814400"; d="scan'208";a="111650148" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2016 19:47:07 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u59Jl7dS013751 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Jun 2016 19:47:07 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 9 Jun 2016 15:47:06 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Thu, 9 Jun 2016 15:47:06 -0400 From: "Keyur Patel (keyupate)" To: Job Snijders , Susan Hares Thread-Topic: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) Thread-Index: AQHRwoe0lG6JtkCcFUCp0q4CdI2NOg== Date: Thu, 9 Jun 2016 19:47:06 +0000 Message-ID: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160609163225.GC2524@Vurt.local> In-Reply-To: <20160609163225.GC2524@Vurt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.161.235] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 19:47:10 -0000 Hi Folks, Comments inlined #Keyur On 6/9/16, 9:32 AM, "Job Snijders" wrote: >Dear Authors, IDR group, > >I'd like to start by thanking you for putting thought and time into the >route leak problem space. It is encouring to see fellow operators engage >with the IETF community to address actual, day to day issues. > >On Mon, Jun 06, 2016 at 12:40:19PM -0400, Susan Hares wrote: >> This begins a 2 week WG Adoption call for >>draft-ymbk-idr-bgp-open-policy. >> You can find the draft at: >>=20 >> https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/. >>=20 >> In your comments on adopting this draft, please indicate: >>=20 >> 1) "Support" or "no Support" > >No support. > >> 2) Do you feel this is a way to prevent route leaks? > >It certainly is a way. #Keyur: I am not sure if the solution attempts to cover all cases: Open policy assumes certain peering relationship can be established between BGP speakers and based on the relationship, the OTC handling is done. This information is restricted and doesn=B9t flow along the path the route is announced. You do want to carry this information so any AS down the path can make an independent decision? > >> 3) Are there any deployment issues that might prevent deployment >> of this enhancement to BGP Open? > >I do not think that the OPEN moment in the lifecycle of a BGP session is >the appropiate place for policy constructs like this. #Keyur: +1. I completely agree. Furthermore, the draft isn=B9t clear about changing of session level roles (either using dynamic capabilities or upon a session restart) and its impact on depref/dropped routes and existing functionality like GR (route based). > In practise it is >probably not an issue when you have to flap a BGP session to change the >relation between two ASNs, but it would be nice if this is not required >(like today on most platforms). > >Secondly (and more importantly), the roles are not necessarily a BGP >session-specific characteristic, but rather a prefix-specific property. >The proposed OPEN method does not provide for this level granularity if >I am reading it correctly. The method would affect all prefixes exchange >over a BGP session, without exception. #Keyur: Ack and agree. Regards, Keyur > >> 4) Does this interact with >> draft-ietf-idr-route-leak-detection-mitigation? > >Yes, in terms of the problem being addressed. > >Kind regards, > >Job From nobody Thu Jun 9 13:09:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7059812D9C0; Thu, 9 Jun 2016 13:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B3auMOs5sbq; Thu, 9 Jun 2016 13:09:56 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B159012D734; Thu, 9 Jun 2016 13:09:55 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id k204so75167156wmk.0; Thu, 09 Jun 2016 13:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hK8t3MxIj2/4I8Na5CE3UlxKlGnH50+WrCTyljdkNTE=; b=CvlgGpE5TT/mF+l9tAn21TfgWzo0pOkgkyMII0q2rPlYhjy1B+iz7gjZuqQ0bQTxen uFHK37/vGmvwQqwBzlZRSa9bQ2fIs7RDsw/LCqSViE7GH7BBPB9AZky2EPLbyE68NBAX 23sJ4vWBd3uyWo9rSz5JT+QeRU91Y4FnSo4fxsAzZSpz0h2eyqMSmffqFwK04okFKJYT M9Lpn4n2Gx5TDEZaUIHXrog+Rsn0eZtD76gPLwAVTyPHalaw9IDdYz6I/HN9X6yjEMrc Y3DfaCunIqzI9inuga4xlArs8RhRk/qAT2sGyXlCTWPYkx8Phn6W6B7tF5rZwr3kunbR 9PvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hK8t3MxIj2/4I8Na5CE3UlxKlGnH50+WrCTyljdkNTE=; b=EK6fHXDGIjepvaXyHLbqZE9UZ7Zk6UXaVhTWLZbiGHaUSJw27TeXtAegdWnyS9mtvf aMPrhSl/MmCO4H352CFjkNJYDWIAJ+z4GQiRnCj731KpJRZ2nrikvsMJqcYWoQUNj97m cVtSDCS0eulfNOg44Q9MnQH3Jtw36WQx2fkctlDmmLGlcnwgHjx9rlYaa54eVTQyfQ8h qNySK0As81JoPtfLUgAXTV5wbCBqHi9hlrdcGb/vQu5T91vYdX1xxOaD9KQGCgNqQoMK JzbpEivyfkxS/aRAuKwGpHeeRM18gc+pGf3e7BK+6yiO/99MQyLG0uGbCM0+I81oL7dr z0sg== X-Gm-Message-State: ALyK8tI4RU45YqvEHK8jhEwj/7vW9AXPlVNk3kj9yxNfunZRJgHIl5pr+fegF0rcKaHQAzcpAquJcB9k6o71Cw== X-Received: by 10.194.25.135 with SMTP id c7mr3805452wjg.63.1465502994284; Thu, 09 Jun 2016 13:09:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.127.195 with HTTP; Thu, 9 Jun 2016 13:09:53 -0700 (PDT) In-Reply-To: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160609163225.GC2524@Vurt.local> From: Brian Dickson Date: Thu, 9 Jun 2016 13:09:53 -0700 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=047d7b2e11296448f30534de0109 Archived-At: Cc: IETF IDR , draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "John G. Scudder" , Susan Hares Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 20:09:57 -0000 --047d7b2e11296448f30534de0109 Content-Type: text/plain; charset=UTF-8 I am not 100% certain, and don't speak for them, but I believe Hurricane Electric (HE) often has peers who use them for both IPv4 peering and IPv6 transit; I don't know, but would guess that at least some of those are over a single MP-BGP session. Brian On Thu, Jun 9, 2016 at 12:37 PM, Randy Bush wrote: > > Secondly (and more importantly), the roles are not necessarily a BGP > > session-specific characteristic, but rather a prefix-specific > > property. The proposed OPEN method does not provide for this level > > granularity if I am reading it correctly. The method would affect all > > prefixes exchange over a BGP session, without exception. > > i can not be sure, as you lack example. but the example i commonly use > is when A gives B local peering and also sells B global transit. today, > this is two separate sessions. do you use another approach; not can > think of, but actualy use? > > are there other real-world examples? just trying to understand. > > randy > --047d7b2e11296448f30534de0109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not 100% certain, and don't speak for them, but I= believe Hurricane Electric (HE) often has peers who use them for both IPv4= peering and IPv6 transit; I don't know, but would guess that at least = some of those are over a single MP-BGP session.

Brian

On Thu, = Jun 9, 2016 at 12:37 PM, Randy Bush <randy@psg.com> wrote:
> Secondly (and more impor= tantly), the roles are not necessarily a BGP
> session-specific characteristic, but rather a prefix-specific
> property.=C2=A0 The proposed OPEN method does not provide for this lev= el
> granularity if I am reading it correctly. The method would affect all<= br> > prefixes exchange over a BGP session, without exception.

i can not be sure, as you lack example.=C2=A0 but the example i comm= only use
is when A gives B local peering and also sells B global transit.=C2=A0 toda= y,
this is two separate sessions.=C2=A0 do you use another approach; not can think of, but actualy use?

are there other real-world examples?=C2=A0 just trying to understand.

randy

--047d7b2e11296448f30534de0109-- From nobody Thu Jun 9 16:43:38 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CD612D7E8; Thu, 9 Jun 2016 16:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bp5Zg8239J7; Thu, 9 Jun 2016 16:43:32 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB0112B057; Thu, 9 Jun 2016 16:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=93783; q=dns/txt; s=iport; t=1465515811; x=1466725411; h=from:to:cc:subject:date:message-id:mime-version; bh=wvxhQi3pSLWW39ditma4kPI7aPFx7C5clEl5NYpKOk0=; b=XaWWm+o5q1Ed2abKWX8sfFslaf43lOaSEMTSTmMOzgjTk8BWg5Dn9Sv0 zFIayBKQEoM0ObiBwHxMLbdE/HxI6tqoXeGFz1G8bs2hTp72ZPgu36GP3 FtgPCK3n0s4OYuZZusrjq6YZx4dXWGaIWCRxzh0BYOmh3MKRGEzHQam2f E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgBQDs/VlX/5FdJa1TAQmCcE5WfQa7F?= =?us-ascii?q?oF6JIVvgTo5EwEBAQEBAQFlHAuETBoBTAQHBxIBNQsBPycEDgMdiBQOA75DAQE?= =?us-ascii?q?BAQEBAQMBAQEBAQEBAQEZBYYniGUBZoUbBY1qhVKFGQGGAoJ4hSyBaYRSiGWGQ?= =?us-ascii?q?IkkASABM4IEAxyBSz8vAYhFKxh/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,447,1459814400"; d="scan'208,217";a="111717769" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2016 23:43:29 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u59NhTe5003334 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Jun 2016 23:43:29 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 9 Jun 2016 18:43:28 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Thu, 9 Jun 2016 18:43:28 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-idr-sla-exchange@ietf.org" Thread-Topic: AD Review of draft-ietf-idr-sla-exchange-08 Thread-Index: AQHRwqi5NZ7Eq+drE06N6iB8qKo/Lg== Date: Thu, 9 Jun 2016 23:43:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_D343FE1E121ABDaretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , Susan Hares , "idr@ietf.org" Subject: [Idr] AD Review of draft-ietf-idr-sla-exchange-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 23:43:37 -0000 --_000_D343FE1E121ABDaretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear authors: I just finished reading this document. I have significant concerns with the content (see my detailed comments belo= w), and with the fact that the we're producing this document on SLAs in a r= outing WG. It is "ok" [*] to carry information in BGP that is not related = to routing, but in this draft we're really defining how to represent an SLA= . The only BGP-specific work is related to propagating a new transitive at= tribute =97 we don't need 30 pages for that!! Many of my comments are keyed off these statements in the Introduction: "Th= e Inter-domain exchange of QoS SLA exchange policy described in this docume= nt=85only requires that the provider wishes to send the QoS SLA policy via = BGP=85to a set of receivers=85The SLA negotiation and assurance is outside = the scope of this document." My interpretation is that BGP is then used a= s a simple transport for the SLA information and that it can't (and shouldn= 't!) concern itself with the interpretation, validation or enforcement of t= he information it is transporting. Given that, I want to first mention 3 overarching themes that I want to see= addressed (I also tried to indicate which theme the comments below relate = to): T1. The SLA Definition. As mentioned above, it concerns me that this WG ha= s taken on the task of defining the description of an SLA. At a minimum, t= his document should have been discussed in the TSV and OPS areas, for both = sanity checking and coordination. I found in the archive some exchanges wi= th tsvwg (from 2013, when the =9601 version was published) -- in the thread= , the tsvwg Chair mentions the need for coordination as they have related w= ork. However, the communication abruptly ends [1] -- note that the last re= commendation from tsvwg was against having multiple drop thresholds in DROP= _THRESHOLD (Section 3.3.2.8), but the current version still hast that =97 i= t does seem like the conversation was concluded=85 Please seek out review= from both tsvwg and opsawg (or at least the OPS-Dir). T2. Who does what? (aka which functionality belongs in BGP?) I then see the document as containing two distinct sets of specifications: = (1) how does BGP transport some information in a transitive attribute (incl= uding how a BGP speaker validates the formatting), and (2) how the user of = the SLA information (which is not the BGP speaker itself, but some other co= nsumer) should deal with it. I would really like to see a clear definition= of who (the BGP Speaker or something else) is executing the action =97 kee= ping into account that it is out of scope what exactly is done with the inf= ormation. I would like to propose a simple framework/terminology for the process, whi= ch I think is something like this: A. the SLA_Provider (which represents whoever/whatever comes up with the SL= A definition) gives the formatted information to BGP for it to transport (a= ssociated with a prefix, destined to a list of ASNs, etc.); B. BGP puts the formatted information in the QoS attribute and advertises i= t in an UPDATE; C. the BGP receiver verifies that the UPDATE is formatted correctly (includ= ing the QoS Attribute); D. a SLA_Consumer (which represents a local process that will make sense of= the content and maybe even do something with it) further verifies that the= content makes sense, keeps track of the SLA ID, etc.. Right now, the document doesn't clearly assign roles and it seems like ever= ything is done by the BGP speaker, where conceptually it isn't because BGP = is a routing protocol and not an SLA_Producer or SLA_Consumer. For example= (there are more cases below), Section 5.2. (SLA Attribute Handling at Rece= iver) says that "the receiving BGP peer SHOULD invalidate previous advertis= ed SLA parameters if one exists for the same SLA id and source AS." Follow= ing the conceptual model above, this action would be done by the SLA_Consum= er, who may care about the content itself. If you don't want to use the simple framework above and want to use other n= ames, that is perfectly fine. I just want the document to clearly reflect = what is done by BGP and what is done by someone else. T3. Clarity and Consistency=85 I am very disappointed in the fact that the= SLA itself is underspecified, that there isn't consistency on the names us= ed (even within the definition of the fields!) and that some sections seem = to be left to the readers' interpretation (guessing!). Examples include si= mple things such as the units in which the length is indicated, and using c= onsistent names. Those may be easy to correct, but a Standards Track docum= ent should not be in this state at this point in the process. There are ma= ny more examples below. I'm returning the document to the WG for further processing. I expect that= proper coordination and review with TSV and OPS, including a new WGLC with= the appropriate WGs in cc (tsvwg, for example), takes place before returni= ng to the IESG. I recommend that other comments be addressed before embark= ing in reviews beyond idr. Thanks! Alvaro. [*] Given the fact that we already throw all kinds of stuff on top of BGP= =85 :-( [1] https://mailarchive.ietf.org/arch/msg/tsvwg/IjVdEF7KZyz0czm4YBXEr7KjmkU Major: M1. [T1] [T2] Introduction: "The Inter-domain exchange of QoS SLA exchange = policy described in this document does not require any specific method for = the provider in establishing SLAs. It only requires that the provider wish= es to send the QoS SLA policy via BGP UPDATE [RFC4271] messages from the pr= ovider to a set of receivers (BGP peers) who will enact the policy. In rea= ction to, a receiving router may translate that to relevant QoS policy defi= nition on the device=85 The SLA negotiation and assurance is outside the s= cope of this document." M1.1. [T2] If I interpret this text correctly, the intent of this document = is to propagate the new attribute (with SLA information in it), but it take= s no position as to what the receivers do with the information. Is that co= rrect? M1.2 [T2] If so, then the "enact the policy" part above is out of place bec= ause there's no assumption as to what will happen with the information. M2. [T3] Section 3.1. (SLA, QoS attribute sub-type, Definition) SubType = range is not defined correctly: s/0x0f/0xff What is the SubType length = expressed in, octets? M3. [T3] Section 3.2. (SLA SubType Value Field) M3.1 "Source AS=85Note that AS =3D 0, used in message outside of QoS attrib= ute, is illegal in normal BGP operations. AS =3D 0 inside the QoS attribut= e may be used simply as a flag=85" M3.1.1 [minor] Please put a reference to rfc7607. M3.1.2 Given that this document specifies a new valid use of AS 0, I think = it should be marked as Updating rfc7607. M3.1.3 What is the purpose of this field? Section 4. (Originating SLA Noti= fication) does say that the "QoS attribute MUST only be added by the origin= ator=85", but it seems easy to forge the value here. M3.2 For the "Destination AS list" field description, it should be clearly = specified the contents if the "Destination AS count" is 0. Also, please be= specific and clear (word are free!), for example: "List of ASNs for which = the SLA is relevant, each of which is a 32-bit number [rfcREFERENCE]. If t= he Destination AS count is set to 0, then this field SHOULD NOT (?) be incl= uded in this sub-TLV=85." M3.3 "SLA Event": the field in Figure 3 is simply called "Event". Please b= e consistent: either call both the same way or clarify which field is being= referenced. I know it may be obvious, but it doesn't make for a crisp spe= cification =97 other parts of the text simply use "event" as well. Please = be specific and clear as to what this field indicates. M3.4 SLA Id M3.4.1 "A 16-bit field containing identifier which is unique in scope of so= urce AS" What happens if the Source AS is set to 0? M3.4.2 [minor] "The SLA ID applies aggregate for all the traffic=85" I'm = guessing you meant to talk about the "aggregate traffic"=85?? M3.4.3 "The SLA identifier is not globally unique but it MUST be unique wit= hin the source AS (advertiser)." What happens if the Source AS field is se= t to 0? The text in the Source AS field description says that when the val= ue is 0 then "ignore Source=85". What does this do to the content of the S= LA ID. M3.4.4 [minor] BTW, please be consistent: SLA ID, SLA id, SLA Id, SLA iden= tifier, etc M3.5 What is the "SLA Length" field expressed in? M3.6 SLA-Content per SLA Event M3.6.1 The name seems to hint at the fact that the content is "per Event", = but it is not described anywhere how multiple events would be encoded, or i= f even possible (see my comment above about the Event field). M3.6.2 Is the name of this field "SLA-Content per SLA Event" or "SLA-Conten= t"? Please be consistent. M3.6.3 "If the SLA-Content field does not exist=85then receiver MUST inheri= t the previously advertised SLA content for the same SLA id from the same S= ource AS." The next two paragraphs try to cover for the fact that the ord= er cannot be guaranteed (specially more than one AS hop away). But this al= l means that there is a significant possibility that a number of UPDATES wi= ll not have any SLA information at all. Then what is the point? When woul= d you want to take advantage of this feature? M4 [T3] Section 3.3. (SLA-Content per Event Field) M4.1 [nit] s/=85and then optionally followed by for the opposite direction/= =85and then optionally followed by the specification for the opposite direc= tion M4.2 [nit] The format of the field starts with the "dir" field =97 is the f= ollowing text really necessary: "This list of Traffic Classes MUST be speci= fied for one direction first=85" It seems obvious to me. M4.3 "dir=85indicates Direction of the SLA." I'm guessing direction from t= he senders point of view, is that correct? Please be specific. M4.4 "Traffic Class (Classifier Group) count=85value of zero (0x00)=85inval= idates previous advertised SLA=85" In this case, I'm assuming that all the= other fields are not needed, is that correct? If so, then they are option= al and should be described that way. M4.5 "Class Descr Len=85length of the Traffic Class Description field" Le= ngth in what units? M4.6 [minor] "Traffic Class Description" A reference for UTF-8 (rfc3629 I = believe) would be nice. M4.7 "Elements (Classifier) Count=85value zero (0x00) means=85traffic class= is to classify rest of the traffic not captured otherwise by other traffic= classes=85RECOMMENDED that Traffic Class that has 0 elements is present la= st=85If an advertised message has it positioned somewhere else, then the re= ceiver MUST re-order it=85" This text (as is) implies that the 0x00 class= ifier SHOULD be present last =97 is that what you meant, for it to always b= e present? If so, why not use MUST and eliminate the reordering logic? Or= was the intent that if present then it should go last? M4.8 Classifier Element TLVs: M4.8.1 The description talks about "Classifier Element TLVs", but Figure 4 = calls them "Traffic Class Elements (TLVs)". Please be consistent. M4.8.2 "Size of Value field=85length of the value field." Length in octet= s, bytes, bits, ??? M4.8.3 [T2] "Value=85It is an error if the IPFix field does not contain the= appropriate format" This statement gets into interpretation of the conten= ts of the attribute. If the purpose of this document is to just transport = information, then why would it be a function of BGP to figure out if the co= ntents are correct? Please be clear about whether the BGP Speaker or SLA_C= onsumer should perform a function. M4.8.4 "If a receiver receives a BGP UPDATE message with QoS/SLA attribute = for an NLRI that it does not support then the receiver MUST NOT install tha= t advertised SLA and continue to forward this attribute as an optional tran= sitive attribute." What does "an NLRI that it does not support" mean? Are= you talking about an NLRI from a specific unsupported AFI/SAFI, or ?? M4.9 Traffic Class Service TLVs: M4.9.1 The units for the length are (again!) not specified. I realize that= it may be in bits (given the next couple of paragraphs), but the reader sh= ouldn't have to guess. M4.9.2 As long as you're thinking about the length, please check all the le= ngth descriptions =97 I think most of them are missing the units, but this = is getting tedious=85 M4.9.3 Please note that the length of the value fields is not described con= sistently. For example, it says that TRAFFIC_CLASS_TSPEC is 96 bits, but 3= .3.2.3 talks about octets for MINRATE_IN_PROFILE_MARKING. M4.9.4 "Value=85It is an error if this field does not contain the appropria= te format (see BGP error handling section=85." Not only is this error app= ropriate for the SLA_Consumer, but the "appropriate format" is not clearly = identified in the description of all the TLVs. M5 [T1] Section 3.3.1. (Supported IPFIX values for Classifier Elements) M5.1 [minor] The correct link to the IPFIX Registry is https://www.ietf.org= /assignments/ipfix/ipfix.xml#ipfix-information-elements M5.2 "Only the IPFIX attributes listed in Table 1 are supported by BGP SLA = exchange." Why? If this document is just about carrying a new attribute t= hat is opaque to BGP itself and that may or may not result in an action at = the receiver (see above), then why not support any IPFIX element? Maybe no= t all of the elements make sense, but some surely seem to =97 ipClassOfServ= ice, for example. M5.3 "Any new attribute to be supported by SLA QOS MUST be added by a Stand= ards Action." To be added where? The IPFIX registry has a different regis= tration procedure (Expert Review) -- are you referring to adding elements t= here? Or adding elements (already in the IPFIX registry) to Table 1? Or ?= ? M6 [T1] [T3] Section 3.3.2.1. (Traffic Class TSPEC TLV) The value of this T= LV "consists of the (r), (b), (p) parameters as described in Invocation Inf= ormation section of [RFC2212]=85". However, the definition in the document= is not the same as the one in rfc2212. For example, this document defined= r as "measured in octets of Layer 2 (L2) datagrams per second", while rfc2= 212 says that it is "measured in bytes of IP datagrams per second". If the= intent is to (as stated in the document) use the definitions from rfc2212,= then don't redefine the terms. M7 [T1] [T2] [T3] Section 3.3.2.2. (Traffic Class L2 Overhead): M7.1 [T3] Section 3.3.2.2. (Traffic Class L2 Overhead) How is the L2 overh= ead defined? M7.2 [T1] [T2] "When the receiver chooses to react to an advertised SLA and= if the L2 Overhead service type is present in advertised SLA, the receiver= MUST use the explicit advertised L2 overhead rather than the local L2 over= head." In the context of this document, where the use of the SLA is out of= scope, what does "react to an SLA" mean? IOW, we can't mandate what the= receiver does, or how it does it if outside the scope. M7.3 [T1] "If SLA is required to consider only IP packet size, the sender M= AY advertise this service with a value of 0." Again, the reason is out of = scope. The ability to advertise a value of 0 is not. M8. [T1] Section 3.3.2.7. (Precedence between MINRATE and MAXRATE) Back to= the data being opaque..why is this section included in the document? M9. [T3] Section 3.3.2.9. (Traffic Class for Relative Priority) "Length = =3D 4 bits" Unlike all the other length issues I've pointed at, this time = you seem to be indicating the length of the Value field. Does this mean th= at the Length field in they TLV should be set to 4 (as in "the length of th= e Value field in bits"), or that the Length field should not even be presen= t because it is always 4 bits, or something else?? M10 Section 4.1.2. (SLA Advertisement for Destination AS Multiple Hops Away= ) "If a new prefix is added in an AS for which SLA parameters have already = been advertised before for other existing prefixes, and if traffic to this = new prefix is subject to the same SLA advertised earlier, then the BGP UPDA= TE for this new prefix may include QoS attribute containing just an SLA id= =85" M10.1 Is this behavior also valid for directly connected peers? M10.2 The description above assumes that the receiver has the SLA descripti= on from a previous UPDATE. See my comments above about Section 3.2. M11. [T2] Section 5.1. (BGP Node Capable of Processing QoS Attribute) M11.1 Back to the opaqueness of the attribute from the BGP point of view an= d how the use of the information is out of scope. What does "processing" m= ean in this context? I think you will need to separate the processing done= by the BGP Speaker from what the SLA_Consumer should do. M11.2 "If UPDATE has a QoS Attribute with a list of destination ASes, it MA= Y trim the list and adjust the count of the destination AS to exclude ones = that are not required in further announcement of BGP UPDATE messages." Jus= t to make sure I'm looking at this from the right place: this text applies = to a BGP speaker that received the QoS attribute from someone else and is n= ow getting ready to propagate it, right? If so, isn't changing the list of= destination ASes basically an attack on the intent of the origin? M11.3 "BGP peer MUST drop SLA related sub-type from the QoS attribute, if t= here are no more ASes from the QoS Attribute's destination list in the forw= arding path. The rest of the QoS attribute contents MAY be Forwarded=85" M11.3.1 What is the "forwarding path"? I'm guessing that means something l= ike: if the AS is not connected to any other AS on the list (except the one= it just received the UPDATE from)=85 What is it and how can the ingress BG= P speaker in the AS figure it out? M11.3.2 [minor] Please be consistent with the naming. I'm assuming that "S= LA related sub-type" is really the SLA sub-type value 0x01=85 Even though = they are not defined yet, other sub-types may also refer to SLAs. M11.3.3 The "MAY" above is normative in a "forward" manner: affects potenti= al future SubTypes. If new SubTypes are defined later, let them define the= behavior. s/MAY/may M11.3.4 [minor] Note that this whole paragraph is repetitive, please simpli= fy it. M12. [T1] [T2] [T3] Section 5.2. (SLA Attribute Handling at Receiver) M12.1 "Reception of and processing of advertised QoS SLA content are option= al for the receiver." What do you mean that "reception" is optional? What= is "processing"? Given that the use of the SLA is outside the scope, I ca= n only guess that "processing" means at least parsing the contents (not act= ually doing anything with them). If so, what do you mean by saying that "p= rocessing" is optional? In general, if an attribute is sent inside an UPD= ATE it then has to be "received" (unless all the NLRI contents are filtered= by policy) and "processed". This part sounds like it belongs with the SLA= _Consumer. M12.2 "the receiving BGP peer SHOULD invalidate previous advertised SLA par= ameters if one exists for the same SLA id and source AS." I think you real= ly want the SLA_Consumer (not the BGP peer). What does "invalidate" mean i= n this context? Maybe replace or an indication what the new version, etc. M12.3 "If the new advertised SLA has a non-zero traffic count=85" "traffic= count" is not defined anywhere in the document=85 I guess you mean the "T= raffic Class count" -- please be clear and specific. M12.4 "=85then the new advertised SLA SHOULD be installed" Installed? Th= is sounds like you're specifying what to do with the SLA specification=85ou= tside the scope! Even for the SLA_Consumer=85 M12.5 "When BGP UPDATE messages are triggered only as a result of SLA polic= y change=85the receiver MAY implement a policy to filter such messages base= d on the prefix and attribute." I appreciate the intent, but what about ch= anges in other attributes? IOW, the receiver doesn't know that the change = was only due to an SLA policy change (which from the BGP point of view may = be better called something like "an update in the QoS attribute"). Please = clarify that if the filter is put in place, all the other attributes need t= o be checked as well. BTW, I think that the "MAY" should be "may", but tha= t is minor. M12.6 "=85the receiver MAY implement advertised SLA for the whole link=85" = This is an indication of what to do with the SLA=85out of scope! M12.7 "=85QoS attribute with the SLA=85" To be complete, I think you mean = "with the SLA SubType field". M12.8 "=85then receiver may establish advertised SLA for that specific pref= ix list under the relevant link." Even thought not in a normative way, thi= s text also talks about the use of the SLA=85out of scope! M12.9 "It is completely up to the receiver to decide for which prefixes it = should accept advertised SLA and for which ones it will not accept." Which= receiver? I'm guessing the SLA_Consumer, because the BGP speaker has no c= hoice but to accept any attribute=85 Are you implying here that the BGP sp= eaker should be able to selectively filter QoS Attributes? M13. Section 6. (Error Handling) M13.1 [T2] What is an "error condition"? I counted 4 places where an error= was explicitly identified =97 surely there are more cases that would resul= t in an "error condition". I'm assuming that a malformed attribute (as in = the length not matching) is an obvious one (no need to explicitly call that= out, but maybe a reference to the general attribute processing in rfc4271 = would be good)=85but what about if the Source AS is set to 0 and the Destin= ation AS count is not 0, is that an error? M13.2 [T2] OTOH, errors on general attribute format checking (do the length= s/counts match, etc.) is where attribute-discard applies for the BGP Speake= r=85other errors (including some of the ones explicitly identified in the t= ext) may be more in the domain of the SLA_Consumer. Note that even though = the SLA_Consumer may decide to not use the SLA (which is equivalent to attr= ibute discard), I think some of the checking (formatting of the values, for= example) doesn't belong to the BGP Speaker. M13.3 [nit] s/attribute-discard/attribute discard M14. Section 7. (Traffic Class Mapping) What is done with the SLA is out o= f scope! The mapping, or not, of policies is also out of scope =97 special= ly the normative language included in the section. Recommendation: delete = this section completely. M15. Section 11. (Security Considerations) M15.1 "The QOS attribute defined in this document SHOULD be used by the man= aged networks for enforcing Quality of Service policies=85" The use of SLA= information is out of scope! M15.2 "=85so there should not be any risks for identity thefts." What does= that mean? Identity theft? Are you talking about the possibility of hija= cking? (I'm just guessing because the next sentence talks about Origin Val= idation.) M15.3 "To strengthen the security for the QoS attribute, RPKI based origin = validation [RFC7115] MAY be used." How does Origin Validation strengthen t= he security of the QoS attribute? Origin Validation can help the receiver = verify that the origin AS is in fact authorized to advertise an NLRI, but n= ot that the valid prefix origin did in fact also originate the QoS attribut= e. Section 4. (Originating SLA Notification) does say that the "QoS attri= bute=85MUST NOT be added during BGP propagation", but there doesn't seem to= be a way to detect non-compliance making it an important security consider= ation. M15.4 "=85BGP Path Validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]) proce= dures could be used over BGP QoS attribute and its associated prefix in pro= ducing the digital signature that can be carried within the signature SLA f= or the messages." What is the "signature SLA"? This text is proposing to = change BGPSec =97 as is, this proposal presents no assurances over the *cur= rent* risk of a MITM (until maybe someday the proposal is specified and imp= lemented). I would rather you clearly identify why there is a risk of MITM= =97 and then say that there is no solution (which is the same as for other= transitive attributes). M15.5 Speaking of MITM, what about privacy? Even if the MITM doesn't chang= e the QoS attribute it can still glean a lot of useful information from jus= t forwarding the UPDATES. Please include some text about privacy. Please = take a look at RFC6973. M16. [T3] Section 10. (IANA Considerations) M16.1 There is no guidance about the QoS Attr flags. I know they are not u= sed in this document, but because it is the document that defines them it w= ould be good to have a registration criteria. M16.2 [minor] I know the space is small, but the SubTypes and SLA Event Typ= es have a registration procedure of Standards Action. I wonder if having a= value (maybe just one) for Private Use could be beneficial to allow people= to put their own stuff in there=85 M16.3 [minor] This sentence seems out of place since it provides no guidanc= e to IANA: "QoS SLA Traffic Class Element Types will be referring to existi= ng IPFIX IANA types as listed in Table 1." Minor: m1. [T1] The Introduction talks about the fact that other "protocols and da= ta models are being created to standardize setting routing configuration pa= rameters within networks. YANG data models=85the I2RS protocol", but that = "some providers desire to exchange QoS parameters in-band utilizing BGP pee= ring relationships." Two related questions: m1.1 Is there specific YANG/i2rs work in process that matches what is defin= ed here? How are the models similar/different? Note that this is not a qu= estion about comparing the use of YANG models, the i2rs protocol and the me= chanism using BGP -- I just want to know if there are other similar effort= s in progress and how they are in sync or not. The underlying question is = really about whether an operator will be able to use a NETCONF/i2rs to conf= igure the SLA information received in a BGP session (as specified in this d= ocument). I know that anything is possible, but is that the direction that= is being taken today? m1.2 Are there implementations? It would be nice to add a section ala rfc6= 982 and point to the idr wiki from there. m2. [T3] The new attribute is called by several different names in the docu= ment: "QoS Attribute", "QoS/SLA Attribute", "QoS BGP attribute", and simply= "attribute" in a couple of cases. Please be consistent!!! m3. Section 3.3.2.3. (Traffic Class for MINRATE_IN_PROFILE_MARKING) I'm n= ot sure how to interpret this: "Marking code-point type =3D 8 bits (1 octe= t) IPFIX Element Identifier=85The marking code-point type of 0x00 is a drop= identifier; the length in this case is zero." IPFIX has Element ID 0 as = reserved. I'm guessing that you mean that if the code-point is 0x00, to be= tter yet, if the length is 0, then drop. ??? m3.1 Same comment for 3.3.2.4, 3.3.2.5 and 3.3.2.6 m4. For all the sub-sections in 3.3.2, please put in a short explanation of= what each TLV represents. m5. Section 8. (Deployment Considerations) I think this section should rea= lly be called "Use Cases" and moved earlier in the document, maybe even as = part of the Introduction. It would be very nice if the case for propagatin= g the QoS Attribute through multiple AS hops was also illustrated. m6. References m6.1 RFC3270 should be Informative m6.2 If RFC7115 is referenced as Normative, then so should I-D.ietf-sidr-bg= psec-protocol because you're offering them as solutions to security issues.= Please take a look at my comments on the Security Considerations Section = above. m6.3 For the illustration in the document, I don't think the reference to R= FC7674 is needed. Nits: n1. s/=85and then optionally followed by for the opposite direction/=85and = then optionally followed by the specification for the opposite direction n2. Please expand on first use: TSpec n3. In 3.3.2.3, please be explicit that the Value contains the Marking code= -point type and value. n4. In 4.1, "next hop to CE (that is the next hop address from CE to PE)"= =85shouldn't that be "next hop to PE"? --_000_D343FE1E121ABDaretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Dear authors:

I just finished reading this document.

I have significant concerns with the content (see my detailed comments belo= w), and with the fact that the we're producing this document on SLAs in a r= outing WG.  It is "ok" [*] to carry information in BGP that = is not related to routing, but in this draft we're really defining how to represent an SLA.  The only BGP-specific work = is related to propagating a new transitive attribute =97 we don't need 30 p= ages for that!!

Many of my comments are keyed off these statements in the Introduction: &qu= ot;The Inter-domain exchange of QoS SLA exchange policy described in this d= ocument=85only requires that the provider wishes to send the QoS SLA policy= via BGP=85to a set of receivers=85The SLA negotiation and assurance is outside the scope of this document."   My interpretation is = that BGP is then used as a simple transport for the SLA information and tha= t it can't (and shouldn't!) concern itself with the interpretation, validation or enforcement of the information it is transporting.

Given that, I want to first mention = 3 overarching themes that I want to see addressed (I also tried t= o indicate which theme the comments below relate to):

T1. The SLA Definition.  As m= entioned above, it concerns me that this WG has taken on the task of defini= ng the description of an SLA.  At a minimum, this document should have been discussed in the TSV and OPS areas, for bot= h sanity checking and coordination.  I found in the archive some excha= nges with tsvwg (from 2013, when the =9601 version was published) -- i= n the thread, the tsvwg Chair mentions the need for coordination as they have related work.  However, the communicati= on abruptly ends [1] -- note that the last recommendation from tsvwg w= as against having multiple drop thresholds in DROP_THRESHOLD (Section 3.3.2= .8), but the current version still hast that =97 it does seem like the conversation was concluded=85   Please seek out review from both tsvwg and opsawg= (or at least the OPS-Dir).  


T2. Who does what?  (aka which funct= ionality belongs in BGP?)   

I then see the document as containing two distinct sets of specifications: = (1) how does BGP transport some information in a transitive attribute (incl= uding how a BGP speaker validates the formatting), and (2) how the user of = the SLA information (which is not the BGP speaker itself, but some other consumer) should deal with it. &nbs= p;I would really like to see a clear definition of who (the BGP Speaker or = something else) is executing the action =97 keeping into account that it is= out of scope what exactly is done with the information.

I would like to propose a simple framework/terminology for the process, whi= ch I think is something like this:  
A. the SLA_Provider (which represents whoever/whatever comes up with the SL= A definition) gives the formatted information to BGP for it to transport (a= ssociated with a prefix, destined to a list of ASNs, etc.); 
B. BGP puts the formatted information in the QoS attribute and advertises i= t in an UPDATE; 
C. the BGP receiver verifies that the UPDATE is formatted correctly (includ= ing the QoS Attribute);
D. a SLA_Consumer (which represents a local process that will make sense of= the content and maybe even do something with it) further verifies that the= content makes sense, keeps track of the SLA ID, etc..

Right now, the document doesn't clearly assign roles and it seems like= everything is done by the BGP speaker, where conceptually it isn't because= BGP is a routing protocol and not an SLA_Producer or SLA_Consumer.  F= or example (there are more cases below), Section 5.2. (SLA Attribute Handling at Receiver) says that "the rece= iving BGP peer SHOULD invalidate previous advertised SLA parameters if one = exists for the same SLA id and source AS."  Following the concept= ual model above, this action would be done by the SLA_Consumer, who may care about the content itself.

If you don't want to use the simple framework above and want to use ot= her names, that is perfectly fine.  I just want the document to clearl= y reflect what is done by BGP and what is done by someone else.  


T3. Clarity and Consistency=85  I am= very disappointed in the fact that the SLA itself is underspecif= ied, that there isn't consistency on the names used (even within the defini= tion of the fields!) and that some sections seem to be left to the readers' interpretation (guessing!).  Examples include= simple things such as the units in which the length is indicated, and=  using consistent names.  Those may be easy to correct, but a Sta= ndards Track document should not be in this state at this point in the process.  There are many more examples below.



I'm returning the document to the WG for further processing.  I expect= that proper coordination and review with TSV and OPS, including a new WGLC= with the appropriate WGs in cc (tsvwg, for example), takes place before re= turning to the IESG.  I recommend that other comments be addressed before embarking in reviews beyond idr.

Thanks!

Alvaro.

[*] Given the fact that we already throw all kinds of stuff on top of BGP= =85 :-( 



Major:

M1. [T1] [T2] Introduction: "The Inter-domain exchange of QoS SLA= exchange policy described in this document does not require any specific method for the provider in establishing SLAs. &n= bsp;It only requires that the provider wishes to send the QoS SLA policy via BGP UPDATE [RFC4271] messages from the provider to a set of receivers (BGP = peers) who will enact the policy.  In reaction to, a receiving router may translate that to relevant QoS policy definition= on the device=85  The SLA negotiation and assurance is outside the sc= ope of this document."

M1.1. [T2] If I interpret this text = correctly, the intent of this document is to propagate the new attribute (with SLA information in i= t), but it takes no position as to what the receivers do with the information.  Is that correct?

M1.2 [T2] If so, then the "enact the= policy" part above is out of place because there's no assumption as t= o what will happen with the information.



M2. [T3] Section 3.1. (SLA, QoS attribute sub-type, Definition)   &nbs= p;SubType range is not defined correctly: s/0x0f/0xff    What is = the  SubType length expressed in, octets?



M3. [T3] Section 3.2. (SLA SubType Value Field) 

M3.1 "Source AS=85Note that AS =3D 0, used in message outside of QoS a= ttribute, is illegal in normal BGP operations.  AS =3D 0 inside the Qo= S attribute may be used simply as a flag=85"
M3.1.1 [minor] Please put a reference to rfc7607.
M3.1.2 Given that this document specifies a new valid use of AS 0, I think = it should be marked as Updating rfc7607.
M3.1.3 What is the purpose of this field?=  Section 4. (Originatin= g SLA Notification) does say that the "QoS attribute MUST only be added by the originator=85", but it seems easy to forge the value her= e.

M3.2 For the "Destination AS list" field description, it should b= e clearly specified the contents if the "Destination AS count" is= 0.  Also, please be specific and clear (word are free!), for example:= "List of ASNs for which the SLA is relevant, each of which is a 32-bit number [rfcREFERENCE].  If the Destination AS count is se= t to 0, then this field SHOULD NOT (?) be included in this sub-TLV=85."= ;

M3.3 "SLA Event": the field in Figure 3 is simply called "Ev= ent".  Please be consistent: either call both the same way or cla= rify which field is being referenced.  I know it may be obvious, but i= t doesn't make for a crisp specification =97 other parts of the text simply use "event" as well.  Please be specific and cl= ear as to what this field indicates.

M3.4 SLA Id
M3.4.1 "A 16-bit field containing id= entifier which is unique in scope of source AS"  What happens if the Source AS= is set to 0?
The SLA ID = applies aggregate for all the traffic=85"   I'm guessing you meant to talk about the "aggregate traffic"<= font face=3D"Calibri,sans-serif">=85??
M3.4.3 "The SLA identifier is not globally unique but it MUST be unique within the source AS (advert= iser)."  What happens if the Source AS field is set to 0?  T= he text in the Source AS field description says that when the value is 0 th= en "ignore Source=85".  What does this do to the content of the SLA ID.
M3.4.4 [minor]  BTW, please be consi= stent: SLA ID, SLA id, SLA Id, SLA identifier, etc

M3.5 What is the "SLA Length" f= ield expressed in?

M3.6 SLA-Content per SLA Event
M3.6.1 The name seems to hint at the fact= that the content is "per Event", but it is not described an= ywhere how multiple events would be encoded, or if even possible (see = my comment above about the Event field).
M3.6.2 Is the name of this field "SL= A-Content per SLA Event" or "SLA-Content"?  Please be c= onsistent.
M3.6.3 "If the SLA-Content field does not exist= =85then receiver MUST inherit the previously advertised SLA content for the same SLA id from the same Source AS." &= nbsp; The next two paragraphs try to cover for the fact that the order cann= ot be guaranteed (specially more than one AS hop away).  But this all means that there is a significant possibility th= at a number of UPDATES will not have any SLA information at all.  Then= what is the point?  When would you want to take advantage of this fea= ture?



M4 [T3] Section 3.3. (SLA-Content per Event Field)

M4.1 [nit] s/=85and then optionally followed by for the opposite = direction/=85and then optionally followed by the specification for the oppo= site direction

M4.2 [nit] The format of the field s= tarts with the "dir" field =97 is the following text really neces= sary: "This list of Traffic Classes MUST be specified for = one direction first=85"  It seems obvious to me.

M4.3 "dir=85indicates Direction of the SLA."  I'm guess= ing direction from the senders point of view, is that correct?  Please= be specific.

M4.4 "Traffic Class (Cla= ssifier Group) count=85value of zero (0x0= 0)=85invalidates previous advertised SLA=85"  In this case, I'm assuming that all the other fields are not needed, is that correct?  If so, then they are o= ptional and should be described that way.

M4.5 "Class Descr Len=85length = of the Traffic Class Description field"   Length in w= hat units?

M4.6 [minor] "Traffic Class Description"  A reference for UTF-8 (rfc3629 I believe) would b= e nice.

M4.7 "Elements (Classifi= er) Count=85value zero (0x00) means=85tra= ffic class is to classify rest of the traffic not captured othe= rwise by other traffic classes=85REC= OMMENDED that Traffic Class that has 0 elements is present last=85If an= advertised message has it positioned somewhere else, then the = receiver MUST re-order it=85"   This text (as is) implies that the 0x00 classifier SHOULD be presen= t last =97 is that what you meant, for it to always be present? &= nbsp;If so, why not use MUST and eliminate the reordering logic?  Or w= as the intent that if p= resent then it should go last?

M4.8 Classifier Element TLVs:=
M4.8.1 The description talks about &= quot;Classifier Element TLVs"= , but Figure 4 calls them "Tr= affic Class Elements (TLVs)".  Please be consistent.
M4.8.2 "Size of Value field=85length of the value field." &n= bsp; Length in octets, bytes, bits, ???
M4.8.3 [T2] "Value=85It is an error if the IPFix field does not c= ontain the appropriate format"  This statement gets into interpre= tation of the contents of the attribute.  If the purpose of this docum= ent is to just transport information, then why would it be a function of BGP to figure out if the contents are correct?  Plea= se be clear about whether the BGP Speaker or SLA_Consumer should perform a = function.
M4.8.4 "If a receiver receives a BGP UPDATE message with QoS= /SLA attribute for an NLRI that it does not support then the receiver = MUST NOT install that advertised SLA and continue to forward this attr= ibute as an optional transitive attribute."  What does "an NLRI that it does not= support" mean?  Are you talking about an NLRI from a specif= ic unsupported AFI/SAFI, or ??  

M4.9 Traffic Class Service TLVs:&nbs= p;
M4.9.1 The units for the length are = (again!) not specified.  I realize that it may be in bits (given the n= ext couple of paragraphs), but the reader shouldn't have to guess.
M4.9.2 As long as you're thinki= ng about the length, please check all the length descriptions =97 = ;I think most of them are missing the units, but this is getting tedious=85
M4.9.3 Please note that the length of the value fields is not describe= d consistently.  For example, it says that TRAFFIC_CLASS_TSPEC is= 96 bits, but 3.3.2.3 talks about octets for MINRATE_IN_PROFILE_MARKIN= G.  
M4.9.4 "Value=85It is an error if this field does not contain&nb= sp;the appropriate format (see BGP error handling section=85."   Not only is this error appropriate for the SLA_Consumer, but the "appropriate format" i= s not clearly identified in the description of all the TLVs.



M5 [T1] Section 3.3.1. (Supported IPFIX values for Classifier Elements)

M5.1 [minor] The correct link to the IPFIX Registry is ht= tps://www.ietf.org/assignments/ipfix/ipfix.xml#ipfix-information-elements

M5.2 "Onl= y the IPFIX attributes listed in Table 1 are supported by BGP SLA exchang= e."  Why?  If this document is just about carrying a new att= ribute that is opaque to BGP itself and that may or may not result in an ac= tion at the receiver (see above), then why not support any IPFIX element?  Maybe not all of the elements make sense, but som= e surely seem to =97 ipClassOfService, for example.

M5.3 "Any new attribute to be= supported by SLA QOS MUST be added = by a Standards Action."  To be added where?  The IPFIX regis= try has a different registration procedure (Expert Review) -- are you referring to adding elements there?  Or adding elements = (already in the IPFIX registry) to= Table 1?  Or ??



M6 [T1] [T3] Section 3.3.2.1. (Traffic Class TSPEC TLV) The value of t= his TLV "consists of the (r), (b), (p) parameters as descr= ibed in Invocation Information section of [RFC2212]=85".  However, the definition in the document is not the same as the one i= n rfc2212.  For example, this document defined r as "measured in = octets of Layer 2 (L2) datagrams per second", while rfc2212 says = that it is "measured in bytes of IP datagrams per second".  If the intent is to (as stated in the document) use the definitions = from rfc2212, then don't redefine the terms.



M7 [T1] [T2] [T3] Section 3.3.2.2. (= Traffic Class L2 Overhead): 

M7.1 [T3] Section 3.3.2.2. (Traffic Class= L2 Overhead)  How is the L2 overhead defined?

M7.2 [T1] [T2] "adverti= sed SLA and if the L2 Overhead service type is present in advertised SLA, the receiver MUST use the explicit advertised L2 = overhead rather than the local L2 overhead."  In the context of this docu= ment, where the use of the SLA is out of  scope, what does "react= to an SLA" mean?   IOW, we can't mandate what the receiver does,= or how it does it if outside the scope.

M7.3 [T1] "If SLA is required to consider only IP packet size, the sen= der MAY advertise this service with a value of 0."  Again, the re= ason is out of scope.  The ability to advertise a value of 0 is not.



M8. [T1] Section 3.3.2.7. (Precedence between MINRATE and MAXRATE) &nb= sp;Back to the data being opaque..why is this section included in the docum= ent?



M9. [T3] Section 3.3.2.9. (Traffic Class for Relative Priority)  "= ;Length =3D 4 bits"  Unlike all the other length issues I've= pointed at, this time you seem to be indicating the length of the Val= ue field.  Does this mean that the Length field in they TLV shoul= d be set to 4 (as in "the length of the Value field in bits"), or = that the Length field should not even be present because it is always 4 bit= s, or something else??



M10 Section 4.1.2. (SLA Advertisement for Destination AS Multiple Hops= Away) "If a new prefix is added in an AS for which SLA paramet= ers have already been advertised before for other existing prefixes, and if traffic to this new prefix is subject to th= e same SLA advertised earlier, then the BGP UPDATE for this new prefix= may include QoS attribute containin= g just an SLA id=85"

M10.1 Is this behavior also valid for directly connected peers?

M10.2 The description above assumes that the receiver has the SLA descripti= on from a previous UPDATE.  See my comments above about Section 3.2.&n= bsp;



M11. [T2] Section 5.1. (BGP Node Capable of Processing QoS Attribute)=   

M11.1 Back to the opaqueness of the = attribute from the BGP point of view and how the use of the information is = out of scope.  What does "processing" mean in this context? =  I think you will need to separate the processing done by the BGP Speaker from what the SLA_Consumer should do.

M11.2 "If UPDATE has a QoS Attribute with a list of destinatio= n ASes, it MAY trim the list and adjust the count of the destination AS to exclude ones that are not required in further announcement of= BGP UPDATE messages."  Just to make sure I'm looking at thi= s from the right place: this text applies to a BGP speaker that received the QoS attribute from someone else and is now getting ready= to propagate it, right?  If so, isn't changing the list of destination ASes basically an atta= ck on the intent of the origin?

M11.3 "BGP peer MUST drop SLA related sub-type fr= om the QoS attribute, if there are no more ASes from the QoS Attribute's destination list in the forwarding path.  The rest of the QoS attribut= e contents MAY be Forwarded=85"
M11.3.1 What is the "forwarding= path"?  I'm guessing that means something like: if the AS is not= connected to any other AS on the list (except the one it just receive= d the UPDATE from)=85 What is it and how can the ingress BGP speaker in the AS figure it out?
M11.3.2 [minor] Please be consistent= with the naming.  I'm assuming that "SLA related sub-type" is really the SLA sub-type value 0= x01=85  Even though they are not defined yet, other sub-types may also refer to SLAs.
M11.3.3 The "MAY" above is= normative in a "forward" manner: affects potential future SubTyp= es.  If new SubTypes are defi= ned later, let them define the behavior.  s/MAY/may
M11.3.4 [minor] Note that this whole= paragraph is repetitive, please simplify it.



M12. [T1] [T2] [T3] Section&n= bsp;5.2. (SLA Attribute Handling a= t Receiver)  

M12.1 "Reception of and processing of advertised QoS SLA content = are optional for the receiver= ."  What do you mean that "reception" is optional?  What is "processing"?  Given that the use of the SLA = is outside the scope, I can only guess that "processing" mea= ns at least parsing the contents (not actually doing anything with them). &= nbsp;If so, what do you mean by saying that "processing" is = optional?   In general, if an attribute is sent inside an UPDATE it then has to b= e "received" (unless all the NLRI contents are filtered by policy= ) and "processed".  This part sounds like it belongs with th= e SLA_Consumer.

M12.2 "the receiving BGP peer SHOULD inval= idate previous advertised SLA parameters if one exists for the same SLA id and source AS."  I think you really want the SLA_Consumer (not t= he BGP peer).  What does "invalidate" mean in this context? =  Maybe replace or an indication what the new version, etc.  

M12.3 "If the new advertised SL= A has a non-zero traffic count=85"  "traffic count" is = not defined anywhere in the document=85  I guess you mean the "Tr= affic Class count" -- please be clear and specific.

M12.4 "=85advertised SLA= SHOULD be installed"   Installed?  This sounds like you're specifying what to do with the SLA specification=85outside the scope!   Even for the SLA_= Consumer=85

M12.5 "When BGP UPDATE messages are triggered only as a result of= SLA policy change=85the receiver MAY implement a policy to filter such mes= sages based on the prefix and attribute."  I appreciate the inten= t, but what about changes in other attributes?  IOW, the receiver doesn't know that the change was only due to an SLA policy ch= ange (which from the BGP point of view may be better called something like = "an update in the QoS attribute").  Please clarify that if t= he filter is put in place, all the other attributes need to be checked as well.  BTW, I think that the "MAY" sh= ould be "may", but that is minor.

M12.6 "=85the receiver MAY impl= ement advertised SLA for the whole link=85"  This is an indicatio= n of what to do with the SLA=85out of scope!

M12.7 "=85QoS attribute with th= e SLA=85"  To be complete, I think you mean "with the SLA Su= bType field".

M12.8 "=85then receiver may est= ablish advertised SLA for that specific prefix list under the relevant link= ."  Even thought not in a normative way, this text also talks abo= ut the use of the SLA=85out of scope!

M12.9 "It is completely up to t= he receiver to decide for which prefixes it should accept advertised SLA an= d for which ones it will not accept."  Which receiver?  I'm = guessing the SLA_Consumer, because the BGP speaker has no choice but to accept any attribute=85  Are you implying here that = the BGP speaker should be able to selectively filter QoS Attributes?=



M13. Section 6. (Error Handling)  

M13.1 [T2] What is an "error condition"?  I counted 4 p= laces where an error was explicitly identified =97 surely there are more ca= ses that would result in an "error condition".  I'm assuming= that a malformed attribute (as in the length not matching) is an obvious one (no need to explicitly call that out, but maybe a reference to= the general attribute processing in rfc4271 would be good)=85but what abou= t if the Source AS is set to 0 and the Destination AS count is not 0, is th= at an error?

M13.2 [T2] OTOH, errors on general attribute format checking (do the l= engths/counts match, etc.) is where attribute-discard applies for the BGP S= peaker=85other errors (including some of the ones explicitly identified in = the text) may be more in the domain of the SLA_Consumer.  Note that even though the SLA_Consumer may deci= de to not use the SLA (which is equivalent to attribute discard), I th= ink some of the checking (formatting of the values, for example) doesn't be= long to the BGP Speaker.

M13.3 [nit] s/attribute-discard/attribute discard



M14. Section 7. (Tra= ffic Class Mapping)  What is done with the SLA is out of scope!  = The mapping, or not, of policies is also out of scope =97 special= ly the normative language included in the section.  Recommendation: delete this section completely.



M15. Section 11. (Security Considerations)

M15.1 "The QOS attribute defined in this document= SHOULD be used by the managed networks for enforcing Quality of Service policies=85"  The use of SLA information is out of sc= ope!

M15.2 "=85so there should not be any risks for identity thefts."  What does th= at mean?  Identity theft?  Are you talking about the possibi= lity of hijacking?  (I'm just guessing because the next sentence = talks about Origin Validation.)

M15.3 "To strengthen the security for the QoS attribute, RPKI= based origin validation [RFC= 7115] MAY be used."  How does= Origin Validation strengthen the security of the QoS attribute?  Orig= in Validation can help the receiver verify that the origin AS is in fa= ct authorized to advertise an NLRI, but not that the valid prefix origin did in fact also originate the QoS attribute.  Section&= nbsp;4. (Originating SLA Notificat= ion) does say that  the "QoS attribute=85MUST NOT be added during BGP propagation"= , but there doesn't seem to be a way to detect non-compliance making it an i= mportant security consideration.

M15.4 "=85BGP Path Validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]) procedures co= uld be used over BGP QoS attribute and its associated prefix in producing the digital signature that can be carried within the signature SLA for the messages= ."  What is the "signature SLA"?  This text is pro= posing to change BGPSec =97 as is, this proposal presents no assu= rances over the *current* risk of a MITM (until maybe someday the proposal is spe= cified and implemented).  I would rather you clearly identify why= there is a risk of MITM =97 and then say that there is no soluti= on (which is the same as for other transitive attributes).

M15.5 Speaking of MITM, what about p= rivacy?  Even if the MITM doesn't change the QoS attribute it can stil= l glean a lot of useful information from just forwarding the UPDATES.  = ;Please include some text about privacy.  Please take a look at RFC6973.



M16. [T3] Section 10. (IANA Considerations)

M16.1 There is no guidance about the=  QoS Attr flags.  I know= they are not used in this document, but because it is the document that de= fines them it would be good to have a registration criteria.

M16.2 [minor] I know the space = is small, but the SubTypes and SLA Event Types have a registration procedur= e of Standards Action.  I wonder if having a value (maybe just on= e) for Private Use could be beneficial to allow people to put their own stuff in there= =85

M16.3 [minor] This sentence seems out of place since it provides no gu= idance to IANA: "QoS SLA Traffic Class Element Types will be referring= to existing IPFIX IANA types as listed in Table 1."




Minor:

m1. [T1] The Introduction talks about the fact that other "protocols a= nd data models are being created to standardize setting routing configurati= on parameters within networks.  YANG data models=85the I2RS protocol&q= uot;, but that "some providers desire to exchange QoS parameters in-band utilizing BGP peering relationships."  Tw= o related questions:

m1.1 Is there specific YANG/i2rs work in process that matches what is defin= ed here?  How are the models similar/different?  Note that this i= s not a question about comparing the use of YANG models, the i2rs protocol = and the mechanism using BGP  -- I just want to know if there are other similar efforts in progress and how they are in= sync or not.  The underlying question is really about whether an oper= ator will be able to use a NETCONF/i2rs to configure the SLA information re= ceived in a BGP session (as specified in this document).  I know that anything is possible, but is that the= direction that is being taken today?

m1.2 Are there implementations?  It would be nice to add a section ala= rfc6982 and point to the idr wiki from there.



m2. [T3] The new attribute is called by several different names in the docu= ment: "QoS Attribute", "QoS/SLA Attribute", "QoS B= GP attribute", and simply "attribute" in a couple of cases. =  Please be consistent!!!



m3.  Section 3.3.2.3. (Traffic = Class for MINRATE_IN_PROFILE_MARKING)  I'm not sure how to interpret t= his:  "Marking code-point type =3D 8 bits (1 octet) IPFIX = Element Identifier=85The marking code-point type of 0x00 is a drop identifier; the length in this case is zero."   IPFIX has = Element ID 0 as reserved.  I'm guessing that you mean that if the code= -point is 0x00, to better yet, if the length is 0, then drop.   ???

m3.1 Same comment for 3.3.2.4, 3.3.2.5 an= d 3.3.2.6



m4. For all the sub-sections in 3.3.2, pl= ease put in a short explanation of what each TLV represents.



m5. Section 8. (Deployment Considerations)  I think this section should really be called "Use = Cases" and moved earlier in the document, maybe even as part of the Introduction.  It would be very nice if the case for p= ropagating the QoS Attribute through multiple AS hops was also illustr= ated.



m6. References

m6.1 RFC3270 should be Informative

m6.2 If RFC7115 is referenced= as Normative, then so should I-D.ietf-sidr-bgpsec-protocol because you're offering them as solutions to security issues.  Please take a look at= my comments on the Security Considerations Section above.

m6.3 For the illustration in the doc= ument, I don't think the reference to RFC7674 is needed.




Nits:

n1. s/=85and then optionally followed by for the = opposite direction/=85and then opt= ionally follo= wed by the specification for the opposite direction

n2. Please expand on first use: = ;TSpec

n3. In 3.3.2.3, please be explicit that the Value contains the = Marking code-point type and value.

n4. In 4.1, "next hop to CE (that is the next hop address = from CE to PE)"=85shouldn't that be "next hop to PE"? 
--_000_D343FE1E121ABDaretanaciscocom_-- From nobody Fri Jun 10 01:13:00 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AF912B01E; Fri, 10 Jun 2016 01:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyacX9D9PakU; Fri, 10 Jun 2016 01:12:57 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9C812D09B; Fri, 10 Jun 2016 01:12:57 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id m124so91042625wme.1; Fri, 10 Jun 2016 01:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=IpdLoc7ijPSWRvaaUOkPeVxqRT27N7ZFB9ud7WDZb9s=; b=04BLEQaJDhEXJj0HltGe+pFAWXSztP8Ojk7BYTIovGMMYDVDb9GeCwbXo8eZ+YCs1b 003AmIxEIxZM+HejALvaBpvE1pTw2iE3zCEdQHX1vqoVAGNsJoAi5Jktrw1ng7f0eHbQ Npwpcu2VPeg5fHic3w7Eq5LCFVTHUcpcJAvQ9667cKorr+mUFC/9r+yuUoGyOPb9L5tb jm+b6hlXEyp3TFh5bX8JKBFiqpiRz2+GU4bLRwmsL0LdvKBBcbGGNdWwe+NSYmOCVYki uHI/DxQ2o77NXMklyNfGkayr8D4DijJ4H65PvARlOlHSoVuJr0dbTelm/sD7CkNmbO1t wrLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=IpdLoc7ijPSWRvaaUOkPeVxqRT27N7ZFB9ud7WDZb9s=; b=Jl449q8DJ7ChtEuD5rZVIokQ9rUB2sz23xQcVebRU+x7et/tLpQUhQ60+uRHZ6plo9 zCzYqed5v9j7SXbOhV6GTqB4wwqG0/butFY/CjB/ib9DWx26e+HgseZh5PCmGxSlcJbZ b5Cp3E5zvH3xt0qThuln7q1/nE3Vx2pBQUBqF/d3BNP7aiEoRtv1MhjwtkBbiPyO/y7a d9wRT081vMKPKpDExg645XJ6XSb8kQEk96TccJb1q+hMAMbm+8oD5Z/v7eor8zWzr7IW R/4+PAayMsjA9DM3Vpwrathc353KnlqHG42RGBppJZeC4ef3ePlTGXChOOpqerYQJCou yCzQ== X-Gm-Message-State: ALyK8tJBXhuyHsnM+2L1DjPn6hS8dpWHEzx+qefhEtA8d0WI/7mv+UO4boT7wwdlt6KN1A== X-Received: by 10.194.74.104 with SMTP id s8mr894179wjv.20.1465546375618; Fri, 10 Jun 2016 01:12:55 -0700 (PDT) Received: from ISOC-A1FD58.local (j163159.upc-j.chello.nl. [24.132.163.159]) by smtp.googlemail.com with ESMTPSA id wo3sm11073291wjb.12.2016.06.10.01.12.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 01:12:54 -0700 (PDT) To: Susan Hares , idr@ietf.org References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> From: Andrei Robachevsky Message-ID: Date: Fri, 10 Jun 2016 10:12:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HwRrlir3iUJxIMle5KQLWlBOKFnOh8NPo" Archived-At: Cc: draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 08:12:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HwRrlir3iUJxIMle5KQLWlBOKFnOh8NPo Content-Type: multipart/mixed; boundary="BvuFtelbxTHuwqFMrHu3R2j9kSkP99NON" From: Andrei Robachevsky To: Susan Hares , idr@ietf.org Cc: draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" Message-ID: Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> In-Reply-To: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> --BvuFtelbxTHuwqFMrHu3R2j9kSkP99NON Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear WG, Susan Hares wrote on 06/06/16 18:40: > This begins a 2 week WG Adoption call for > draft-ymbk-idr-bgp-open-policy. You can find the draft at: >=20 > https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/. >=20 > =20 >=20 > In your comments on adopting this draft, please indicate: >=20 > =20 >=20 > 1) =93Support=94 or =93no Support=94 > No Support. I think proposed enhancements to the BGP Open message in signalling the relationship could be a useful property that should be explored further. For instance, in cases where a single policy (e.g. peer-peer) can be applied to the BGP session, this method can be used for automating setting of the RLP field. I suggest that this amendment is documented in a separate draft, which I'll support for the WG adoption. > 2) Do you feel this is a way to prevent route leaks? >=20 In some cases. > 3) Are there any deployment issues that might prevent deployment o= f > this enhancement to BGP Open? >=20 Variation of routing policy on per prefix basis. > 4) Does this interact with > draft-ietf-idr-route-leak-detection-mitigation? >=20 The proposed OTC flag is similar to the RLP field, but the semantics is different. I suggest that the considerations for the OTC flag (especially a single flag vs per-hop) are discussed in the framework of the the draft-ietf-idr-route-leak-detection-mitigation and a best way is chosen by the WG, rather than having 2 parallel threads of incompatible solutions. Full disclosure - I am one of the co-authors of draft-ietf-idr-route-leak-detection-mitigation Andrei > =20 >=20 > Sue Hares and John Scudder >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 --BvuFtelbxTHuwqFMrHu3R2j9kSkP99NON-- --HwRrlir3iUJxIMle5KQLWlBOKFnOh8NPo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAldadoYACgkQljz5tZmtij+kQQCg1/tPkMUU3k05ukNPwlTBLZan og4An1cPibA6WpmSC2Av+rCNrAqSSNr2 =T8Z7 -----END PGP SIGNATURE----- --HwRrlir3iUJxIMle5KQLWlBOKFnOh8NPo-- From nobody Fri Jun 10 02:23:34 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED1812B03D for ; Fri, 10 Jun 2016 02:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.334 X-Spam-Level: X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRo0OIAX84LC for ; Fri, 10 Jun 2016 02:23:29 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB2912D518 for ; Fri, 10 Jun 2016 02:23:29 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 21224206FE; Fri, 10 Jun 2016 11:23:28 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id E5ACB4005B; Fri, 10 Jun 2016 11:23:27 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 11:23:27 +0200 From: To: Lucy yong , "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt Thread-Index: AQHRwYlWKLZD+NLIGEG6YM0mvKsgaJ/fj6NAgAA+7fCAAp8FAA== Date: Fri, 10 Jun 2016 09:23:26 +0000 Message-ID: <3789_1465550608_575A8710_3789_7942_1_9E32478DFA9976438E7A22F69B08FF921BC4E487@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20160608132609.19947.65371.idtracker@ietfa.amsl.com> <2211_1465392560_57581DB0_2211_5567_1_9E32478DFA9976438E7A22F69B08FF921BC4661E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D57296547@dfweml501-mbb> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D57296547@dfweml501-mbb> 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_9E32478DFA9976438E7A22F69B08FF921BC4E487OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:23:32 -0000 --_000_9E32478DFA9976438E7A22F69B08FF921BC4E487OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lucy, Pls find some comments inline. Thanks, Stephane From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Wednesday, June 08, 2016 21:21 To: LITKOWSKI Stephane OBS/OINIS; idr@ietf.org Subject: RE: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt Hi Stephane, et al, I read this draft and have some comments. * I like this approach to treat interfaceset as FS scope, not as ma= tching, nor as action. * Instead of using group-identifier to express interfaceset in the = EC, IMO: it is better to use interface type to identify the interfaceset an= d have IANA registry for each interface type. This will make interworking/a= utomation easier. Any thought on that? [SLI] Bruno Decraene raised on similar comment at the beginning of the draf= t , proposing some "well-known" interface-set. There was not a strong suppo= rt for it considering that having a group-id will enable any scenario. Now = regarding your proposal of having a specific interface type defined, I thin= k it's really restrictive. I'm not opposite that someone creates new scope = for specific interface types later but I would like to keep the generic app= roach in this draft. Creating well known group-ids may also be reconsidered. * IMO: Content in Sn 6 is very useful, however it does not belong t= o this draft. These rules for processing permanent configured and BGP FS ap= ply to all BGP FS. It should be documented in one draft and apply to all BG= P FS drafts. FS ACL is just one type of BGP FS, there are others as well. T= he rules should be described in general term. I agree that there may be more iteractions to describe like Policy Based ro= uting. But I think that this draft is a good place to describe it. The base= flowspec does not precise where the rules must be applied, so it becomes u= p to implementation to place the rule where it best fits and manage interac= tion with other mechanism. Now with this draft, we know that the rules will be pushed on a pr interfac= e basis interacting with well known interface features. We cannot describe = all for sure. I will try in the next revision to be more generic and still = giving examples. * I am not clear what first sentence means in Sn 7. Does it say tha= t some interfaces may not be able to support the rules? Pls explain. [SLI] That's a question of scaling. With the base FS, the rule is applied i= n a single place, while here it may be "duplicated" in the forwarding plane= and implementations will need to look at optimizations to prevent to creat= e unnecessary states in the forwarding plane. I will see how to reword it. Thanks, Lucy -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: Wednesday, June 08, 2016 8:29 AM To: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt Hi IDR, This is a new version of the interface-set flowspec extension. As there was some misinterpretation of what the interface-set is (it is not= a match (as not part of NLRI) and it is not an action), we defined the not= ion of traffic filtering scope. Interface-set would be the first traffic fi= ltering scope defined, and nothing prevents to create new ones if required. Best Regards, Stephane -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Wednesday, June 08, 2016 15:26 To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Applying BGP flowspec rules on a specific interfa= ce set Authors : Stephane Litkowski Adam Simpson Keyur Patel Jeff Haas Filename : draft-ietf-idr-flowspec-interfaceset-01.txt Pages : 14 Date : 2016-06-08 Abstract: BGP Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP Flow-spec where flow specifications are used to maintain some access control lists at network boundary. BGP Flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP Flow-spec ([RFC5575]) introduces the notion of flow specification (which describes the matching criterion) and traffic filtering actions. The flow specification is encoded as part of the NLRI while the traffic filtering actions are encoded as extended communities. The combination of a flow specification and one or more actions is known as a flow specification rule. [RFC5575] does not detail where the flow specification rules need to be applied. Besides the flow specification and traffic filtering actions, this document introduces the notion of traffic filtering scope in order to drive where a particular rule must be applied. In particular, this document introduces the "interface-set" traffic filtering scope that could be used in parallel of traffic filtering actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers about groups of interfaces where the rule must be applied. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-flowspec-interfaceset-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ 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_9E32478DFA9976438E7A22F69B08FF921BC4E487OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
______________________________________________________________________=
___________________________________________________

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_9E32478DFA9976438E7A22F69B08FF921BC4E487OPEXCLILMA4corp_-- From nobody Fri Jun 10 02:43:31 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBFF12D0E3 for ; Fri, 10 Jun 2016 02:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reuTlXU9-e2B for ; Fri, 10 Jun 2016 02:43:28 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45944128E18 for ; Fri, 10 Jun 2016 02:43:28 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id m124so94229459wme.1 for ; Fri, 10 Jun 2016 02:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8TaR8wBR4jngovQTgY3FHOHosAi+hUGTOi1qmoqHYKo=; b=sqIW7ki8dtK1eW9IQCEyz0CX2nZxJatdriyjOfMWY/PWFyIO7IxFh5203wwyNp+ocv vppD+KweFJMH7iS9BZVgrWolpow5mAnHK50kUtBGgqJVkq3nJUmA+Y67amX3G1p1zIks zqaX1fc+qTJ/cabDvnC38spOzDZqBh95wG08UUsDZLgdynHs/6xuBULxylBcDbGXCBij 1WlzWyNKAV+1HDp7PqY9QCyibSIBXbk+5X+4QkxaNWKElmEBK3lsEXlHwvd195icNXhO xlZ4Jio0c9lGHH+qCc0owqtEjncHyTs+zJH5tpUe6+aY2FRHV/2RQDPWmsJEgveyszJ8 RBeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8TaR8wBR4jngovQTgY3FHOHosAi+hUGTOi1qmoqHYKo=; b=e5KnHtvGhYTx6olQVZXQDz9QEaEOve3GlNWIrAoDXozziQsFNY8susHzn1VrpmeN0T YlAMrODIw2wFGlDk7u+0iITCnqxrQhKJ0M1Wo7VbrhC5skAI49CM5Fl6QDkAkfmw6QtN daGBr4GjBSiE836k62wy1AfChNeDfaiO+NaEcPj9sd4INGuunnprvUkFX6FtFNmtjryL bACNmUkU7yiZRo7rWcY+7IYb5KG/2Z3q/NSsk0LVuFDhf0QMW12uSHV5lFk64RYgFTxR cA8/7UV6zn6OcC1bv3i7Z+7NsRmrFKZxN81M7TzorDqK5yAlJmafk35qT5TJptZUfMkl iIeg== X-Gm-Message-State: ALyK8tK41MnhZl4VE8HGDLuXlW5T+mjWOoORifJWWDJOlseSo6gJJ8MjJVO3ODpi1OLyYA== X-Received: by 10.194.114.193 with SMTP id ji1mr1371841wjb.55.1465551806562; Fri, 10 Jun 2016 02:43:26 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:f948:e3f7:3d8c:2db8]) by smtp.gmail.com with ESMTPSA id zg2sm11492818wjb.1.2016.06.10.02.43.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jun 2016 02:43:25 -0700 (PDT) Date: Fri, 10 Jun 2016 11:43:24 +0200 From: Job Snijders To: Randy Bush Message-ID: <20160610094324.GH2524@Vurt.local> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160609163225.GC2524@Vurt.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:43:30 -0000 Hi Randy, On Thu, Jun 09, 2016 at 12:37:10PM -0700, Randy Bush wrote: > > Secondly (and more importantly), the roles are not necessarily a BGP > > session-specific characteristic, but rather a prefix-specific > > property. The proposed OPEN method does not provide for this level > > granularity if I am reading it correctly. The method would affect all > > prefixes exchange over a BGP session, without exception. > > i can not be sure, as you lack example. but the example i commonly use > is when A gives B local peering and also sells B global transit. > today, this is two separate sessions. do you use another approach; not > can think of, but actualy use? Yes, using two separate sesssions to deliver the two separate products is a common (and valid) approach. > are there other real-world examples? just trying to understand. I won't share the company names involved, but on multiple occasions, my employer has engaged in providing transit between two peering partners. This was either done unilaterally (when my employer has a desire to keep the internet together), or part of a bilateral commerical agreement. In other words I cannot assume the BGP peer will cooperate with its role assignment. In all those cases, under the "OPEN" approach, we'd flag all involved parties as 'peer', and the peer would have assigned us the role 'peer' too, except that they weren't in some specific contexts. There are at least two use-cases: - some prefixes are 'peering', others are 'transit': this has happened for instance when redistributing root-server prefixes that were behind a peer to other peers. - all prefixes are peering, except they should be redistributed to peer X too (can be decided unilaterally or bilaterally). Reflecting on the two examples, the common theme is that if you are a stub network (e.g. one does NOT provide IP Transit using BGP to your customers) the "OPEN"-approach may be a reasonable approach, but for a transit network the approach feels too restrictive. Kind regards, Job From nobody Fri Jun 10 04:57:04 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90EE12D999; Fri, 10 Jun 2016 04:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oGpY_0OBYLz; Fri, 10 Jun 2016 04:57:02 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B2512B02F; Fri, 10 Jun 2016 04:57:01 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id j7so20812008lfg.1; Fri, 10 Jun 2016 04:57: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; bh=1Mt188GQBjM4eQBjfKeoiM62Jzq0iTjubkLHiwTeITY=; b=bXUwvtTeJ7AqgS4ZxZVelaVm44WVwQXlRc8YsmPPb0+1d10fzSD29TP8PsQ6EEvEbU D4I/y8Dp/rhVJhmzQv/pPD1q8r3R86LAd3BRH37h9+c9uBS/fj0Sw9DtglzkaS1mlo2f By5RUjTHn03Ioew/c+gJgmOqJ04/fG1/o0S969AmYkOkWHvat6qTrZJoFRlU3R9/NShy WRNjCQJ3cMd2emXAmftvnC1MqkTPy8iB5sfHPI1Y2/9ItxxZcnw5QOYFwsFKRKW5Iwyx HJdE5oUbuyC6DrvMQt8p0/s7/opeDsg0qnP43X9U+95hsvJwpBf+VKRGg9EuZdxYhptO Xx/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1Mt188GQBjM4eQBjfKeoiM62Jzq0iTjubkLHiwTeITY=; b=h7BM57OFJ63tvE/Pp9Xp0umHkbVJEh0e+yzNwq5cu74Y6T1o/mhSyArPa6tLpRLt4Y 39lKFY4NVefK6dvvzAfAojYSa0096KocVRxPScGjPRRXnF7E1tBU5EtKKyOoQtPKMQ1u u3cty4BMMrmoKW0pJJjjRfso4K8AaKp7nhNyW07APQr0mdNyPJlGi+VTcjHKH0TScYDU /j7tWXpfCu+xywBBUxXni5NdEVQo6cOdQYoUKLqsHWG1Avc5cEeFUkC5g2QZEYXmnhCU 4AyYUDVCYBUSkZeOAXK4hDQ9MSLb569aaaSg2pi6Jh6RQMT5D0lVyNLqYxS2o0iB/4hh Hr0w== X-Gm-Message-State: ALyK8tKu8s6KHyFJLLC3OzS6KPla92J8WJdCK4LIOlvzRVKsO0k56ULfeaKAlWN0dmc9b4CTyHkm3OQ0nfDNWw== MIME-Version: 1.0 X-Received: by 10.25.33.133 with SMTP id h127mr452513lfh.82.1465559819691; Fri, 10 Jun 2016 04:56:59 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Fri, 10 Jun 2016 04:56:59 -0700 (PDT) Received: by 10.25.21.30 with HTTP; Fri, 10 Jun 2016 04:56:59 -0700 (PDT) In-Reply-To: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> Date: Fri, 10 Jun 2016 13:56:59 +0200 X-Google-Sender-Auth: HnNggIcxtc5yaenZKJPBn2a-tlQ Message-ID: From: Robert Raszuk To: Susan Hares Content-Type: multipart/alternative; boundary=001a113f1888732f9b0534eb3cac Archived-At: Cc: idr wg , draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "John G. Scudder" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 11:57:04 -0000 --001a113f1888732f9b0534eb3cac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Responding to #3 how authors envision deployment via IX where I peer single session to RS while on the other side I may have various types of peers ? I do not think BGP OPEN MSG is the right place for this. Thx R. On Jun 6, 2016 12:40, "Susan Hares" wrote: This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy. You can find the draft at: https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/. In your comments on adopting this draft, please indicate: 1) =E2=80=9CSupport=E2=80=9D or =E2=80=9Cno Support=E2=80=9D 2) Do you feel this is a way to prevent route leaks? 3) Are there any deployment issues that might prevent deployment of this enhancement to BGP Open? 4) Does this interact with draft-ietf-idr-route-leak-detection-mitigation? Sue Hares and John Scudder _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --001a113f1888732f9b0534eb3cac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Responding to #3 how authors envision deployment via IX wher= e I peer single session to RS while on the other side I may have various ty= pes of peers ?

I do not think BGP OPEN MSG is the right place for this.

Thx
R.

On Jun 6, 2016 12:40, "Susan Hares" &l= t;shares@ndzh.com> wrote:

This begins a 2 week WG Adopt= ion call for draft-ymbk-idr-bgp-open-policy. You can find the draft at: =

https://datatrack= er.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/.

=C2=A0

In your co= mments on adopting this draft, please indicate:

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =E2=80=9CSupport=E2=80=9D or =E2=80=9Cno Support=E2=80=9D =

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do you fee= l this is a way to prevent route leaks?

3= )=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Are there any deployment issues that migh= t prevent deployment of this enhancement to BGP Open?

= 4)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Does this interact with dr= aft-ietf-idr-route-leak-detection-mitigation?

=C2=A0

Sue Hares and Jo= hn Scudder

=C2=A0


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--001a113f1888732f9b0534eb3cac-- From nobody Fri Jun 10 05:30:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE0612D992 for ; Fri, 10 Jun 2016 05:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCXq_Bb_-F_5 for ; Fri, 10 Jun 2016 05:30:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DFD212D18E for ; Fri, 10 Jun 2016 05:30:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bBLa6-0005q8-3M; Fri, 10 Jun 2016 12:30:34 +0000 Date: Fri, 10 Jun 2016 05:30:33 -0700 Message-ID: From: Randy Bush To: Job Snijders In-Reply-To: <20160610094324.GH2524@Vurt.local> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160609163225.GC2524@Vurt.local> <20160610094324.GH2524@Vurt.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr@ietf.org, "John G. Scudder" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 12:30:37 -0000 > I won't share the company names involved, but on multiple occasions, > my employer has engaged in providing transit between two peering > partners. actually, the first time your company did this, publicly documented on nanog, was when asp and i patched the war between psi and abovenet. i like that record because it allows me to do as you are trying, to say that there are more things in heaven and earth, Horatio. but, bottom line, what you are saying is that, if you used this feature at he same time you were intentionally violating the no transit between peers policy, it would flag it as an error. this is a feature, not a bug; it is what it is *supposed* to do. if you want to violate valley free or no transit between peers, you probably do not want to enable this capability. randy From nobody Fri Jun 10 06:06:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6606E12D53B for ; Fri, 10 Jun 2016 06:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lddK8_FPhUM for ; Fri, 10 Jun 2016 06:06:45 -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 ED0D412B012 for ; Fri, 10 Jun 2016 06:06:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLS24657; Fri, 10 Jun 2016 13:06:41 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 10 Jun 2016 14:06:38 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Fri, 10 Jun 2016 06:06:32 -0700 From: Lucy yong To: "stephane.litkowski@orange.com" , "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt Thread-Index: AQHRwYlWKLZD+NLIGEG6YM0mvKsgaJ/fj6NAgAA+7fCAAp8FAIAAPKPA Date: Fri, 10 Jun 2016 13:06:31 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57296F83@dfweml501-mbb> References: <20160608132609.19947.65371.idtracker@ietfa.amsl.com> <2211_1465392560_57581DB0_2211_5567_1_9E32478DFA9976438E7A22F69B08FF921BC4661E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D57296547@dfweml501-mbb> <3789_1465550608_575A8710_3789_7942_1_9E32478DFA9976438E7A22F69B08FF921BC4E487@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <3789_1465550608_575A8710_3789_7942_1_9E32478DFA9976438E7A22F69B08FF921BC4E487@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.234] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D57296F83dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.575ABB62.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 258572945eaac000cc13e8851be4c04a Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 13:06:50 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D57296F83dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephane, Pls see inline below. From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Friday, June 10, 2016 4:23 AM To: Lucy yong; idr@ietf.org Subject: RE: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt Hi Lucy, Pls find some comments inline. Thanks, Stephane From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Wednesday, June 08, 2016 21:21 To: LITKOWSKI Stephane OBS/OINIS; idr@ietf.org Subject: RE: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt Hi Stephane, et al, I read this draft and have some comments. * I like this approach to treat interfaceset as FS scope, not as ma= tching, nor as action. * Instead of using group-identifier to express interfaceset in the = EC, IMO: it is better to use interface type to identify the interfaceset an= d have IANA registry for each interface type. This will make interworking/a= utomation easier. Any thought on that? [SLI] Bruno Decraene raised on similar comment at the beginning of the draf= t , proposing some "well-known" interface-set. There was not a strong suppo= rt for it considering that having a group-id will enable any scenario. Now = regarding your proposal of having a specific interface type defined, I thin= k it's really restrictive. I'm not opposite that someone creates new scope = for specific interface types later but I would like to keep the generic app= roach in this draft. Creating well known group-ids may also be reconsidered= . [Lucy] From interworking perspective and consistent behavior, it is necessa= ry for all vendors to have common understanding about interface types. If = someone creates a new interface type later, that will need to be supported= by vendors so it is better to be standardized and have code point in a IAN= A registry. * IMO: Content in Sn 6 is very useful, however it does not belong t= o this draft. These rules for processing permanent configured and BGP FS ap= ply to all BGP FS. It should be documented in one draft and apply to all BG= P FS drafts. FS ACL is just one type of BGP FS, there are others as well. T= he rules should be described in general term. I agree that there may be more iteractions to describe like Policy Based ro= uting. But I think that this draft is a good place to describe it. The base= flowspec does not precise where the rules must be applied, so it becomes u= p to implementation to place the rule where it best fits and manage interac= tion with other mechanism. Now with this draft, we know that the rules will be pushed on a pr interfac= e basis interacting with well known interface features. We cannot describe = all for sure. I will try in the next revision to be more generic and still = giving examples. [Lucy] IMO: These rules should apply to BGP FS whether interfaceset scope i= s used or not. If you want to keep them in this draft, need to be clarify t= hat. In addition, good to describe them in term of processing rules for per= manent configured and BGP FS. * I am not clear what first sentence means in Sn 7. Does it say tha= t some interfaces may not be able to support the rules? Pls explain. [SLI] That's a question of scaling. With the base FS, the rule is applied i= n a single place, while here it may be "duplicated" in the forwarding plane= and implementations will need to look at optimizations to prevent to creat= e unnecessary states in the forwarding plane. I will see how to reword it. [Lucy] Thx. Thanks, Lucy -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: Wednesday, June 08, 2016 8:29 AM To: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt Hi IDR, This is a new version of the interface-set flowspec extension. As there was some misinterpretation of what the interface-set is (it is not= a match (as not part of NLRI) and it is not an action), we defined the not= ion of traffic filtering scope. Interface-set would be the first traffic fi= ltering scope defined, and nothing prevents to create new ones if required. Best Regards, Stephane -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Wednesday, June 08, 2016 15:26 To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Applying BGP flowspec rules on a specific interfa= ce set Authors : Stephane Litkowski Adam Simpson Keyur Patel Jeff Haas Filename : draft-ietf-idr-flowspec-interfaceset-01.txt Pages : 14 Date : 2016-06-08 Abstract: BGP Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. The primary application of this extension is DDoS mitigation where the flowspec rules are applied in most cases to all peering routers of the network. This document will present another use case of BGP Flow-spec where flow specifications are used to maintain some access control lists at network boundary. BGP Flowspec is a very efficient distributing machinery that can help in saving OPEX while deploying/updating ACLs. This new application requires flow specification rules to be applied only on a specific subset of interfaces and in a specific direction. The current specification of BGP Flow-spec ([RFC5575]) introduces the notion of flow specification (which describes the matching criterion) and traffic filtering actions. The flow specification is encoded as part of the NLRI while the traffic filtering actions are encoded as extended communities. The combination of a flow specification and one or more actions is known as a flow specification rule. [RFC5575] does not detail where the flow specification rules need to be applied. Besides the flow specification and traffic filtering actions, this document introduces the notion of traffic filtering scope in order to drive where a particular rule must be applied. In particular, this document introduces the "interface-set" traffic filtering scope that could be used in parallel of traffic filtering actions (marking, rate-limiting ...). The purpose of this extension is to inform remote routers about groups of interfaces where the rule must be applied. This extension can also be used in a DDoS mitigation context where a provider wants to apply the filtering only on specific peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-flowspec-interfaceset-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ 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_2691CE0099834E4A9C5044EEC662BB9D57296F83dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephane,

 

Pls see inline belo= w.

 

From: stephane= .litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Friday, June 10, 2016 4:23 AM
To: Lucy yong; idr@ietf.org
Subject: RE: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-= 01.txt

 

Hi Lucy,

 

Pls find some comments= inline.

 

Thanks,

 

Stephane

 

From: Lucy yon= g [mailto:lucy.yong@huawei.com]
Sent: Wednesday, June 08, 2016 21:21
To: LITKOWSKI Stephane OBS/OINIS; id= r@ietf.org
Subject: RE: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-= 01.txt

 

Hi Stephane, et al,

 

I read this draft and have some comments.

·         I like this approach to treat interfaceset a= s FS scope, not as matching, nor as action.

·         Instead of using group-identifier to express= interfaceset in the EC, IMO: it is better to use interface type to identif= y the interfaceset and have IANA registry for each interface type. This wil= l make interworking/automation easier. Any thought on that?

[SLI] Bruno Decraene r= aised on similar comment at the beginning of the draft , proposing some = 220;well-known” interface-set. There was not a strong support for it considering that having a group-id will enable any scenario. Now re= garding your proposal of having a specific interface type defined, I think = it’s really restrictive. I’m not opposite that someone creates = new scope for specific interface types later but I would like to keep the generic approach in this draft. Creating well= known group-ids may also be reconsidered.

[Lucy] From inte= rworking perspective and consistent behavior, it is necessary for all vendo= rs to have  common understanding about interface types. If someone creates a new  interface type later, that will need to be = supported by vendors so it is better to be standardized and have code point= in a IANA registry.

 

·         IMO: Content in Sn 6 is very useful, however= it does not belong to this draft. These rules for processing permanent con= figured and BGP FS apply to all BGP FS. It should be documented in one draf= t and apply to all BGP FS drafts. FS ACL is just one type of BGP FS, there are others as well. The rules sho= uld be described in general term.

I agree that there may= be more iteractions to describe like Policy Based routing. But I think tha= t this draft is a good place to describe it. The base flowspec does not precise where the rules must be applied, so it becomes up to impl= ementation to place the rule where it best fits and manage interaction with= other mechanism.

Now with this draft, w= e know that the rules will be pushed on a pr interface basis interacting wi= th well known interface features. We cannot describe all for sure. I will try in the next revision to be more generic and still giv= ing examples.

[Lucy] IMO: Thes= e rules should apply to BGP FS whether interfaceset scope is used or not. I= f you want to keep them in this draft, need to be clarify that. In addition, good to describe them in term of processing rules for p= ermanent configured and BGP FS.

 

 

·         I am not clear what first sentence means in = Sn 7. Does it say that some interfaces may not be able to support the rules= ? Pls explain.

[SLI] That’s = a question of scaling. With the base FS, the rule is applied in a single pl= ace, while here it may be “duplicated” in the forwarding plane = and implementations will need to look at optimizations to prevent to create unnecessary states in the forwarding plane. I will se= e how to reword it.

[Lucy] Thx.

 

 

Thanks,

Lucy

 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.= org] On Behalf Of stephane.litkowski@orange.= com
Sent: Wednesday, June 08, 2016 8:29 AM
To: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt<= o:p>

 

Hi IDR,

 

This is a new version of the interface-set flowsp= ec extension.

 

As there was some misinterpretation of what the i= nterface-set is (it is not a match (as not part of NLRI) and it is not an a= ction), we defined the notion of traffic filtering scope. Interface-set wou= ld be the first traffic filtering scope defined, and nothing prevents to create new ones if required.

 

Best Regards,

 

Stephane

 

 

-----Original Message-----

From: Idr [mailto:idr-bounces@= ietf.org] On Behalf Of internet-drafts@ietf.org

Sent: Wednesday, June 08, 2016 15:26

To: i-d-announce@ietf.org

Cc: idr@ietf.org

Subject: [Idr] I-D Action: draft-ietf-idr-flowspe= c-interfaceset-01.txt

 

 

A New Internet-Draft is available from the on-lin= e Internet-Drafts directories.

This draft is a work item of the Inter-Domain Rou= ting of the IETF.

 

        Title&= nbsp;          : Applying BGP = flowspec rules on a specific interface set

        Author= s         : Stephane Litkowski=

        &= nbsp;           &nbs= p;     Adam Simpson

        &= nbsp;           &nbs= p;     Keyur Patel

        &= nbsp;           &nbs= p;     Jeff Haas

      Filename &nbs= p;      : draft-ietf-idr-flowspec-interfaceset-01.= txt

      Pages  &= nbsp;        : 14

      Date  &n= bsp;         : 2016-06-08

 

Abstract:

   BGP Flow-spec is an extension to BGP= that allows for the

   dissemination of traffic flow specif= ication rules.  The primary

   application of this extension is DDo= S mitigation where the flowspec

   rules are applied in most cases to a= ll peering routers of the

   network.

 

   This document will present another u= se case of BGP Flow-spec where

   flow specifications are used to main= tain some access control lists at

   network boundary.  BGP Flowspec= is a very efficient distributing

   machinery that can help in saving OP= EX while deploying/updating ACLs.

   This new application requires flow s= pecification rules to be applied

   only on a specific subset of interfa= ces and in a specific direction.

 

   The current specification of BGP Flo= w-spec ([RFC5575]) introduces the

   notion of flow specification (which = describes the matching criterion)

   and traffic filtering actions. = The flow specification is encoded as

   part of the NLRI while the traffic f= iltering actions are encoded as

   extended communities.  The comb= ination of a flow specification and

   one or more actions is known as a fl= ow specification rule.  [RFC5575]

   does not detail where the flow speci= fication rules need to be

   applied.

 

   Besides the flow specification and t= raffic filtering actions, this

   document introduces the notion of tr= affic filtering scope in order to

   drive where a particular rule must b= e applied.  In particular, this

   document introduces the "interf= ace-set" traffic filtering scope that

   could be used in parallel of traffic= filtering actions (marking,

   rate-limiting ...).  The purpos= e of this extension is to inform

   remote routers about groups of inter= faces where the rule must be

   applied.

 

   This extension can also be used in a= DDoS mitigation context where a

   provider wants to apply the filterin= g only on specific peers.

 

 

 

The IETF datatracker status page for this draft i= s:

https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-inter= faceset/

 

There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-= 01

 

A diff from the previous version is available at:=

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-flowsp= ec-interfaceset-01

 

 

Please note that it may take a couple of minutes = from the time of submission until the htmlized version and diff are availab= le at tools.ietf.org.

 

Internet-Drafts are also available by anonymous F= TP at:

<= span style=3D"color:windowtext;text-decoration:none">ftp://ftp.ietf.org/int= ernet-drafts/

 

_______________________________________________

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 et= re diffuses, exploites ou copies sans autorisation. Si vous avez recu ce me= ssage par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant susceptibles d'alteration, Orange decline toute responsa= bilite si ce message a ete altere, deforme ou falsifie. Merci.

 

This message and its attachments may contain conf= idential or privileged information that may be protected by law; they shoul= d 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 fo= r 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 con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_2691CE0099834E4A9C5044EEC662BB9D57296F83dfweml501mbb_-- From nobody Fri Jun 10 08:24:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B9E12D7BF for ; Fri, 10 Jun 2016 08:24:03 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=highloadlab-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAYeq0miOGiA for ; Fri, 10 Jun 2016 08:24:00 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C6512D7C3 for ; Fri, 10 Jun 2016 08:23:59 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id e5so12896947ith.0 for ; Fri, 10 Jun 2016 08:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highloadlab-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=02X9YQwSjef0R99/TzPN1TC3GZaRVG6RtKP5Z/H29X0=; b=hokQZVetk4Jq0O5TWG4XFq3TcrXcp2riqGBhbw5Gx+TSGTKsHT6CZ5/FNICCfBfuGr xx3WzRB+XW1Oecwn+JXlXkAVz+piwwkpNO3PJrl1ycoPiXd3hpM6ECzr4hhhqWkszTxC RboCYyAnxuoMceQhRH0zGTklxZYc3wU1sZagrU/jYthFQtTLmwWgR03bcGNZi8B8qRYh hV1cN/jsOsQvSXnWZ64SZEJvPXGP/K12VCs7lz0OYVzksbMSBhTAljQ6qm2S+A7UJXJ3 tXAMrZrECA78n4q75yRBSOp+0J2PUyaWFoFE+yV4PGuP8evPvRt/v4rdxYNvAEyy59hX xv1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=02X9YQwSjef0R99/TzPN1TC3GZaRVG6RtKP5Z/H29X0=; b=GjnGT/ksaG6mYyjKcmyebZFW/i5r7bXpy5C3x1i7L2kgA6t2zdima0QiCjKHzUKD++ uE/gOWYcb7Hb01MrKKxlfTq5XQ3cjIPhzqGE38zRFe0DUA88B0fYgRZnn1O1KURePvM7 tanzvUBimqZMAy75Zis/I/ixfrPC75SdkMTQHXaQ+a89Ssl1gWsFpVoreBhzHfNx+Aby 9tXiMTnEX2PdOMXF4MT5WkChf6URBSaygDhNJqMVJi3SW2A0Xi44ZNSKOFYFZjJ0CQ0v 162glfqV06ZoeLBYYEWNq8Wu3XxKTixgmXl6y90J6pWfmB9PFz38ZX9XziyEogHENv9t 36RA== X-Gm-Message-State: ALyK8tKndioQ6EPhCOiJUYww/L+SfOM9NjRzoCF0aslK+tBDtoW2paCnuP+NUR9LYQpF/7rNCFIMr0/5f6SHrw== X-Received: by 10.36.104.2 with SMTP id v2mr33036905itb.64.1465572239036; Fri, 10 Jun 2016 08:23:59 -0700 (PDT) MIME-Version: 1.0 Sender: aa@highloadlab.com Received: by 10.64.146.129 with HTTP; Fri, 10 Jun 2016 08:23:57 -0700 (PDT) X-Originating-IP: [176.110.121.30] In-Reply-To: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> From: Alexander Azimov Date: Fri, 10 Jun 2016 18:23:57 +0300 X-Google-Sender-Auth: HeteZxR9JgDX8KpIYq7HDK4-D8w Message-ID: To: Robert Raszuk Content-Type: multipart/alternative; boundary=001a11449c06b386620534ee2019 Archived-At: Cc: idr wg , draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "John G. Scudder" , Susan Hares Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 15:24:04 -0000 --001a11449c06b386620534ee2019 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Robert, Thank you for comment. In spite of your concerns RS is a perfect place to deploy roles: RS does not provide IP-transit (if there are no leaks!) but it *provides* local connectivity. So, RS is provider for all its neighbors. 2016-06-10 14:56 GMT+03:00 Robert Raszuk : > Responding to #3 how authors envision deployment via IX where I peer > single session to RS while on the other side I may have various types of > peers ? > > I do not think BGP OPEN MSG is the right place for this. > > Thx > R. > On Jun 6, 2016 12:40, "Susan Hares" wrote: > > This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy. > You can find the draft at: > > https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/. > > > > In your comments on adopting this draft, please indicate: > > > > 1) =E2=80=9CSupport=E2=80=9D or =E2=80=9Cno Support=E2=80=9D > > 2) Do you feel this is a way to prevent route leaks? > > 3) Are there any deployment issues that might prevent deployment of > this enhancement to BGP Open? > > 4) Does this interact with > draft-ietf-idr-route-leak-detection-mitigation? > > > > Sue Hares and John Scudder > > > > _______________________________________________ > 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 > > --=20 | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@qrator.net | visit: www.qrator.net --001a11449c06b386620534ee2019 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Robert,

Thank you for comment.

In spite of your concerns RS is a perfect place to de= ploy roles: RS does not provide IP-transit (if there are no leaks!) but it = provides local connectivity. So, RS is provider for all its neighbor= s.

201= 6-06-10 14:56 GMT+03:00 Robert Raszuk <robert@raszuk.net>:

Responding to #3 how author= s envision deployment via IX where I peer single session to RS while on the= other side I may have various types of peers ?

I do not think BGP OPEN MSG is the right place for this.

Thx
R.

On Jun 6, 2016 12:40, &qu= ot;Susan Hares" <shares@ndzh.com> wrote:

This begins a 2 week WG Adoption call for dr= aft-ymbk-idr-bgp-open-policy. You can find the draft at:

=

https://datatracker.ietf.org/doc= /draft-ymbk-idr-bgp-open-policy/.

=C2=A0

In your comments on adopt= ing this draft, please indicate:

<= u>=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =E2=80=9CSupport=E2=80=9D or =E2=80=9Cno Support=E2=80=9D

2)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do you feel this is a w= ay to prevent route leaks?

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Are there any deployment issues that might prevent dep= loyment of this enhancement to BGP Open?

= 4)=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Does this interact with draft-ietf-idr-ro= ute-leak-detection-mitigation?

= =C2=A0

Sue Hares and John Scudder <= /u>

=C2=A0

____________________________________________= ___
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




--
=
| Alexander Azimov =C2=A0| HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto:=C2= =A0aa@qrator.net
| visit:=C2=A0www.qrator.net
--001a11449c06b386620534ee2019-- From nobody Fri Jun 10 08:35:34 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3FE12D66E; Fri, 10 Jun 2016 08:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAtTFtoDmEM1; Fri, 10 Jun 2016 08:35:31 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D0D12D672; Fri, 10 Jun 2016 08:35:31 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id q132so10719667lfe.3; Fri, 10 Jun 2016 08:35: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:from:date:message-id :subject:to:cc; bh=tK4wwkaJJQLlo/Qmo9IvkYXlDSxUFlhoEG9XkYXGvhA=; b=bx3Oln4oTjJtU5oi5Iqd+uFl4m/O894vhxHp0XIQmw5C+KArAvFd1zLn7hPCduT2q2 HKMKH+vf6R4apZv/Z3riQZtI87kp0sKBff8w+PYerguGZDtm++26aymzt4xWiD/6/3Gx pbRKLt2ykQrkP7SWAcooi27FLt2NoNBzGtElwqHZBDbGy9UJLauWAwbhkWA4v/M6Uczs t0A6g10h0FtSjeZeYpIzIG8bBhf7/DkI82CW2xja+IW9oEu59WYrpYAbSk+fX4fbqjFB AJU9WSj2Vc1scAJ1mugw4fG2aGdUgRiQdWWIOymGc89aSQOYh8r4hJYp2EuRAoyBy4g9 nyaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tK4wwkaJJQLlo/Qmo9IvkYXlDSxUFlhoEG9XkYXGvhA=; b=E6OSPSy/Fhr4lbVKu85PxJ3aVzncOv7gw+mVpqy3a7eDGEI5O1pBbR/dzp3WOFRc6Y GSY1ojIIQChjVYb/+KQRk9I7dYJN8vDDgn575iH5GZMKvI39IBWM4RCGTGQzMREgo125 b+7dQgy0/uS/maGZ0AhCaszOQ7zbiKB4xkYRUXg33OA2q6EjF6XIKpFQYaNXLmS8A+qY 01uVD+L9gz+3cDclgFwvuE5a4jILz5MHt6nDXIY1Wpd22LUoDjlvqZdaglO2DdEE8wIk WMWhtam70Ia2Omw5XsTDECEnRrHpuw7k3nbIcgPGhyGv+CrewV2NtbsIDECO98UqVUY3 C+ew== X-Gm-Message-State: ALyK8tKK33h49t8/+MazGIm21ACNyfgPa0h2r18gJkiIIK+Z+Q6EI6Oh3kW9CXnGhIgwZ9aLG6JOtDrkK3eiow== X-Received: by 10.25.87.83 with SMTP id l80mr699243lfb.4.1465572929268; Fri, 10 Jun 2016 08:35:29 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Fri, 10 Jun 2016 08:35:28 -0700 (PDT) In-Reply-To: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> From: Robert Raszuk Date: Fri, 10 Jun 2016 17:35:28 +0200 X-Google-Sender-Auth: woKstAan5KqA0c7rd-6Ak-n-v4s Message-ID: To: Alexander Azimov Content-Type: multipart/alternative; boundary=001a11404778d771a80534ee4978 Archived-At: Cc: idr wg , draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "John G. Scudder" , Susan Hares Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 15:35:34 -0000 --001a11404778d771a80534ee4978 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You mean other then FT's OpenTransit ? http://vision.opentransit.net/docs/peering_policy/ Well in general you are correct that in IX transit peering is established over direct EBGP sessions, however there is more and more exceptions and while RS policies get richer over single session various types of customers get connected. On Fri, Jun 10, 2016 at 5:23 PM, Alexander Azimov wrote: > Dear Robert, > > Thank you for comment. > > In spite of your concerns RS is a perfect place to deploy roles: RS does > not provide IP-transit (if there are no leaks!) but it *provides* local > connectivity. So, RS is provider for all its neighbors. > > 2016-06-10 14:56 GMT+03:00 Robert Raszuk : > >> Responding to #3 how authors envision deployment via IX where I peer >> single session to RS while on the other side I may have various types of >> peers ? >> >> I do not think BGP OPEN MSG is the right place for this. >> >> Thx >> R. >> On Jun 6, 2016 12:40, "Susan Hares" wrote: >> >> This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy= . >> You can find the draft at: >> >> https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/. >> >> >> >> In your comments on adopting this draft, please indicate: >> >> >> >> 1) =E2=80=9CSupport=E2=80=9D or =E2=80=9Cno Support=E2=80=9D >> >> 2) Do you feel this is a way to prevent route leaks? >> >> 3) Are there any deployment issues that might prevent deployment of >> this enhancement to BGP Open? >> >> 4) Does this interact with >> draft-ietf-idr-route-leak-detection-mitigation? >> >> >> >> Sue Hares and John Scudder >> >> >> >> _______________________________________________ >> 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 >> >> > > > -- > | Alexander Azimov | HLL l QRATOR > | tel.: +7 499 241 81 92 > | mob.: +7 915 360 08 86 > | skype: mitradir > | mailto: aa@qrator.net > | visit: www.qrator.net > --001a11404778d771a80534ee4978 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

You mean o= ther then FT's OpenTransit ?=C2=A0

http:= //vision.opentransit.net/docs/peering_policy/

Well in general you are correct that in IX transit peering is establi= shed over direct EBGP sessions, however there is more and more exceptions a= nd while RS policies get richer over single session various types of custom= ers get connected.=C2=A0

On Fri, Jun 10, 2016 at 5:23 PM, Alexander Azimov <aa@qrator.net<= /a>> wrote:
De= ar Robert,

Thank you for comment.

In spite of your concerns RS is a perfect place to deploy roles: RS does= not provide IP-transit (if there are no leaks!) but it provides loc= al connectivity. So, RS is provider for all its neighbors.

2016-06-10 14:56 GMT+03:00 Robert Raszuk <robert@raszuk.net>:

Responding to #3 how au= thors envision deployment via IX where I peer single session to RS while on= the other side I may have various types of peers ?

I do not think BGP OPEN MSG is the right place for this.

Thx
R.

On Jun 6, 2016 12:40, "Susan Hare= s" <shares@ndz= h.com> wrote:

This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-pol= icy. You can find the draft at:

https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-= policy/.

=C2=A0

In your comments on adopting this draft, please in= dicate:

=C2=A0

1)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9CSupport=E2=80=9D = or =E2=80=9Cno Support=E2=80=9D

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Do you feel this is a way to prevent route leaks? =

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Are the= re any deployment issues that might prevent deployment of this enhancement = to BGP Open?

4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= u>Does this interact with draft-ietf-idr-route-leak-detection-mitigatio= n?

=C2=A0

Sue Hares and John Scudder

=C2=A0


________= _______________________________________
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




--
| Alexander Azimov =C2=A0| HLL l QRATOR=
| skype: mitradir
| mailto:=C2=A0aa@qrator.net
| visit:=C2= =A0www.qrator.net<= /font>

Hi Lucy,

 

Pls find some comments= inline.

 

Thanks,

 

Stephane

 

From: Lucy yon= g [mailto:lucy.yong@huawei.com]
Sent: Wednesday, June 08, 2016 21:21
To: LITKOWSKI Stephane OBS/OINIS; idr@ietf.org
Subject: RE: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-= 01.txt

 

Hi Stephane, et al,

 

I read this draft and have some comments.

·         I like this approach to treat interfaceset a= s FS scope, not as matching, nor as action.

·         Instead of using group-identifier to express= interfaceset in the EC, IMO: it is better to use interface type to identif= y the interfaceset and have IANA registry for each interface type. This wil= l make interworking/automation easier. Any thought on that?

[SLI] Bruno Decraene r= aised on similar comment at the beginning of the draft , proposing some = 220;well-known” interface-set. There was not a strong support for it considering that having a group-id will enable any scenario. Now re= garding your proposal of having a specific interface type defined, I think = it’s really restrictive. I’m not opposite that someone creates = new scope for specific interface types later but I would like to keep the generic approach in this draft. Creating well= known group-ids may also be reconsidered.

 

·         IMO: Content in Sn 6 is very useful, however= it does not belong to this draft. These rules for processing permanent con= figured and BGP FS apply to all BGP FS. It should be documented in one draf= t and apply to all BGP FS drafts. FS ACL is just one type of BGP FS, there are others as well. The rules sho= uld be described in general term.

I agree that there may= be more iteractions to describe like Policy Based routing. But I think tha= t this draft is a good place to describe it. The base flowspec does not precise where the rules must be applied, so it becomes up to impl= ementation to place the rule where it best fits and manage interaction with= other mechanism.

Now with this draft, w= e know that the rules will be pushed on a pr interface basis interacting wi= th well known interface features. We cannot describe all for sure. I will try in the next revision to be more generic and still giv= ing examples.

 

 

·         I am not clear what first sentence means in = Sn 7. Does it say that some interfaces may not be able to support the rules= ? Pls explain.

[SLI] That’s = a question of scaling. With the base FS, the rule is applied in a single pl= ace, while here it may be “duplicated” in the forwarding plane = and implementations will need to look at optimizations to prevent to create unnecessary states in the forwarding plane. I will se= e how to reword it.

 

 

Thanks,

Lucy

 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com
Sent: Wednesday, June 08, 2016 8:29 AM
To: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt<= o:p>

 

Hi IDR,

 

This is a new version of the interface-set flowsp= ec extension.

 

As there was some misinterpretation of what the i= nterface-set is (it is not a match (as not part of NLRI) and it is not an a= ction), we defined the notion of traffic filtering scope. Interface-set wou= ld be the first traffic filtering scope defined, and nothing prevents to create new ones if required.

 

Best Regards,

 

Stephane

 

 

-----Original Message-----

From: Idr [mailto:idr-bounces@= ietf.org] On Behalf Of internet-drafts@ietf.org

Sent: Wednesday, June 08, 2016 15:26

To: i-d-announce@ietf.org

Cc: idr@ietf.org

Subject: [Idr] I-D Action: draft-ietf-idr-flowspe= c-interfaceset-01.txt

 

 

A New Internet-Draft is available from the on-lin= e Internet-Drafts directories.

This draft is a work item of the Inter-Domain Rou= ting of the IETF.

 

        Title&= nbsp;          : Applying BGP = flowspec rules on a specific interface set

        Author= s         : Stephane Litkowski=

        &= nbsp;           &nbs= p;     Adam Simpson

        &= nbsp;           &nbs= p;     Keyur Patel

        &= nbsp;           &nbs= p;     Jeff Haas

      Filename &nbs= p;      : draft-ietf-idr-flowspec-interfaceset-01.= txt

      Pages  &= nbsp;        : 14

      Date  &n= bsp;         : 2016-06-08

 

Abstract:

   BGP Flow-spec is an extension to BGP= that allows for the

   dissemination of traffic flow specif= ication rules.  The primary

   application of this extension is DDo= S mitigation where the flowspec

   rules are applied in most cases to a= ll peering routers of the

   network.

 

   This document will present another u= se case of BGP Flow-spec where

   flow specifications are used to main= tain some access control lists at

   network boundary.  BGP Flowspec= is a very efficient distributing

   machinery that can help in saving OP= EX while deploying/updating ACLs.

   This new application requires flow s= pecification rules to be applied

   only on a specific subset of interfa= ces and in a specific direction.

 

   The current specification of BGP Flo= w-spec ([RFC5575]) introduces the

   notion of flow specification (which = describes the matching criterion)

   and traffic filtering actions. = The flow specification is encoded as

   part of the NLRI while the traffic f= iltering actions are encoded as

   extended communities.  The comb= ination of a flow specification and

   one or more actions is known as a fl= ow specification rule.  [RFC5575]

   does not detail where the flow speci= fication rules need to be

   applied.

 

   Besides the flow specification and t= raffic filtering actions, this

   document introduces the notion of tr= affic filtering scope in order to

   drive where a particular rule must b= e applied.  In particular, this

   document introduces the "interf= ace-set" traffic filtering scope that

   could be used in parallel of traffic= filtering actions (marking,

   rate-limiting ...).  The purpos= e of this extension is to inform

   remote routers about groups of inter= faces where the rule must be

   applied.

 

   This extension can also be used in a= DDoS mitigation context where a

   provider wants to apply the filterin= g only on specific peers.

 

 

 

The IETF datatracker status page for this draft i= s:

https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-inter= faceset/

 

There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-= 01

 

A diff from the previous version is available at:=

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-flowsp= ec-interfaceset-01

 

 

Please note that it may take a couple of minutes = from the time of submission until the htmlized version and diff are availab= le at tools.ietf.org.

 

Internet-Drafts are also available by anonymous F= TP at:

<= span style=3D"color:windowtext;text-decoration:none">ftp://ftp.ietf.org/int= ernet-drafts/

 

_______________________________________________

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 et= re diffuses, exploites ou copies sans autorisation. Si vous avez recu ce me= ssage par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant susceptibles d'alteration, Orange decline toute responsa= bilite si ce message a ete altere, deforme ou falsifie. Merci.

 

This message and its attachments may contain conf= idential or privileged information that may be protected by law; they shoul= d 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 fo= r messages that have been modified, changed or falsified.

Thank you.

 

_______________________________________________

Idr mailing list

Idr@ietf.org

https://www.ietf= .org/mailman/listinfo/idr

--001a11404778d771a80534ee4978-- From nobody Fri Jun 10 09:07:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE7912D745 for ; Fri, 10 Jun 2016 09:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmrlSMm5BTqT for ; Fri, 10 Jun 2016 09:07:01 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0103.outbound.protection.outlook.com [23.103.201.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBFA12D5CD for ; Fri, 10 Jun 2016 09:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mG6HU75Xrk/ktqEVSZE8nnQAsRdbFFN2kf4NPwy13UI=; b=hN98YEdLVJof765HNJ/uDjXyL1Nzhcuu3RrlBwaacMvC5dAJqkL9bQAzIpbn/O52y0nEiLDwMTugcSpOCiRx80qxqIWF2oT/Pw39eeBPN8tgoVrTU83UNbl/NNRX+vVc17nsAkrP+0svrEYxNNlEP4zUaGIBDKfdTag6/KQZ/rk= Received: from BL2PR09MB1123.namprd09.prod.outlook.com (10.167.102.151) by BL2PR09MB1122.namprd09.prod.outlook.com (10.167.102.150) with Microsoft SMTP Server (TLS) id 15.1.511.8; Fri, 10 Jun 2016 16:06:59 +0000 Received: from BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) by BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) with mapi id 15.01.0511.010; Fri, 10 Jun 2016 16:06:59 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "idr@ietf.org" Thread-Topic: route leak discussion on NANOG list Thread-Index: AdHDLxD13Vk9r9Z3TjOgIw2j8ir/nA== Date: Fri, 10 Jun 2016 16:06:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: b09ec413-277d-45ea-212f-08d3914940fc x-microsoft-exchange-diagnostics: 1; BL2PR09MB1122; 5:9b2ghbRkljWWAckjc9dcRx/3J1wAneeCCCcTB6bvVuPkQHvL8uPcdvOQ+Fr892EQHfx9InWe5nukqDoHEN37IMYW8LgxENjyJvCX6j9zwyOtbm2qSj2HDm97axaSZrteXS46HvTEThhLzto6Ilu5ig==; 24:XtER+sOJ1U4uoSXhy9XVYtm+N829UQuikh0RdTcqS3Yq7KEOvRq+RgC3jNUU7O2uNw07KPuH8+Z//fgOf1LiJn//mPY32yPbx7SZZaMHD78=; 7:NcqWhOri2VZ0Mo5KvOB2bQvcj24eMJoYTekTUA0y7hX/NkvrIen0CKUQUwO7A/k6Q2KZaeLYwDnTIV8GjxVsQf1C/Mc6cSOa4dmfXBvYpH2IZxCZmdVe4k014GoOQTQJJ8YFkwxIBVR93ZFLna7g7bQ+TATRcIMCLxfhWfcKuPI71FjakuaSFfPWjIaX/TNObpwjlXmfnmGUEiSPbsPbKw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR09MB1122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BL2PR09MB1122; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB1122; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(5004730100002)(87936001)(76576001)(6116002)(9686002)(74316001)(101416001)(3846002)(97736004)(107886002)(450100001)(2501003)(8936002)(5008740100001)(105586002)(81166006)(5640700001)(68736007)(102836003)(586003)(8676002)(50986999)(33656002)(66066001)(122556002)(11100500001)(77096005)(2900100001)(2906002)(54356999)(229853001)(15975445007)(19580395003)(5002640100001)(99286002)(1730700003)(86362001)(106356001)(92566002)(81156014)(3660700001)(5003600100002)(2351001)(110136002)(3280700002)(10400500002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB1122; H:BL2PR09MB1123.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 16:06:59.4527 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB1122 Archived-At: Subject: [Idr] route leak discussion on NANOG list X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 16:07:04 -0000 Just fyi... Just in case some of us here do not often check the NANOG list, there is interesting discussion taking place about route leak prevention. You may check this post and the thread: http://mailman.nanog.org/pipermail/nanog/2016-June/086348.html=20 The inputs/insights shared on NANOG provide additional corroboration for=20 the common practice related to "intra-AS messaging for route leak preventio= n" that is outlined and recommended in Section 3.2 of [route-leak-detection-= mitigation-03]. https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-= 03#section-3.2=20 Sriram =20 =20 =20 From nobody Fri Jun 10 09:25:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3301012D62F; Fri, 10 Jun 2016 09:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7-VIMU1jlfD; Fri, 10 Jun 2016 09:25:25 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26F412D11C; Fri, 10 Jun 2016 09:25:24 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id m124so108752583wme.1; Fri, 10 Jun 2016 09:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:message-id:date:user-agent:mime-version; bh=eR5mbknVoiwzjz2vDyEuS/PS0UfMSAkxM0qVT2HLdSA=; b=Wf+aizAQK2utWohVyfJ+8t6Ge05IfTWOonBRkJ5rJUNvxU0dFAktsodQKYPwckVfMJ ubxTzMR5MbqCXOoqTcXMtbTxcqQBBkI7VAg5MB5j9vUUGYA7CD8g7HegnAfKQ//8rF99 KWpquEBewWyint1Ymhjrh60IHiqukAB5HIChbG767J5OVRKivZ70ysczeNBLDIMpoH6N yPRHwXV2Y5qSytLKZFp4CYfUXwFD7sGs56TYJUxRnPacIauMg+x8345YBy0XFW7vtL3q qHYfPQklejq5mBGmvdz+mo7us4Z46RnJ2uU7OFjiLRWEQ3K2wDFc9paGWH9z7vdLSsMH ct5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:cc:message-id:date:user-agent :mime-version; bh=eR5mbknVoiwzjz2vDyEuS/PS0UfMSAkxM0qVT2HLdSA=; b=F6UK8XBTodqUFmA5zMiykOUiabV3aSWDIo69W5njeeRwS8Y2Zf34IKhL5WcN1sFe4z omfzDjzRpIEQtoEvwNfm/TRvBud9GWQxVY0jjVIzbiuXCSVMCZYyeayyC3E08hj+Nlps mq0fGsA+OPswvQ4yHdh9LErorxJDQfGiY9CtsOnP4uEgxKxxADdKHtey+XHwAWBcFWz0 PCzPs9iKiKzbp0VhkAUCIEwZUTX39k/2v3Gv0GEV5ZQgIc0SBf362oTDGJpSjUGIGxbL wRRkcTi+i0Xbbg5HbvkUli3PWScZacnaVBdFeFcmOZSSRLnkUDWgLyTrOboIYSGVllTY KHjQ== X-Gm-Message-State: ALyK8tIAc9+bENF7TH7HD6uT44UI7PyaUpXdlezGiH2/Xv8PcPteTUCgotge+QvksCqjew== X-Received: by 10.28.43.129 with SMTP id r123mr18261284wmr.99.1465575923378; Fri, 10 Jun 2016 09:25:23 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id c4sm13068691wjb.38.2016.06.10.09.25.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 09:25:22 -0700 (PDT) From: Stewart Bryant To: draft-ietf-idr-te-pm-bgp@tools.ietf.org, idr-chairs@tools.ietf.org, idr@ietf.org, "rtg-dir@ietf.org" Message-ID: Date: Fri, 10 Jun 2016 17:25:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------EBA1CA6FB33181B83B68D603" Archived-At: Cc: Jonathan Hardwick Subject: [Idr] QA review of draft-ietf-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 16:25:26 -0000 This is a multi-part message in MIME format. --------------EBA1CA6FB33181B83B68D603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I was asked to do a QA review of draft-ietf-idr-te-pm-bgp-03 This is a short, simple, well written draft that integrates two existing technologies. It is ready to move onto its next stage. The only (minor) observation that I would make, is that the front page author list is longer than is normally acceptable by the IESG. Assuming that all the TLVs that are needed are included, the draft looks about finished. - Stewart --------------EBA1CA6FB33181B83B68D603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
I was asked to do a QA review of draft-ietf-idr-te-pm-bgp-03

This is a short, simple, well written draft that integrates two
existing technologies. 

It is ready to move onto its next stage.

The only (minor) observation that I would make, is that 
the front page author list is longer than is normally 
acceptable by the IESG. 

Assuming that all the TLVs that are needed are included, 
the draft looks about finished.

- Stewart
--------------EBA1CA6FB33181B83B68D603-- From nobody Fri Jun 10 09:33:31 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D149D12D845; Fri, 10 Jun 2016 09:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzQ6wzIpDtQ4; Fri, 10 Jun 2016 09:33:26 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 63AE712D820; Fri, 10 Jun 2016 09:33:26 -0700 (PDT) Received: by seele.lamehost.it (Postfix, from userid 33) id 1915274387; Fri, 10 Jun 2016 18:33:25 +0200 (CEST) To: Susan Hares X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 10 Jun 2016 18:33:25 +0200 From: Marco Marzetti In-Reply-To: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> Message-ID: X-Sender: marco@lamehost.it User-Agent: Roundcube Webmail/1.1.5 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 16:33:29 -0000 On 2016-06-06 18:40, Susan Hares wrote: Dear members, > This begins a 2 week WG Adoption call for > draft-ymbk-idr-bgp-open-policy. You can find the draft at: > > https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/. > > In your comments on adopting this draft, please indicate: > > 1) "Support" or "no Support" I do not support this draft > > 2) Do you feel this is a way to prevent route leaks? > Only in a perfect world. > 3) Are there any deployment issues that might prevent deployment This approach is too strict and can't cope with the different peering relationships that exist in the real world. (In other words: you can't bound your sales to these specs) > of this enhancement to BGP Open? > > 4) Does this interact with > draft-ietf-idr-route-leak-detection-mitigation? Partly. They try to address the same problem in very different ways. > > Sue Hares and John Scudder > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr Regards -- Marco From nobody Fri Jun 10 13:11:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5934312D8FE; Fri, 10 Jun 2016 13:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGRoc-DAqZ-a; Fri, 10 Jun 2016 13:10:59 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0116.outbound.protection.outlook.com [23.103.201.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA929128B44; Fri, 10 Jun 2016 13:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7V64++4imLuLyDfpuw1WlBcZG+JUyN60Gk4OkCUrWI0=; b=eKSheceXEVVxB/oBXxAasM187ItDqXUJA9ue1Bq34oxfuEDrcJEqXgZVH4ruK8/DTks/OLCGOIlktq75KJfogFe+w8DQstKCbuWJ5QSmnrV75sz1kxume9SjvCQhudE0YqlUV9Xl1+ZE0RkL4o+et7YPNG8ICwQoyruksJqi2eY= Received: from BL2PR09MB1123.namprd09.prod.outlook.com (10.167.102.151) by BL2PR09MB1122.namprd09.prod.outlook.com (10.167.102.150) with Microsoft SMTP Server (TLS) id 15.1.511.8; Fri, 10 Jun 2016 20:10:57 +0000 Received: from BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) by BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) with mapi id 15.01.0511.010; Fri, 10 Jun 2016 20:10:57 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "Osborne, Eric" , "idr@ietf.org" Thread-Topic: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) Thread-Index: AdHAEXYm+R0yr9NBRVeLkrezdS25EQAAqhngAD9OpKAAI2/qgABsbwKQ Date: Fri, 10 Jun 2016 20:10:57 +0000 Message-ID: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBE3F5E@USIDCWVEMBX03.corp.global.level3.com> <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEB0B5@USIDCWVEMBX03.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACD6BBEB0B5@USIDCWVEMBX03.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: 50a2c8c9-4e87-4069-1d95-08d3916b55bd x-microsoft-exchange-diagnostics: 1; BL2PR09MB1122; 5:7phTMWtXv43SkbqJeeOW3KSrXawhN1YbGxflRbldaBSsJZgNQMxsp1/VmzI3myvmiJs/36729XcCpR/EUa0Stq2/2ogwPewy6O+32PyO0nIMSjziyZj1mESWguBl+wifWUWk0uV0UQ7/l1Qq5bsiJQ==; 24:3SBlVUeRmqrXCA2T4zldgtrXI06TeUo9IyY7QZhqr/FiByd0YJrm6TDRtwMkqat+Pu7CtfaZqY9SK6zOn1RKB4omvpQY07D9TUq8WD3CIKs=; 7:gjg0gU1MAg8M8JG8LMUpBhLDG/kDTqeRhriiQJsPWoo6USQwWjWjY+g7ikspnO0fLy0XfxoXy81DVi9noS3jwvJ7fFOTqFREjkhn4xxYsJ0tOfvTCW21dYLfCAxKl5ijo6i5oC2Xk2WQC5dHKeTTbfklwzohVRnprbY3oqh7ZQSwBSUlfhBOMbeGDBlZvBTJOvN6XU8OrI1DgOBVhFYKWQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR09MB1122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BL2PR09MB1122; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB1122; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(52044002)(5423002)(189002)(54356999)(5002640100001)(76176999)(2906002)(2900100001)(15975445007)(561944003)(19580395003)(2950100001)(66066001)(33656002)(8676002)(50986999)(230783001)(11100500001)(77096005)(122556002)(3280700002)(10400500002)(189998001)(86362001)(106356001)(99286002)(5001770100001)(81156014)(5003600100002)(3660700001)(92566002)(97736004)(8936002)(2501003)(76576001)(87936001)(6116002)(5004730100002)(3846002)(101416001)(9686002)(74316001)(93886004)(102836003)(586003)(68736007)(105586002)(4326007)(81166006)(5008740100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB1122; H:BL2PR09MB1123.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 20:10:57.1607 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB1122 Archived-At: Cc: "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 20:11:02 -0000 >On the basis that detection-mitigation adds an attribute to=20 >every route (potentially per AS hop), whereas bgp-open=20 >keeps it to the neighbor relationship. =20 >One attribute per route * 600k routes * N hops seems like a lot=20 >if I can do the same thing with an open message. =20 Perhaps you have realized by now (based on the discussion on the list)=20 that the bgp-open draft also adds one OTC flag per route (or prefix). (Yep, on the wire there is one flag per route in the bgp-open draft also.) The SIDR, IDR, and GROW WGs have been working on it for=20 the past four years or so. See this post from 2012: https://www.ietf.org/mail-archive/web/sidr/current/msg04263.html =20 which summarized some of the requirements/design principles that were=20 discussed at the time in the WG meetings. Note that in particular it says: "the relationship has to be per prefix not per link, as prefixes with different business models are often sent over the same link." Several people in this thread also have tried to convey the above=20 design principle (i.e. RLP flag per route). Also see the discussion=20 in Section 5.3 of [route-leak-detection-mitigation]. =20 >I'm also concerned about how much I should trust the RLP bit=20 >from an AS a few hops away. Getting it from my directly connected=20 >neighbor is one thing, but if I can trust the source to do the right thing= =20 >with the RLP bit, why can't I just assume they won't leak=20 >YouTube-ish things to begin with? It is not the source, but the AS that is two hops from you -- it is important to know what they asserted in the update. (Keyur also highlighted this earlier in this thread.) Let us say AS X is a multi-homed customer of AS A and AS B: AS A ---> AS X ---> AS B (path of the update propagation) (assume that RLP flag per AS-hop is in use) AS X receives a route from its provider AS A,=20 and accidentally leaks it to provider AS B. AS X is not participating in RLP (does not set its own RLP flag), but it passes on the RLP flag set by of AS A to AS B because the RLP attribute is transitive. Then AS B is able to detect the leak... because AS B knows that the AS two hops away (AS A) asserted that it is sending the update to a customer (or a lateral peer) by setting its (i.e. AS A's) own RLP =3D 1. So there is need to know the RLP flag value set by the ASes=20 before your immediate neighbor. Your immediate neighbor (AS X) is=20 the leaker (the offender) -- in this instance.=20 So you do not want to rely on their RLP flag as much=20 (for detection of route leaks).=20 Also, you have knowledge about your peering relationship with them. =20 Down the road, the intention is to secure the RLP attribute so that no AS can change the RLP flag set by another AS in the path. In the above example, if AS X were maliciously trying to leak the route by changing the RLP flag of AS A, then it (AS X) would be prevented from doing so if there is cryptographic protection of the RLP attribute (e.g. by using the BGPsec protocol path signatures; see Section 3.1.2).=20 The end goal of this effort has been to provide=20 *secure* route leak protection (progressing via IDR-->SIDR). (I.e. provide a solution for both accidental and malicious route leaks.) Then it becomes necessary that each AS must set its RLP attribute=20 individually (RLP per AS-hop) and be secured. >I didn't see a discussion of scale anywhere in detection-mitigation. =20 >This seems like such an obvious scale difference to me that I worry that=20 >"hard to say that one proposal is more heavy weight than=20 >the other in principle" means I'm missing something. =20 >Feel free to enlighten me as needed. The BGP RLP attribute is sown in Section 3.1.1 of=20 [route-leak-detection-mitigation]. It consists of {ASN, RLP flag} tuples.=20 The parsing/processing load associated with the BGP RLP attribute=20 is not much different from processing the AS_PATH attribute. May be it is simpler than the AS_PATH processing where you have to=20 take into account the prepends, AS_SETs, CONFED_SETs, loop detection etc. If you want to consider another per-AS-hop thing to compare with .... We have done and reported elsewhere about BGPsec validation processing=20 which involves verifying one path signature per prefix and per AS-hop.=20 That has been implemented and does not seem daunting. Just some preliminary thoughts trying to address your concerns. Sriram From nobody Fri Jun 10 15:32:46 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7018B12D575; Fri, 10 Jun 2016 15:32:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610223242.18157.49537.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 15:32:42 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ix-bgp-route-server-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 22:32:42 -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 of the IETF. Title : Internet Exchange BGP Route Server Authors : Elisa Jasinska Nick Hilliard Robert Raszuk Niels Bakker Filename : draft-ietf-idr-ix-bgp-route-server-11.txt Pages : 11 Date : 2016-06-10 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 external 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: https://tools.ietf.org/html/draft-ietf-idr-ix-bgp-route-server-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ix-bgp-route-server-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 10 18:29:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA3A12D841 for ; Fri, 10 Jun 2016 18:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuZYm0YWP4si for ; Fri, 10 Jun 2016 18:29:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C23312D808 for ; Fri, 10 Jun 2016 18:29:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bBXjn-0000Vn-93; Sat, 11 Jun 2016 01:29:23 +0000 Date: Fri, 10 Jun 2016 18:29:22 -0700 Message-ID: From: Randy Bush To: Brian Dickson In-Reply-To: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160609163225.GC2524@Vurt.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IETF IDR Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 01:29:26 -0000 > I am not 100% certain, and don't speak for them, but I believe Hurricane > Electric (HE) often has peers who use them for both IPv4 peering and IPv6 > transit; I don't know, but would guess that at least some of those are over > a single MP-BGP session. in actual fact, they are not. confirmed by HE. randy From nobody Fri Jun 10 19:05:02 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108D012D59A for ; Fri, 10 Jun 2016 19:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8NvuKmjDFPr for ; Fri, 10 Jun 2016 19:05:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F288712D15F for ; Fri, 10 Jun 2016 19:04:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bBYIE-0000dM-7H; Sat, 11 Jun 2016 02:04:58 +0000 Date: Fri, 10 Jun 2016 19:04:57 -0700 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 02:05:01 -0000 >> In spite of your concerns RS is a perfect place to deploy roles: RS does >> not provide IP-transit (if there are no leaks!) but it *provides* local >> connectivity. So, RS is provider for all its neighbors. > You mean other then FT's OpenTransit ? welcome to the kinky internet, where every thinkable and unthinkable act is done; after all, it was invented in california. :) if you are planning something kinky, do not bring a straight friend to the party. that is, as i said to job, if you intend to violate valley free or peer-peer, do not run mechanisms designed to detect these as errors. perhaps we should design for the norm. with things this complex, we can always find corner cases. though i guess one can make a career out of finding them; it's a target rich environment. true skill is in finding the simple middle path. randy From nobody Fri Jun 10 19:30:18 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A1C12D871 for ; Fri, 10 Jun 2016 19:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF6n-OMGLXxG for ; Fri, 10 Jun 2016 19:30:15 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902AF12D5BE for ; Fri, 10 Jun 2016 19:30:14 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id j7so32115137lfg.1 for ; Fri, 10 Jun 2016 19:30:14 -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:from:date:message-id :subject:to:cc; bh=6Y63KaZyiHR3A0WdUj0JHoesXhqAtY6hoCZwKzIpff8=; b=oCh1onuNZQk9+5axu8ACAk35c0uHpIon4tBg7UBOljDdYA2vjonGPjEFVUSYB6JNGO TQY9I8fjn2Z92CpYxOeVGKVJ1d+GLocaGkYhNhSeZt3nEJVB8i8jwx7S0UlFO3rYYxkr tuqgoCobjHfj5s4EZlZq2+RkLrbjwzCdv/K30kHOVucHBxBlZRRje//6rrbY/OyDbHp7 RnLH2lPAP4tpyJrd0lWgABYrTNEuSzafzLFvcJcQV6/ynfSQjITNh0uIR79d8gbkt+NV xkTCXxYslrGLlTUBRlGe6xs6bWelTwSh14dAQmrEfhDjE2yqNBgmRkgdHZwQkB39IuRn GcCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6Y63KaZyiHR3A0WdUj0JHoesXhqAtY6hoCZwKzIpff8=; b=CovzRPepNh+waAYfgGwj38DdlXxHEIMrW5oWJnw85QYgSah0hdMV/sxNCnS50k5jUz ZH/nRnoZDL19TRh3R3NZb+zNPgmgX1hMs3Y60kOW4IAfSUmMMNO7yhjpetHHADjpJGOi vQEPw3OcmCUaAjeSBdBu+g1UjVxRoxFVAK+y/Gb++2NnUn/AefFF11TtOKBnzyjUvhNb ZO/tdx4CQvBSJb+qCtDMndyftMT4EGqVTGTkp1P0qgtOCV8fZHArfzKxL8OE6rklkhht NvgKReVVFT13lYLq0pe5z5YLTiLcU0rqk7s1S1OdI+79GKvxZX5dC0C++qSrZE7UxlwC HCDw== X-Gm-Message-State: ALyK8tIuz4T5JkYUzZ07IwBwMyJ/JKOQmjMuZd7Y05k4EXF5STiv8KwapauzYlhLLzZTcpJ4PTrGB0PJjGgEAQ== X-Received: by 10.25.84.80 with SMTP id i77mr1448799lfb.88.1465612212530; Fri, 10 Jun 2016 19:30:12 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Fri, 10 Jun 2016 19:30:11 -0700 (PDT) In-Reply-To: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> From: Robert Raszuk Date: Sat, 11 Jun 2016 04:30:11 +0200 X-Google-Sender-Auth: SXoMreH4o_B60NbaAmYoKzrsiio Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a11405a284e75980534f76f05 Archived-At: Cc: idr wg Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 02:30:17 -0000 --001a11405a284e75980534f76f05 Content-Type: text/plain; charset=UTF-8 I must admit that you are right to say that true skill is in finding some way to help address the problem for vast majority of deployments. I also agree that while best protocol design skills are in addressing corner cases here no loop will form and no harm to routing would be done if say 5% disable that capability. However my honest observation is that this approach would work well when operators would only operate on binary BGP code with such functionality enabled as mandatory capability and be always ON by default with no option to disable it. Said this we all have to admit that such times are long gone and as soon as NOC have a business case and chance to disable it their marketing folks will force them to do so. So the real question comes to the point if IDR is in position to issue RFCs to test ISP marketing guys in their level of power to enforce big vendors to add knobs disabling such capabilities or speeding up shifting to open source BGP .... Tx, r. On Sat, Jun 11, 2016 at 4:04 AM, Randy Bush wrote: > >> In spite of your concerns RS is a perfect place to deploy roles: RS does > >> not provide IP-transit (if there are no leaks!) but it *provides* local > >> connectivity. So, RS is provider for all its neighbors. > > You mean other then FT's OpenTransit ? > > welcome to the kinky internet, where every thinkable and unthinkable act > is done; after all, it was invented in california. :) > > if you are planning something kinky, do not bring a straight friend to > the party. that is, as i said to job, if you intend to violate valley > free or peer-peer, do not run mechanisms designed to detect these as > errors. > > perhaps we should design for the norm. with things this complex, we can > always find corner cases. though i guess one can make a career out of > finding them; it's a target rich environment. true skill is in finding > the simple middle path. > > randy > --001a11405a284e75980534f76f05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I must admit that you are right to say = that true skill is in finding some way to help address the problem for vast= majority of deployments.=C2=A0

I also agree that while best protocol design skills are in addres= sing corner cases here no loop will form and no harm to routing would be do= ne if say 5% disable that capability.=C2=A0

However my honest observation is that this approach w= ould work well when operators would only operate on binary BGP code with su= ch functionality enabled as mandatory capability and be always ON by defaul= t with no option to disable it. =C2=A0 Said this we all have to admit that = such times are long gone and as soon as NOC have a business case and chance= to disable it their marketing folks will force them to do so.=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
So the real question comes t= o the point if IDR is in position to issue RFCs to test ISP marketing guys = in their level of power to enforce big vendors to add knobs disabling such = capabilities or speeding up shifting to open source BGP ....

Tx,
r. =C2= =A0



On Sat, Jun 11, 201= 6 at 4:04 AM, Randy Bush <randy@psg.com> wrote:
>> In spite of your concerns RS is= a perfect place to deploy roles: RS does
>> not provide IP-transit (if there are no leaks!) but it *pro= vides* local
>> connectivity. So, RS is provider for all its neig= hbors.
> You mean other then FT's OpenTransit ?

welcome to the kinky internet, where every thinkable and unthinkable= act
is done; after all, it was invented in california. :)

if you are planning something kinky, do not bring a straight friend to
the party.=C2=A0 that is, as i said to job, if you intend to violate valley=
free or peer-peer, do not run mechanisms designed to detect these as
errors.

perhaps we should design for the norm.=C2=A0 with things this complex, we c= an
always find corner cases.=C2=A0 though i guess one can make a career out of=
finding them; it's a target rich environment.=C2=A0 true skill is in fi= nding
the simple middle path.

randy

--001a11405a284e75980534f76f05-- From nobody Fri Jun 10 21:07:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF14D12D0B7 for ; Fri, 10 Jun 2016 21:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyzrpiXP0tnH for ; Fri, 10 Jun 2016 21:07:45 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C8E12D142 for ; Fri, 10 Jun 2016 21:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7552; q=dns/txt; s=iport; t=1465618065; x=1466827665; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CrrRI6lX/n7oETHue6lmYJmd2RwuFCuhUM4jXfcLUq0=; b=EheBETtjPANstnH5hW+EPCbPamgFkketiYFQqaZmDYN+8JH1hHSN9BeO F24AvDWcPVsyiiAjkTgh5wf5Sn4tCAfhsFVct6P3TWmZJqU62v5roJoH2 LJ3pjB/7UcQjOc/uCFeUmfUjk4ihZt2SWXnWb9jHy6pO7tlvfzrRdX9pL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBBgBljVtX/5hdJa1egnBOVn22IoZ5F?= =?us-ascii?q?wEMhXMCgSc8EAEBAQEBAQFlJ4RGAQEEAQEBGhBBCxACAQgOJwYEBycLFBEBAQQ?= =?us-ascii?q?OBYgwDr1sAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4F3glaHbIIvBZNBhR4Bh?= =?us-ascii?q?gOIJIFphFKIZY9sATUfggccFoE1booIAQEB?= X-IronPort-AV: E=Sophos;i="5.26,453,1459814400"; d="scan'208,217";a="283512543" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2016 04:07:44 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5B47hYR007890 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 11 Jun 2016 04:07:43 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 10 Jun 2016 23:07:43 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1104.009; Fri, 10 Jun 2016 23:07:43 -0500 From: "Jakob Heitz (jheitz)" To: Susan Hares Thread-Topic: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) Thread-Index: AdHAElYAB9sVfa6xQkej61auMDdHAwDhHdVc Date: Sat, 11 Jun 2016 04:07:42 +0000 Message-ID: References: <017501d1c01a$41156960$c3403c20$@ndzh.com> In-Reply-To: <017501d1c01a$41156960$c3403c20$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_BE51245C87B749F68C5447D310B93C7Fciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 04:07:47 -0000 --_000_BE51245C87B749F68C5447D310B93C7Fciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Moving the new attribute flags into the attribute is the safe way to ensure= that the flags will be propagated properly by legacy speakers. Thanks, Jakob. On Jun 6, 2016, at 10:38 AM, Susan Hares > wrote: This begins a 2 week WG Adoption call for draft-keyupate-idr-bgp-attribute-= announcement. You can find the draft at: https://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-attribute-announcem= ent/ This draft defines attribute extensions that help confine the scope of Opti= onal attributes within a given AS or a given BGP member-AS in Confederation= . In your comments please include: 1) "Support" or "No support" for this draft as an IDR WG draft, 2) Experiences with debugging optional attributes errors that this dra= ft would aid, 3) Deployments that use AS confederations where this draft's ability t= o confined scope of the optional attributes would help restrict errors, Sue Hares and John Scudder _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_BE51245C87B749F68C5447D310B93C7Fciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support.
Moving the new attribute flags into the attr= ibute is the safe way to ensure that the flags will be propagated properly = by legacy speakers.

Thanks,
Jakob.


On Jun 6, 2016, at 10:38 AM, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week WG Adoption call for draft-keyu= pate-idr-bgp-attribute-announcement.  You can find the draft at:

https://datatracker.ietf.org/doc/dr= aft-keyupate-idr-bgp-attribute-announcement/

 

This draft defines attribute extensions that help co= nfine the scope of Optional attributes within a given AS or a given BGP mem= ber-AS in Confederation.   In your comments please include:<= /o:p>

1)    &nbs= p; “Support” or “No support̶= 1; for this draft as an IDR WG draft,

2)    &nbs= p; Experiences with debugging optional attributes = errors that this draft would aid,

3)    &nbs= p; Deployments that use AS confederations where th= is draft’s ability to confined scope of the optional attributes would= help restrict errors,

 

 

Sue Hares and John Scudder  

 

 

 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_BE51245C87B749F68C5447D310B93C7Fciscocom_-- From nobody Fri Jun 10 21:56:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C9412D903 for ; Fri, 10 Jun 2016 21:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TdKg8pBe6Dr for ; Fri, 10 Jun 2016 21:56:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF6812D917 for ; Fri, 10 Jun 2016 21:56:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bBay8-0001Ir-Ad; Sat, 11 Jun 2016 04:56:24 +0000 Date: Fri, 10 Jun 2016 21:56:23 -0700 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 04:56:27 -0000 > However my honest observation is that this approach would work well > when operators would only operate on binary BGP code with such > functionality enabled as mandatory capability and be always ON by > default with no option to disable it. Said this we all have to admit > that such times are long gone and as soon as NOC have a business case > and chance to disable it their marketing folks will force them to do > so. > > So the real question comes to the point if IDR is in position to issue > RFCs to test ISP marketing guys in their level of power to enforce big > vendors to add knobs disabling such capabilities or speeding up > shifting to open source BGP .... complex twisty path which starts and ends in unhelpful places. i am not interested in a vendor nanny state, never have been. see the very careful and complete operator control in RFC 6811 BGP Prefix Origin Validation. if i know i have a 'normal' relationship with a bgp neighbor, give me to tools to mark it as such and to detect and maybe even ameliorate damage by [untentional (i am an optimist)] violation of that normality. if i do not have a normal relationship, i won't use protective tools which assume and enforce normality. life can be simple. randy From nobody Fri Jun 10 22:37:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A51C12DA49 for ; Fri, 10 Jun 2016 22:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.628 X-Spam-Level: X-Spam-Status: No, score=-5.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTsrXlIoybmw for ; Fri, 10 Jun 2016 22:37:23 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8581812B01B for ; Fri, 10 Jun 2016 22:37:23 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 47B90C3C64; Sat, 11 Jun 2016 05:37:23 +0000 (UTC) Date: Sat, 11 Jun 2016 05:37:23 +0000 From: heasley To: Robert Raszuk Message-ID: <20160611053723.GP41578@shrubbery.net> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: idr wg Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 05:37:24 -0000 Sat, Jun 11, 2016 at 04:30:11AM +0200, Robert Raszuk: > However my honest observation is that this approach would work well when > operators would only operate on binary BGP code with such functionality > enabled as mandatory capability and be always ON by default with no option > to disable it. Said this we all have to admit that such times are long > gone and as soon as NOC have a business case and chance to disable it their > marketing folks will force them to do so. I suspect that any given NOC/operator does not want to be featured on BBC news for having broken Internet access to popular destinations. So, perhaps most would be less likely to skinny dip. I'm not convinced of the idea, but I would suggest that the draft should mandate that it be possible to disable the capability by configuration. From nobody Fri Jun 10 22:42:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C63A12DA60 for ; Fri, 10 Jun 2016 22:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsDTU4ijV10s for ; Fri, 10 Jun 2016 22:42:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E5512DA5E for ; Fri, 10 Jun 2016 22:42:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bBbgd-0001R4-B1; Sat, 11 Jun 2016 05:42:23 +0000 Date: Fri, 10 Jun 2016 22:42:21 -0700 Message-ID: From: Randy Bush To: heasley In-Reply-To: <20160611053723.GP41578@shrubbery.net> References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160611053723.GP41578@shrubbery.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg , Robert Raszuk Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 05:42:26 -0000 > I'm not convinced of the idea, but I would suggest that the draft should > mandate that it be possible to disable the capability by configuration. clearly. my bad. i thought it was implied by 'capability' as opposed to a mandatory change to open. randy From nobody Sat Jun 11 03:47:45 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A843412D0E3 for ; Sat, 11 Jun 2016 03:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw6XTXTpNo2d for ; Sat, 11 Jun 2016 03:47:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C8512D0C0 for ; Sat, 11 Jun 2016 03:47:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bBgS4-0002du-A3; Sat, 11 Jun 2016 10:47:40 +0000 Date: Sat, 11 Jun 2016 03:47:39 -0700 Message-ID: From: Randy Bush To: heasley In-Reply-To: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160611053723.GP41578@shrubbery.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 10:47:44 -0000 >> I'm not convinced of the idea, but I would suggest that the draft should >> mandate that it be possible to disable the capability by configuration. > > clearly. my bad. i thought it was implied by 'capability' as opposed > to a mandatory change to open. someone privately commented that maybe the negotiation could always be on, but there should be a relationship "it's complex"' or whatever. randy From nobody Mon Jun 13 06:28:11 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB5B12B017; Mon, 13 Jun 2016 06:28:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 06:28:09 -0700 Archived-At: Cc: idr@ietf.org, shares@ndzh.com, idr-chairs@ietf.org, draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 13:28:10 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-idr-ix-bgp-route-server-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Quick question: Why is the following statement a SHOULD and not a MUST: "the route server SHOULD NOT prepend its own AS number to the AS_PATH segment nor modify the AS_PATH segment in any other way. " Is this because the clients might eitherwise not accept the message? Maybe add one sentence to explain the SHOULD! From nobody Mon Jun 13 06:42:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC1612D7B1 for ; Mon, 13 Jun 2016 06:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkIp8RAtPx0r for ; Mon, 13 Jun 2016 06:42:26 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443C212D7AE for ; Mon, 13 Jun 2016 06:42:25 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5DDgIDl047403 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jun 2016 14:42:18 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <575EB839.3050303@foobar.org> Date: Mon, 13 Jun 2016 14:42:17 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mirja Kuehlewind References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> In-Reply-To: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, The IESG , shares@ndzh.com, draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 13:42:26 -0000 Mirja Kuehlewind wrote: > Quick question: Why is the following statement a SHOULD and not a MUST: > "the route server SHOULD NOT prepend its own AS number to the AS_PATH > segment nor modify the AS_PATH segment in any other way. " > Is this because the clients might eitherwise not accept the message? > Maybe add one sentence to explain the SHOULD! Hi Mirja, This was the subject of some discussion recently on IDR. Yes, probably appropriate to add in a one-liner to explain why it's SHOULD rather than MUST. Nick From nobody Mon Jun 13 07:17:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50E912D7BD for ; Mon, 13 Jun 2016 07:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCNYiEBNPdDH for ; Mon, 13 Jun 2016 07:17:55 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216BE12D7C4 for ; Mon, 13 Jun 2016 07:17:52 -0700 (PDT) Received: (qmail 26438 invoked from network); 13 Jun 2016 16:17:50 +0200 Received: from p5dec2a86.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.42.134) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Jun 2016 16:17:50 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <575EB839.3050303@foobar.org> Date: Mon, 13 Jun 2016 16:17:49 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3124) Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, The IESG , shares@ndzh.com, draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 14:17:56 -0000 Great! Thanks! > Am 13.06.2016 um 15:42 schrieb Nick Hilliard : > > Mirja Kuehlewind wrote: >> Quick question: Why is the following statement a SHOULD and not a MUST: >> "the route server SHOULD NOT prepend its own AS number to the AS_PATH >> segment nor modify the AS_PATH segment in any other way. " >> Is this because the clients might eitherwise not accept the message? >> Maybe add one sentence to explain the SHOULD! > > Hi Mirja, > > This was the subject of some discussion recently on IDR. Yes, probably > appropriate to add in a one-liner to explain why it's SHOULD rather than > MUST. > > Nick From nobody Mon Jun 13 14:36:31 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A8F12DA73 for ; Mon, 13 Jun 2016 14:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 776fU9Glz4Oi for ; Mon, 13 Jun 2016 14:35:10 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E2112DA6E for ; Mon, 13 Jun 2016 14:35:09 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5DLZ1bM064087 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jun 2016 22:35:02 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be cupcake.local Message-ID: <575F2704.3050509@foobar.org> Date: Mon, 13 Jun 2016 22:35:00 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Mirja Kuehlewind (IETF)" References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> In-Reply-To: <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, The IESG , shares@ndzh.com, draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 21:35:11 -0000 Mirja Kuehlewind (IETF) wrote: > Great! Thanks! this is now changed as follows: > https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508 Nick From nobody Mon Jun 13 19:34:29 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE5C12D105 for ; Mon, 13 Jun 2016 19:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbQeDVA-FjHS for ; Mon, 13 Jun 2016 19:34:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B9612D0DA for ; Mon, 13 Jun 2016 19:34:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bCeBL-00006d-OZ; Tue, 14 Jun 2016 02:34:23 +0000 Date: Tue, 14 Jun 2016 11:34:22 +0900 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <575F2704.3050509@foobar.org> References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 02:34:27 -0000 > this is now changed as follows: > https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508 i hate to be old fashioned; actually, that's a lie; but is there either an OLD/NEW here or an internet-draft. randy From nobody Mon Jun 13 19:36:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4188B12D0DA for ; Mon, 13 Jun 2016 19:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwJluLkb2i_J for ; Mon, 13 Jun 2016 19:36:50 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC6612D105 for ; Mon, 13 Jun 2016 19:36:50 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id z186so125237299ywd.2 for ; Mon, 13 Jun 2016 19:36: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:from:date:message-id :subject:to:cc; bh=HjOE/qKjtSWrOXwglg5huXzryTWyi+V/pEANhfEGGUQ=; b=nodjdtMUxBUbgVthR1th1g/Q2fY7J/vi4+z6wtZhhE8bOz8Z7cBWR9Cx8UriUXoH+k KcqGfb4ygLRxz+66rtwcvNrUg66xcXohOljJUwV3Bi1Gr9Q7lY8JhNlh905elKqi+QCa iafIonhx81ZyMIkdFl0hL7dpkzMWBIWYDD0xW9xdyUZNaXiEPJd5aCza9ZTbiIXj+EBK L6N1NWF+KYVxGO4MOgZlYps3pBjCgbm5aL9PagQ9NE3ay+4x1GpacCzNibj05oC/W53q XzXw0EayTVMPgy4jAF10p3NmH2jz479GSVV9N72Jh+wdPxAJ8I41qqeYcJV3nYGTg3dE Hcig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=HjOE/qKjtSWrOXwglg5huXzryTWyi+V/pEANhfEGGUQ=; b=jiNTuBwDtuqQ1oB46hbfhzlPZslCYmsJc2shEHev09sF8EQEDHpKaqOydGJvMoXW8n oSEA/Cn0CzSfuz7vCnjOdnP3rvXrs1B0urUOoWARojBAEz0SNk4nAhWdnYFa0YwHbkbS Zu4cRnTlC8FHsCqIXU+f1F5RKPnDSu+jRic6m6GYz+5ZkYlDO4VguWYnOu4bU9yLEM1+ AFHt5cRmWHEWCMxVW3XD33NdpaXKzqSrYJZtv35dWO8/ucoo7Nym2a1fZJPCw/PLhCZ0 juS11N4683Xs/ymj0b6MUMotYhJ3RRtFb/LKdd/cZMCQcr0kq7u6/AbWvOOV2FKznAjC ACig== X-Gm-Message-State: ALyK8tLCa/nx/8mGOHU/UtLCJBBLR6r3Sb/Dm6++YUMc05c6os7USfBX6iMrC3TrkXI3FFiUDvpglYVOEMB5/Q== X-Received: by 10.13.221.131 with SMTP id g125mr698438ywe.238.1465871809853; Mon, 13 Jun 2016 19:36:49 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.129.146.130 with HTTP; Mon, 13 Jun 2016 19:36:49 -0700 (PDT) In-Reply-To: References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> From: Christopher Morrow Date: Mon, 13 Jun 2016 22:36:49 -0400 X-Google-Sender-Auth: OwjsuwHaDEKJUbCUc0qzFYQgcx8 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=94eb2c061040834081053533e0d3 Archived-At: Cc: "idr@ietf.org List" Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 02:36:52 -0000 --94eb2c061040834081053533e0d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 13, 2016 at 10:34 PM, Randy Bush wrote: > > this is now changed as follows: > > > https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd= 0508 > > i hate to be old fashioned; actually, that's a lie; but is there either > an OLD/NEW here or an internet-draft. > =E2=80=8Bdid you mean: "Where is the full draft?" =E2=80=8B https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/blob/5fd0508= b617696ee2e60f9d9a6572d8682568d07/draft-ietf-idr-ix-bgp-route-server.xml is the xml version at least... (there was a 'view' button that got me that link) it'd be rad if there was an auto-generation of the html/txt/(pdf?) versions based on git commit hookage/etc. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --94eb2c061040834081053533e0d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Ju= n 13, 2016 at 10:34 PM, Randy Bush <randy@psg.com> wrote:
> this is now changed as follows:
> https://github.com= /fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508

i hate to be old fashioned; actually, that's a lie; but is there= either
an OLD/NEW here or an internet-draft.

<= div class=3D"gmail_default" style=3D"font-size:small">=E2=80=8Bdid you mean= : "Where is the full draft?"

=E2=80=8Bhttps://github.com/fooelisa/draft-jasinska= -ix-bgp-route-server/blob/5fd0508b617696ee2e60f9d9a6572d8682568d07/draft-ie= tf-idr-ix-bgp-route-server.xml

is the xml version at least... (there was a 'view' butto= n that got me that link)

= it'd be rad if there was an auto-generation of the html/txt/(pdf?) vers= ions based on git commit hookage/etc.

=C2=A0

randy

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--94eb2c061040834081053533e0d3-- From nobody Mon Jun 13 19:38:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8B412D11A for ; Mon, 13 Jun 2016 19:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HopmaRXAlxvu for ; Mon, 13 Jun 2016 19:38:45 -0700 (PDT) Received: from mail.rg.net (mail.rg.net [198.180.150.2]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A48912D105 for ; Mon, 13 Jun 2016 19:38:45 -0700 (PDT) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=[192.168.0.18]) by mail.rg.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1bCeFV-0001pB-7Q; Tue, 14 Jun 2016 02:38:41 +0000 From: "Randy Bush" To: "Christopher Morrow" Date: Tue, 14 Jun 2016 11:38:38 +0900 Message-ID: In-Reply-To: References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "idr@ietf.org List" Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 02:38:47 -0000 >>> this is now changed as follows: >>> >> https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508 >> >> i hate to be old fashioned; actually, that's a lie; but is there >> either >> an OLD/NEW here or an internet-draft. > > ​did you mean: "Where is the full draft?" no. i mean a real internet-draft, in the ietf drafts directory which i mirror. From nobody Mon Jun 13 19:48:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E2C12D586 for ; Mon, 13 Jun 2016 19:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAFS2LL3OxvZ for ; Mon, 13 Jun 2016 19:48:40 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225FB12D127 for ; Mon, 13 Jun 2016 19:48:40 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id v137so41492579ywa.3 for ; Mon, 13 Jun 2016 19:48: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:from:date:message-id :subject:to:cc; bh=5CvfRbhmz+0lR3FPALtKG0B988j1quWc/kKYHV9XoyA=; b=Qj9QsI0mju+auhYjUuWLr7GyuMksjGOMXS2XikLtOTg2Q/6r4Opua6h+Xegh7BlkHw kfiBzzAdwt0vflL+9T8MecdxdOiwj+mjxHXTI4GkwBTD1ncdmD7s1U/NGH/Xr8LIm3QT fIILSHnnHQ1n0lOjAcDZ39I3OvA4FHC5bq/7L71ZHrAsTMRLDUCwJC4ZR/xAoPHpMqFx m1nyoodkcrh6j80v6qeK0Bn1m/UvA4HYIgNhR9xdoLJMA7QX6DCKvkixvh4gzblhSJpu IaCAbyP7PsZS/+EO+/OOb3k/EKrQ+l2OJVkpNE9GhpHxEeYVeJgLZwLrs/9qCUrxN2LB +cnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5CvfRbhmz+0lR3FPALtKG0B988j1quWc/kKYHV9XoyA=; b=KEVlkzl9GIYkqYIhh+X7QxAwOXxR7x5sYbfS9vLhMZC/GFLlyQ1fAg2IotSJIsGrqI +s5TLkJEkuq/ROTK6VfpeDbBf5OZroFVdkNJH/U4CUvg1X5OZUIEul+XHHO3lWKcYm3x xGbu5M5nmkxNMGlhhvY086Jy5TumKmVrOJhxrT1lnws3hm1++6LvwBvJ8QwLmCYpIhXH FvX+SjwXPjzHuZvqmlfaNjpiYuViUzFaS+oWkvVFWZZFgfSFnHRHOOHKwFDWtCiK/VEc udXJoT/sCH3DVCG+fE9kGvx97h745gcqOWiVmDjwqscpWu7RV7KtfcbkFUNjk1+cFrJu d7gA== X-Gm-Message-State: ALyK8tI2QLReQvYt0Z9mdqDy0/RYMZ5cxBE2iYm6lHoSNCCMhngpz2FYILLjgjjytpMNcw8APcGNhw6jI+SnYw== X-Received: by 10.13.196.132 with SMTP id g126mr711628ywd.95.1465872519331; Mon, 13 Jun 2016 19:48:39 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.129.146.130 with HTTP; Mon, 13 Jun 2016 19:48:38 -0700 (PDT) In-Reply-To: References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> From: Christopher Morrow Date: Mon, 13 Jun 2016 22:48:38 -0400 X-Google-Sender-Auth: ltw4xPd4v5NMHhzjU8A4rHYqr_E Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a114d7ed4cd059c0535340ae0 Archived-At: Cc: "idr@ietf.org List" Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 02:48:42 -0000 --001a114d7ed4cd059c0535340ae0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 13, 2016 at 10:38 PM, Randy Bush wrote: > this is now changed as follows: >>>> >>>> >>> https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5= fd0508 >>> >>> i hate to be old fashioned; actually, that's a lie; but is there either >>> an OLD/NEW here or an internet-draft. >>> >> >> =E2=80=8Bdid you mean: "Where is the full draft?" >> > > no. i mean a real internet-draft, in the ietf drafts directory which i > mirror. > =E2=80=8Boh! "hey, cool code kid, got an email to the submission bot to get= your changes to where we can all see them?" (version of: =E2=80=8B http://static.flickr.com/87/240803829_9212773615_o.png) err, maybe nick was thinking there might be more revisions on his text options? I'm not a native bgp speaker, but I'd question (for instance) the use of 'AS_PATH segment' in this part of the draft, given: "AS_PATH is a well-known mandatory attribute that is composed of a sequence of AS path segments. Each AS path segment is represented by a triple ." from: https://tools.ietf.org/html/rfc4271 I would have thought 'segment' was an individual 'asn' (the triple I suppose, the TLV) in the AS_PATH, not the whole 'AS_PATH' attribute. Maybe instead of 'AS_PATH segment' in nick's revision: "This differs from the behaviour specified in section 5.1.2 of , wh= ich requires that the BGP speaker prepends its own AS number as the last element of the AS_PATH. While it is technically possible to operate a route server which prepends its own AS to the AS_PATH, it is not recommended to do so because this may adversely affect the resulting network topology between the route server clients." =E2=80=8Bagain, I'm not a native bgp speaker, so I'm probably off base, but= ... maybe there's a revision in the revision still to be had before updating the actual draft archive?=E2=80=8B --001a114d7ed4cd059c0535340ae0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Ju= n 13, 2016 at 10:38 PM, Randy Bush <randy@psg.com> wrote:
this is now changed as follows:

https://github.com/fooe= lisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508

i hate to be old fashioned; actually, that's a lie; but is there either=
an OLD/NEW here or an internet-draft.

=E2=80=8Bdid you mean: "Where is the full draft?"

 no.=C2=A0 i mean a real internet-draft, in the ietf drafts directory which = i mirror.

=E2=80=8Boh! "hey, cool code kid, = got an email to the submission bot to get your changes to where we can all = see them?" (version of: =E2=80=8Bhttp://static.flickr.com/87/240803829_9212773= 615_o.png)
=
err, maybe= nick was thinking there might be more revisions on his text options?
=

I'm not a native bgp speak= er, but I'd question (for instance) the use of 'AS_PATH segment'= ; in this part of the draft, given:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "AS_PATH is a well-known mandatory attribute that is compos= ed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 of a sequence of AS path segments.=C2=A0 Each AS path segment is
<= div class=3D"gmail_default">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 repre= sented by a triple <path segment type, path segment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 length, path segmen= t value>."

from:=C2=A0https://tools.ietf.org/html/rfc4271

I would have thought 'segment&= #39; was an individual 'asn' (the triple I suppose, the TLV) in the= AS_PATH, not the whole 'AS_PATH' attribute. Maybe instead of '= AS_PATH segment' in nick's revision:

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0"This differs from the behaviour
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sp= ecified in section 5.1.2 of <xref target=3D"RFC4271" />, wh= ich
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 requires that the BGP speaker prepends its own AS number as
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the last element of the AS_PATH.=C2=A0 = While it is technically
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 possible to operate a route server which pr= epends its own AS to
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 the AS_PATH, it is not recommended to do so be= cause this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 may adversely affect the resulting network topology be= tween the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 route server clients."

= =E2=80=8Bagain, I'm not a native bgp speaker, so I'm probably off b= ase, but... maybe there's a revision in the revision still to be had be= fore updating the actual draft archive?=E2=80=8B

--001a114d7ed4cd059c0535340ae0-- From nobody Mon Jun 13 20:14:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0137512D5AA for ; Mon, 13 Jun 2016 20:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJNNwMbWmO3t for ; Mon, 13 Jun 2016 20:14:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13FF12D586 for ; Mon, 13 Jun 2016 20:14:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bCeoW-0000Hz-Rt; Tue, 14 Jun 2016 03:14:53 +0000 Date: Tue, 14 Jun 2016 12:14:50 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.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=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "idr@ietf.org List" Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 03:14:57 -0000 >>>> i hate to be old fashioned; actually, that's a lie; but is there either >>>> an OLD/NEW here or an internet-draft. > err, maybe nick was thinking there might be more revisions on his text > options? see OLD/NEW comment above > I'm not a native bgp speaker, but I'd question (for instance) the use of > 'AS_PATH segment' in this part of the draft, given: >=20 > "AS_PATH is a well-known mandatory attribute that is composed > of a sequence of AS path segments. Each AS path segment is > represented by a triple length, path segment value>." >=20 > from: https://tools.ietf.org/html/rfc4271 >=20 > I would have thought 'segment' was an individual 'asn' (the triple I > suppose, the TLV) in the AS_PATH, not the whole 'AS_PATH' attribute. Maybe > instead of 'AS_PATH segment' in nick's revision: >=20 > "This differs from the behaviour specified in section > 5.1.2 of , which requires that > the BGP speaker prepends its own AS number as the last > element of the AS_PATH. While it is technically > possible to operate a route server which prepends its > own AS to the AS_PATH, it is not recommended to do so > because this may adversely affect the resulting network > topology between the route server clients." >=20 > =E2=80=8Bagain, I'm not a native bgp speaker, so I'm probably off base, b= ut... > maybe there's a revision in the revision still to be had before updating > the actual draft archive?=E2=80=8B i think what might be said is "creating an undesirably longer AS_PATH" and thus biasing receivers against using the exchange. From nobody Mon Jun 13 20:48:41 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7313412D73B for ; Mon, 13 Jun 2016 20:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8mWmQXeWOTt for ; Mon, 13 Jun 2016 20:48:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890D612D0FB for ; Mon, 13 Jun 2016 20:48:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bCfLB-0000OW-H6; Tue, 14 Jun 2016 03:48:37 +0000 Date: Tue, 14 Jun 2016 12:48:35 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "idr@ietf.org List" Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 03:48:40 -0000 > i think what might be said is "creating an undesirably longer AS_PATH" > and thus biasing receivers against using the exchange. my bad (trans-pac and not enough coffee). we're discussing the opposite, why one might want the RS to have an AS in my path. well, to me it would be because i have one a path directly from peer and one via the RS. i would prefer the former. see draft-ietf-idr-rs-bfd-01.txt for why i kinda like to know layer two is up. randy From nobody Mon Jun 13 21:26:01 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AE312DB1A for ; Mon, 13 Jun 2016 21:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuvPJVmNk9Ir for ; Mon, 13 Jun 2016 21:25:59 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A965E12D195 for ; Mon, 13 Jun 2016 21:25:58 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id q132so58658259lfe.3 for ; Mon, 13 Jun 2016 21:25:58 -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; bh=i4RdyKHOv6NkNFEv2WHk1eQXs5DhzkUQjyxp6e50v+4=; b=TkvZyIC2sJYNX5NBLbuaHr5nBu+xq9+ffUqreErTEIDufVF92Zus7vKGO3iyJpcaFb F3fTI+5Ihb9joT7uEa9fNHEiF7koK6sKUDJ7wckk2Y6ZDdp6zKjrP1PgNACUT6eqD3sI 2j4SBxeKdtuTfcKv4Tpp0mDWkuvJGLQVdGaB2qX9QzcQOQbYMmig7fP53u8GevVT9Xs0 DlansfZUWrkUTmTaM5SGfGqaTaBGbRSEryeltp0w+I4ZQ9TfMoSjwLeoKWSFMJ8B2LWr w74VYQ0hTzGLpvyPVy/lZHSSi384Hw5QRsK/KlHcGB7nlfr15OzTUcbZzCREIWg0WY2L zgqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=i4RdyKHOv6NkNFEv2WHk1eQXs5DhzkUQjyxp6e50v+4=; b=lEhy1mNrVSLNWMDOse4x518U2gzvsP/rfUKSmMh/nQLVgN13F/6p1q2xtE9uCs83tm DgX6Ytps2SbzDiDZuVVHpry5udXcZ+BnNWfoArqVsOUtjK4d7Vmp1tuCGtim1IxuEtRg Hy03lvbncTIxexoIS6omq3jP00njOoumRQT0M/lZ4xyl0lyYYeJtRrYvbhT/Xq29F+ef FKPvZv06OcFDRcX6yMZ95zJuZlACDklQOCrfDaSjj7CmJM8H6Ui63/5vdjYnepw2JVNf ZMI1dT790Fv9lX5MizPKnnOjD8aJmNdwJthOXCbhGe0iP8lSbvpQMPwkvwCedS5pLo7A nzPA== X-Gm-Message-State: ALyK8tLQLu/M0UZTCeoCZyzikvCRGqT999LRP4sd4npjZd+7IGdiFGSyv4y8Bs5G4p7Sjs2V+4y0ASJtpU3LrA== MIME-Version: 1.0 X-Received: by 10.25.84.65 with SMTP id i62mr1216955lfb.88.1465878356725; Mon, 13 Jun 2016 21:25:56 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Mon, 13 Jun 2016 21:25:56 -0700 (PDT) Received: by 10.25.21.30 with HTTP; Mon, 13 Jun 2016 21:25:56 -0700 (PDT) In-Reply-To: References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> Date: Tue, 14 Jun 2016 06:25:56 +0200 X-Google-Sender-Auth: oDU15yP9xpOXeGRAWcnsm1U1PJw Message-ID: From: Robert Raszuk To: Randy Bush Content-Type: multipart/alternative; boundary=001a11411f28bc99b005353566f0 Archived-At: Cc: idr wg Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 04:26:00 -0000 --001a11411f28bc99b005353566f0 Content-Type: text/plain; charset=UTF-8 Let's observe that nothing prevents such "one" to extend it's inbound AS_PATH for nets he learns from RS with additional AS to make it less preffered ... without any special action to be taken by RS itself. Thx R. On Jun 13, 2016 23:48, "Randy Bush" wrote: > > i think what might be said is "creating an undesirably longer AS_PATH" > > and thus biasing receivers against using the exchange. > > my bad (trans-pac and not enough coffee). we're discussing the > opposite, why one might want the RS to have an AS in my path. well, to > me it would be because i have one a path directly from peer and one via > the RS. i would prefer the former. see draft-ietf-idr-rs-bfd-01.txt > for why i kinda like to know layer two is up. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a11411f28bc99b005353566f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Let's observe that nothing prevents such "one"= to extend it's inbound AS_PATH for nets he learns from RS with additio= nal AS to make it less preffered ... without any special action to be taken= by RS itself.

Thx
R.

On Jun 13, 2016 23:48, "Randy Bush" &l= t;randy@psg.com> wrote:
> i think what might be said= is "creating an undesirably longer AS_PATH"
> and thus biasing receivers against using the exchange.

my bad (trans-pac and not enough coffee).=C2=A0 we're discussing the opposite, why one might want the RS to have an AS in my path.=C2=A0 well, t= o
me it would be because i have one a path directly from peer and one via
the RS.=C2=A0 i would prefer the former.=C2=A0 see draft-ietf-idr-rs-bfd-01= .txt
for why i kinda like to know layer two is up.

randy

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--001a11411f28bc99b005353566f0-- From nobody Mon Jun 13 21:28:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D4512D107 for ; Mon, 13 Jun 2016 21:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_bHC6-HnwBq for ; Mon, 13 Jun 2016 21:28:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C01612B03A for ; Mon, 13 Jun 2016 21:28:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bCfxu-0000ZZ-Qc; Tue, 14 Jun 2016 04:28:39 +0000 Date: Tue, 14 Jun 2016 13:28:37 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 04:28:42 -0000 > Let's observe that nothing prevents such "one" to extend it's inbound > AS_PATH for nets he learns from RS with additional AS to make it less > preffered ... without any special action to be taken by RS itself. >>> i think what might be said is "creating an undesirably longer AS_PATH" >>> and thus biasing receivers against using the exchange. >> >> my bad (trans-pac and not enough coffee). we're discussing the >> opposite, why one might want the RS to have an AS in my path. well, to >> me it would be because i have one a path directly from peer and one via >> the RS. i would prefer the former. see draft-ietf-idr-rs-bfd-01.txt >> for why i kinda like to know layer two is up. and the sender can prepend when sending to the RS. and and and. the point is not to explore all possible hacks, but to explain why this SHOULD is not a MUST. life can be simple. randy From nobody Tue Jun 14 03:15:51 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265B112D18F for ; Tue, 14 Jun 2016 03:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id povNTDtpl4eo for ; Tue, 14 Jun 2016 03:15:48 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C663E12D162 for ; Tue, 14 Jun 2016 03:15:47 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5EAFhZI092979 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2016 11:15:44 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <575FD94E.8030606@foobar.org> Date: Tue, 14 Jun 2016 11:15:42 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Christopher Morrow References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "idr@ietf.org List" Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 10:15:50 -0000 Christopher Morrow wrote: > err, maybe nick was thinking there might be more revisions on his > text options? something like that. Who was it who said that dealing with the IETF is like being nibbled to death by ducks? > I'm not a native bgp speaker, but I'd question (for instance) the use > of 'AS_PATH segment' in this part of the draft, given: > ​again, I'm not a native bgp speaker No, you're correct. > so I'm probably off base, but... maybe there's a revision in the > revision still to be had before updating the actual draft archive?​ That would probably be tempting fate but then again, the reason the IETF exists at all is because fate was tempted. It would be a shame to lose that spark. Randy Bush wrote: > i think what might be said is "creating an undesirably longer AS_PATH" > and thus biasing receivers against using the exchange. "creating an undesirably longer AS_PATH" works, but "biasing receivers against using the exchange" is language that I would prefer to avoid, the reason being that route servers have an expected behaviour which is to provide a comparable topology view to bilateral peering. In this regard, jamming the RS ASN into the path violates the principal of least astonishment. The art is to distil this sentiment into a single sentence. The wording has been updated as follows: github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/686ed8a Is there consensus on this wording? If so I'll post -12. Nick From nobody Tue Jun 14 03:29:42 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EC212D1D8 for ; Tue, 14 Jun 2016 03:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPNNuJuzTAbE for ; Tue, 14 Jun 2016 03:29:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4FB12D746 for ; Tue, 14 Jun 2016 03:29:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bClbB-0001pp-Fr; Tue, 14 Jun 2016 10:29:33 +0000 Date: Tue, 14 Jun 2016 19:29:31 +0900 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <575FD94E.8030606@foobar.org> References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "idr@ietf.org List" Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 10:29:41 -0000 > Randy Bush wrote: >> i think what might be said is "creating an undesirably longer AS_PATH" >> and thus biasing receivers against using the exchange. and i recanted as it did not answer k=FChlewind's point > The wording has been updated as follows: > github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/686ed8a and therefore i do not that that does. Mirja Kuehlewind wrote: > Quick question: Why is the following statement a SHOULD and not a MUST: > "the route server SHOULD NOT prepend its own AS number to the AS_PATH > segment nor modify the AS_PATH segment in any other way. " i suggested an example; a corner case. but corner cases are typical for a MUST being a SHOULD > we're discussing the opposite, why one might want the RS to have an AS > in my path. well, to me it would be because i have one path directly > from peer and one via the RS. i would prefer the former. randy From nobody Tue Jun 14 05:08:33 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906CD12D08D for ; Tue, 14 Jun 2016 05:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7tnGzw6lG2J for ; Tue, 14 Jun 2016 05:08:30 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70EA912D533 for ; Tue, 14 Jun 2016 05:08:30 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5EC8QuW097270 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2016 13:08:26 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <575FF3B9.3080501@foobar.org> Date: Tue, 14 Jun 2016 13:08:25 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Randy Bush References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "idr@ietf.org List" Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 12:08:32 -0000 Randy Bush wrote: > i suggested an example; a corner case. but corner cases are typical for > a MUST being a SHOULD there are a bunch of corner cases associated with this particular situation. Does the proposed wording work for you? > While it is technically possible to operate a route server which > prepends its own AS to the AS_PATH, it is not recommended to do so > because creating an undesirably longer AS_PATH may adversely affect > the resulting network topology between the route server clients. Nick From nobody Tue Jun 14 07:42:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7396612DAC9 for ; Tue, 14 Jun 2016 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM-sEeSKsLpt for ; Tue, 14 Jun 2016 07:42:28 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B82812D7B8 for ; Tue, 14 Jun 2016 07:42:28 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id z186so138700650ywd.2 for ; Tue, 14 Jun 2016 07:42: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:from:date:message-id :subject:to:cc; bh=Ul807orxMxJhyWJAlHNInoZqxMsS+BhiDSN234FRc7c=; b=aQ/TSOlaxo45YglDV+map8k8nunwdx3TZdAhsVUPLMdv8tsUMjcQRiNWQjSj7B/eo+ 90BqBYsy/4i1g4CL+IK94M4JNOySUoulwhzon7td1Q1nIK3215n5w6f8jGmL6T94Piy9 7UVHQoWZ+g7ADr0uOwSH737K1ZWomMb/WLKESLeMae/5xjBB6Hjdtw8EUdllaSYGp/ry 5yin3omnlmKaB93n8e1TP2Q4iPY5dGXAbgicjPvz7u+GnAX8D8ePSxKeQ5P2TKEhqcXS bLUqIzErb9wmwcuYtJuvCBni+7A8NoICbOn9kLW0jhDXQ9UtzobJMDJdXpTLIKVAbvM6 A75g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ul807orxMxJhyWJAlHNInoZqxMsS+BhiDSN234FRc7c=; b=JYe8PAUOhXJdm96gJTm9NnXl3GUlyr/YTo4NRzW1xjyz+VzeFcQch9248XGEREJFGm vDBrjMV3KqgrCrG4cGYzXAEW1F2wPJvIlgcLXRJJmhf1PAppYvv8z5yF7NBDaVpwej+C WvrmDkjfZX/2wN9B7ttdaHI635jXN2sLkPZurwrv5aKIVYsnF/K/diGT1GzaBDn1MJJC D4tC9Ja8CPThi6OSatZXPh7tobMuTffU36n5K1BctvOHN/nVoeGicx5jE9dPCwrOLsj1 M0y6xYN1c9/OtUnLFCj3ogyQPXbnB1NIhDy3dmopWWYZJ0wr3cx2gbvY67yvg9EOgZWr Fwtg== X-Gm-Message-State: ALyK8tLCO8maTLYOqPobpMnHshqw7kXpyarUSsXweVFFlq5YkhFQjLv4AnKONhU5H+/aHcbf9eP+HMQwv/MtMA== X-Received: by 10.37.98.6 with SMTP id w6mr10352315ybb.129.1465915347573; Tue, 14 Jun 2016 07:42:27 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.129.146.130 with HTTP; Tue, 14 Jun 2016 07:42:27 -0700 (PDT) In-Reply-To: <575FF3B9.3080501@foobar.org> References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> From: Christopher Morrow Date: Tue, 14 Jun 2016 10:42:27 -0400 X-Google-Sender-Auth: qdopshiTrd6x4irrV0z8xAlQ4Cs Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a1142df2690224705353e03c3 Archived-At: Cc: "idr@ietf.org List" Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 14:42:31 -0000 --001a1142df2690224705353e03c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 14, 2016 at 8:08 AM, Nick Hilliard wrote: > Randy Bush wrote: > > i suggested an example; a corner case. but corner cases are typical fo= r > > a MUST being a SHOULD > > there are a bunch of corner cases associated with this particular > situation. > > Does the proposed wording work for you? > > =E2=80=8Blgtm, thanks!=E2=80=8B > > While it is technically possible to operate a route server which > > prepends its own AS to the AS_PATH, it is not recommended to do so > > because creating an undesirably longer AS_PATH may adversely affect > > the resulting network topology between the route server clients. > > Nick > > --001a1142df2690224705353e03c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Ju= n 14, 2016 at 8:08 AM, Nick Hilliard <nick@foobar.org> wrote:<= br>
Randy Bush wrote:
> i suggested an example; a corner case.=C2=A0 but corner cases are typi= cal for
> a MUST being a SHOULD

there are a bunch of corner cases associated with this particular situation= .

Does the proposed wording work for you?


=E2=80=8Blgtm, thanks!=E2=80=8B
=C2=A0
> While it is technically possible to operate a route server which
> prepends its own AS to the AS_PATH, it is not recommended to do so
> because creating an undesirably longer AS_PATH may adversely af= fect
> the resulting network topology= between the route server clients.

Nick


--001a1142df2690224705353e03c3-- From nobody Tue Jun 14 08:37:55 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D3612D7C8; Tue, 14 Jun 2016 08:37:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160614153754.19291.870.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 08:37:54 -0700 Archived-At: Cc: idr@ietf.org, shares@ndzh.com, idr-chairs@ietf.org, draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 15:37:54 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-idr-ix-bgp-route-server-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm at a bit of a loss to understand why path hiding would be a considered an undesirable property of an MLPE routeserver. IMHO as an operator that peers on MLPE exchanges as well as bilaterally on exchange fabrics and via PNIs. blinding a client of the MLPE which I may have a session already with at the exchange or via PNI is basically mandatory. Likewise without per-asn export policy at exchanges my ability to advertise anycast prefixes via the MLPE is basically noexistant If an IXP operator deploys a route server without implementing a per-client routing policy control system, then path hiding does not occur as all paths are considered equally valid from the point of view of the route server. Does not seem like a particularly desirable outcome. While I'm fine with 2.3 not being normative, it does seem desirable that an MLPE service offer the client control, it greatly increases the sorts of clients that can safely use the service. From nobody Tue Jun 14 09:09:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9657512D7D3; Tue, 14 Jun 2016 09:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UA5jnwhwikXC; Tue, 14 Jun 2016 09:09:19 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F98612B013; Tue, 14 Jun 2016 09:09:19 -0700 (PDT) X-Envelope-To: draft-ietf-idr-ix-bgp-route-server@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5EG9CNb006286 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2016 17:09:13 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57602C27.10803@foobar.org> Date: Tue, 14 Jun 2016 17:09:11 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joel Jaeggli References: <20160614153754.19291.870.idtracker@ietfa.amsl.com> In-Reply-To: <20160614153754.19291.870.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org, draft-ietf-idr-ix-bgp-route-server@ietf.org, The IESG , shares@ndzh.com, idr-chairs@ietf.org Subject: Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:09:22 -0000 Joel Jaeggli wrote: > I'm at a bit of a loss to understand why path hiding would be a > considered an undesirable property of an MLPE routeserver. Because in certain circumstances, if you have two paths A and B to a leaf node L, and path A decides to block access to L via the IXP, A's policy action acting on the RS will also block path B. There are no circumstances that I can imagine where this would be a desirable outcome. > IMHO as an > operator that peers on MLPE exchanges as well as bilaterally on exchange > fabrics and via PNIs. blinding a client of the MLPE which I may have a > session already with at the exchange or via PNI is basically mandatory. We're talking about different things here. Blinding a path by offering a better alternative is fine - which is, I think, what you are talking about. Blinding a path by denying third parties a failover path is not ok. > Likewise without per-asn export policy at exchanges my ability to > advertise anycast prefixes via the MLPE is basically noexistant > > If an IXP operator deploys a route server without > implementing a per-client routing policy control system, then path > hiding does not occur as all paths are considered equally valid from > the point of view of the route server. > > Does not seem like a particularly desirable outcome. > > While I'm fine with 2.3 not being normative, it does seem desirable that > an MLPE service offer the client control, it greatly increases the sorts > of clients that can safely use the service. Yep, agreed. This was an issue that Geoff Huston brought up during the rtgdir review. His point was that a standards track document cannot recommend a course of action which is not formally defined anywhere. At the moment, neither add-path nor the multiple rib options have been defined formally within standards track documents. So as authors we had an option of either delaying publication of this draft for an indeterminate number of years while the multi-rib and add-path drafts were standardized, or else mark these as non-normative for the time being and standardise the rest of the requirements. Given that ietf-idr-add-paths has been in the ietf process since 2002 and it's now 2016, we figured it was probably a more practical solution to move ahead with this draft as-is, and if someone wants to document multiple ribs in future, this draft can be updated. Nick From nobody Tue Jun 14 09:34:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD98912D811; Tue, 14 Jun 2016 09:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kByt4Dgs18R2; Tue, 14 Jun 2016 09:34:21 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F407312D13E; Tue, 14 Jun 2016 09:34:20 -0700 (PDT) Received: from mb-2.local ([IPv6:2620:11a:c081:20:7df9:7167:e9d9:6b3a]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u5EGYB5E020313 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 14 Jun 2016 16:34:12 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:7df9:7167:e9d9:6b3a] claimed to be mb-2.local To: Nick Hilliard References: <20160614153754.19291.870.idtracker@ietfa.amsl.com> <57602C27.10803@foobar.org> From: joel jaeggli Message-ID: Date: Tue, 14 Jun 2016 09:34:09 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <57602C27.10803@foobar.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5QE5D581A4JEBb0bt0j7mREOxxfuEgxaF" Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, The IESG , shares@ndzh.com, draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:34:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5QE5D581A4JEBb0bt0j7mREOxxfuEgxaF Content-Type: multipart/mixed; boundary="lwqRI7cAQI0i0kJJt3nGLkWxjdcdaGwtp" From: joel jaeggli To: Nick Hilliard Cc: idr@ietf.org, draft-ietf-idr-ix-bgp-route-server@ietf.org, The IESG , shares@ndzh.com, idr-chairs@ietf.org Message-ID: Subject: Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) References: <20160614153754.19291.870.idtracker@ietfa.amsl.com> <57602C27.10803@foobar.org> In-Reply-To: <57602C27.10803@foobar.org> --lwqRI7cAQI0i0kJJt3nGLkWxjdcdaGwtp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/14/16 9:09 AM, Nick Hilliard wrote: > Joel Jaeggli wrote: >> I'm at a bit of a loss to understand why path hiding would be a >> considered an undesirable property of an MLPE routeserver. >=20 > Because in certain circumstances, if you have two paths A and B to a > leaf node L, and path A decides to block access to L via the IXP, A's > policy action acting on the RS will also block path B. There are no > circumstances that I can imagine where this would be a desirable outcom= e. IF L is a customer of A and B sure. If it's L's policy that's doing the blocking and you're not winning unequivically on as path length due to prepending then a desired result, (not transiting the exchange) is achieved. (this isn't really hypotethtical as at least one of my transit providers has been known to leak our anycast prefixes via mlpe sesssions at an exchange where we are also present) eventually I won't use them. For me as a prefix originator, the difference is the ability to advertise prefixes on the MLPE and not, e.g. it's effectively unusable without that property. >> IMHO as an >> operator that peers on MLPE exchanges as well as bilaterally on exchan= ge >> fabrics and via PNIs. blinding a client of the MLPE which I may have = a >> session already with at the exchange or via PNI is basically mandatory= =2E >=20 > We're talking about different things here. Blinding a path by offering= > a better alternative is fine - which is, I think, what you are talking > about. Blinding a path by denying third parties a failover path is not= ok. >=20 >> Likewise without per-asn export policy at exchanges my ability to >> advertise anycast prefixes via the MLPE is basically noexistant >> >> If an IXP operator deploys a route server without >> implementing a per-client routing policy control system, then path >> hiding does not occur as all paths are considered equally valid fro= m >> the point of view of the route server. >> >> Does not seem like a particularly desirable outcome. >> >> While I'm fine with 2.3 not being normative, it does seem desirable th= at >> an MLPE service offer the client control, it greatly increases the sor= ts >> of clients that can safely use the service. >=20 > Yep, agreed. This was an issue that Geoff Huston brought up during the= > rtgdir review. His point was that a standards track document cannot > recommend a course of action which is not formally defined anywhere. A= t > the moment, neither add-path nor the multiple rib options have been > defined formally within standards track documents. So as authors we ha= d > an option of either delaying publication of this draft for an > indeterminate number of years while the multi-rib and add-path drafts > were standardized, or else mark these as non-normative for the time > being and standardise the rest of the requirements. >=20 > Given that ietf-idr-add-paths has been in the ietf process since 2002 > and it's now 2016, we figured it was probably a more practical solution= > to move ahead with this draft as-is, and if someone wants to document > multiple ribs in future, this draft can be updated. >=20 > Nick >=20 --lwqRI7cAQI0i0kJJt3nGLkWxjdcdaGwtp-- --5QE5D581A4JEBb0bt0j7mREOxxfuEgxaF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAldgMgIACgkQ8AA1q7Z/VrI20wCeMjSlraLdKEjwqQ3TO5svwiEj PpEAn3RFAfJ0Nx7orYzTxBiwUzTUSE3S =i5zO -----END PGP SIGNATURE----- --5QE5D581A4JEBb0bt0j7mREOxxfuEgxaF-- From nobody Tue Jun 14 09:52:29 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECECE12D80C; Tue, 14 Jun 2016 09:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArqQ_Ijc6tmz; Tue, 14 Jun 2016 09:52:25 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E982412D09B; Tue, 14 Jun 2016 09:52:24 -0700 (PDT) X-Envelope-To: idr-chairs@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5EGqJmT007985 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2016 17:52:20 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57603642.4000900@foobar.org> Date: Tue, 14 Jun 2016 17:52:18 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: joel jaeggli References: <20160614153754.19291.870.idtracker@ietfa.amsl.com> <57602C27.10803@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, The IESG , shares@ndzh.com, draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 16:52:27 -0000 joel jaeggli wrote: > IF L is a customer of A and B sure. you mean, if L is a downstream of A and B - not necessarily a customer. > If it's L's policy that's doing the blocking This is the point - it's not L's policy that's doing the blocking. If A blocks L's prefixes at the RS, it will block all paths, via both A and B, even though it should have no control over B's paths if it decides to take itself out of the equation. Nick From nobody Tue Jun 14 10:01:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBD012D861; Tue, 14 Jun 2016 10:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6XCq9FbvH97; Tue, 14 Jun 2016 10:01:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5624E12D85C; Tue, 14 Jun 2016 10:01:18 -0700 (PDT) Received: from mb-2.local ([IPv6:2620:11a:c081:20:7df9:7167:e9d9:6b3a]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u5EH19DI020509 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 14 Jun 2016 17:01:10 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:7df9:7167:e9d9:6b3a] claimed to be mb-2.local To: Nick Hilliard References: <20160614153754.19291.870.idtracker@ietfa.amsl.com> <57602C27.10803@foobar.org> <57603642.4000900@foobar.org> From: joel jaeggli Message-ID: <62fec2b2-355f-1f52-0313-073224cfc2d1@bogus.com> Date: Tue, 14 Jun 2016 10:01:08 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <57603642.4000900@foobar.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="knGsNBjVcK0XwDvkqr5oVLxhTcmrRlPLD" Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, The IESG , shares@ndzh.com, draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 17:01:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --knGsNBjVcK0XwDvkqr5oVLxhTcmrRlPLD Content-Type: multipart/mixed; boundary="C0n09QLDET345ps5Ra7TQMXvGmACO4ISQ" From: joel jaeggli To: Nick Hilliard Cc: idr@ietf.org, draft-ietf-idr-ix-bgp-route-server@ietf.org, The IESG , shares@ndzh.com, idr-chairs@ietf.org Message-ID: <62fec2b2-355f-1f52-0313-073224cfc2d1@bogus.com> Subject: Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) References: <20160614153754.19291.870.idtracker@ietfa.amsl.com> <57602C27.10803@foobar.org> <57603642.4000900@foobar.org> In-Reply-To: <57603642.4000900@foobar.org> --C0n09QLDET345ps5Ra7TQMXvGmACO4ISQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/14/16 9:52 AM, Nick Hilliard wrote: > joel jaeggli wrote: >> IF L is a customer of A and B sure. >=20 > you mean, if L is a downstream of A and B - not necessarily a customer.= if it's a peer we'd view either of them sending it to the exchange as a leak. The difference between in the downstream cone and customer route is defintional >> If it's L's policy that's doing the blocking >=20 > This is the point - it's not L's policy that's doing the blocking. If = A > blocks L's prefixes at the RS, it will block all paths, via both A and > B, even though it should have no control over B's paths if it decides t= o > take itself out of the equation. sure, easy enough to concede. Albiet I rather prefer to take b out of the equation when it's my prefix.= > Nick >=20 --C0n09QLDET345ps5Ra7TQMXvGmACO4ISQ-- --knGsNBjVcK0XwDvkqr5oVLxhTcmrRlPLD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAldgOFQACgkQ8AA1q7Z/VrLRMACfYO3UzCzn3rWlIujB2obEQsTJ TyYAnRDU2PsgGHycObwmGSyusa0QRUxa =O+1m -----END PGP SIGNATURE----- --knGsNBjVcK0XwDvkqr5oVLxhTcmrRlPLD-- From nobody Tue Jun 14 10:08:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5167E12D600 for ; Tue, 14 Jun 2016 10:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaFuFX8vVy5Y for ; Tue, 14 Jun 2016 10:08:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEEE12D5B5 for ; Tue, 14 Jun 2016 10:08:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bCroq-0003YJ-FD; Tue, 14 Jun 2016 17:08:04 +0000 Date: Wed, 15 Jun 2016 02:08:02 +0900 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <575FF3B9.3080501@foobar.org> References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg , Mirja Kuehlewind Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 17:08:08 -0000 > Does the proposed wording work for you? > >> While it is technically possible to operate a route server which >> prepends its own AS to the AS_PATH, it is not recommended to do so >> because creating an undesirably longer AS_PATH may adversely affect >> the resulting network topology between the route server clients. i suspect that the AD is competent to speak for herself. but imiho this misses her point, why is the SHOULD not a MUST? this says why it might be a MUST. why allow the loophole? i admit my example was baroque. randy From nobody Tue Jun 14 21:19:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14A91200A0; Tue, 14 Jun 2016 21:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvzIoMs-F35y; Tue, 14 Jun 2016 21:19:22 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CA012D0B8; Tue, 14 Jun 2016 21:19:22 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g20so9968412ywb.0; Tue, 14 Jun 2016 21:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EgrqD/kNXShhcj9nBMNBPN4EZ179xa3wkocDCuj+oJM=; b=PzECEPTvJ0gG7bqUagjtwVxZY3/gOtdj6DaTzlwN6psX7ljS/uNz1B9Qs0n8B4erGk MaT2ay2BNKKZci0XAypHD/1LIHpBub65BsMa5TgCumK5Vz/hZvFvYGYK4rBBpqNPJ0Iw WL0RXHFt1Gp9a1W+1u7LYyl92t4B/ChUMogIz6toNCP9kL3UMPJeM7wuxfxtuchtP5TJ mmFA9B8T00jlMeKOvGmuDzX68CO86moDbOrefQT3+WtbKxYqJVLf/+0Fqusmwz8ehgU3 VZmXbBDxhFohQUQzMSGIEwzHcSiTNFixH3XrHWEwbjA/SmyLLBe+H1ogdJQ28aUWzwBG bMxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EgrqD/kNXShhcj9nBMNBPN4EZ179xa3wkocDCuj+oJM=; b=ieHYCyI24QVxgSTzGt3e8Ps0p8Q2GCJUqIRDBtRC0xnPQJCXKBNiH13BuZ1jN66Kwd Tt0+W24D7udX5vOUSCYQHFdH+Yti8y0LTHBA7Q4NAhPJyOtpAREp8z8k8RmcqS4Uqyfk 7SZlY/P0tIGoSgJPO4bI/PotWnp5kA5f8t5FVbHzKEapFhE3auhPjg4g6k5uPsboYPvg slq37ZLv1ms9NZeOslwFrCRH7q1CMtOA/8IhosxGl5kA1GnOfN/SFHjefB6W4vT0UwLk hbxKJ2EbV/FsQa3S6q5gJNqSMgky5539eRnf46AICrn4QcFF553Ju3e+2DJhQyGkWBfv CfLw== X-Gm-Message-State: ALyK8tK5ZFhKXehopM2qcwGkInmnPhzAwB/Q6whxTx0KBwCtpzpHNUBan+hZRvwrHhC1zaFylLje2aVa+sF3BA== X-Received: by 10.37.116.130 with SMTP id p124mr12252536ybc.5.1465964361224; Tue, 14 Jun 2016 21:19:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.101.84 with HTTP; Tue, 14 Jun 2016 21:19:20 -0700 (PDT) In-Reply-To: <575F2704.3050509@foobar.org> References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> From: Spencer Dawkins at IETF Date: Tue, 14 Jun 2016 23:19:20 -0500 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a114da96e0117d50535496daa Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, "Mirja Kuehlewind \(IETF\)" , The IESG , Susan Hares , draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 04:19:23 -0000 --001a114da96e0117d50535496daa Content-Type: text/plain; charset=UTF-8 Hi, Nick, On Mon, Jun 13, 2016 at 4:35 PM, Nick Hilliard wrote: > Mirja Kuehlewind (IETF) wrote: > > Great! Thanks! > > this is now changed as follows: > > > > https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508 > > Nick > I had the same question as Mirja, but balloted No Objection because the discussion was already taking place in this thread. I've looked at https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508, but I'm still confused. The document defines a route server as "not a router", because it doesn't forward packets - the text is Although a route server uses BGP to exchange reachability information with each of its clients, it does not forward traffic itself and is therefore not a router. If the route server does prepend its own AS number to the AS_PATH, won't it then receive packets that it can't forward? Can you help me understand what I'm missing here? Thanks! Spencer --001a114da96e0117d50535496daa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Nick,

On Mon, Jun 13, 2016 at 4:35 PM, Nick Hilliard &= lt;nick@foobar.org= > wrote:
Mirja Kuehlewind (IETF) wrote:
> Great! Thanks!

this is now changed as follows:

> https://github.com= /fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508

Nick

I had the same quest= ion as Mirja, but balloted No Objection because the discussion was already = taking place in this thread.

I've looked at https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server= /commit/5fd0508, but I'm still confused.=C2=A0

=
The document defines a route server as "not a router", becau= se it doesn't forward packets - the text is=C2=A0

<= pre class=3D"" style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0p= x;color:rgb(0,0,0)"> Although a route= server uses BGP to exchange reachability information with each of its clients, it does not forward traffic itself and is=C2= =A0
=C2=A0 =C2=A0therefore not a router.=C2=A0

If the route server does prepend = its own AS number to the AS_PATH, won't it then receive packets that it= can't forward?

Can you help me understand wha= t I'm missing here?

Thanks!

Spencer
--001a114da96e0117d50535496daa-- From nobody Tue Jun 14 21:30:05 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079F212D0AA; Tue, 14 Jun 2016 21:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9Y6Jr4mMGFw; Tue, 14 Jun 2016 21:30:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9137312D0A1; Tue, 14 Jun 2016 21:30:02 -0700 (PDT) Received: from mb-2.local ([IPv6:2601:b00:c500:8b41:8c67:e9ca:344e:32cb]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u5F4TIhl023573 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 15 Jun 2016 04:29:19 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:b00:c500:8b41:8c67:e9ca:344e:32cb] claimed to be mb-2.local To: Spencer Dawkins at IETF , Nick Hilliard References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> From: joel jaeggli Message-ID: <3402d769-1683-5854-fdcb-295421a06f30@bogus.com> Date: Tue, 14 Jun 2016 21:29:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1kO9InqVUhLNOlIk02ooEbhis0BQUK3t1" Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, "Mirja Kuehlewind \(IETF\)" , The IESG , Susan Hares , draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 04:30:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1kO9InqVUhLNOlIk02ooEbhis0BQUK3t1 Content-Type: multipart/mixed; boundary="MXa50EWQQ7PwkQH03VDhfM8OdeAQXLGli" From: joel jaeggli To: Spencer Dawkins at IETF , Nick Hilliard Cc: idr@ietf.org, idr-chairs@ietf.org, "Mirja Kuehlewind (IETF)" , The IESG , "Alvaro Retana (aretana)" , Susan Hares , draft-ietf-idr-ix-bgp-route-server@ietf.org Message-ID: <3402d769-1683-5854-fdcb-295421a06f30@bogus.com> Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_No_Objection_on_draft-ietf-idr?= =?UTF-8?Q?-ix-bgp-route-server-11:_=28with_COMMENT=29?= References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> In-Reply-To: --MXa50EWQQ7PwkQH03VDhfM8OdeAQXLGli Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/14/16 9:19 PM, Spencer Dawkins at IETF wrote: > Hi, Nick, >=20 > On Mon, Jun 13, 2016 at 4:35 PM, Nick Hilliard > wrote: >=20 > Mirja Kuehlewind (IETF) wrote: > > Great! Thanks! >=20 > this is now changed as follows: >=20 > > > https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/comm= it/5fd0508 >=20 > Nick >=20 >=20 > I had the same question as Mirja, but balloted No Objection because the= > discussion was already taking place in this thread. >=20 > I've looked at > https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5= fd0508, > but I'm still confused.=20 >=20 > The document defines a route server as "not a router", because it > doesn't forward packets - the text is=20 >=20 > Although a route server uses BGP to exchange reachability information > with each of its clients, it does not forward traffic itself and is=20 >=20 > therefore not a router.=20 >=20 > If the route server does prepend its own AS number to the AS_PATH, won'= t > it then receive packets that it can't forward? Nah, the AS path only counts for path selection. What matters as far as forwarding goes is what the nexthop on the route is. In a normally functioning exchange the routeserver will never set itself to be the nexthop of a learned so the nexthop route will remain the originator of the route which is another router on the same (connected) subnet. Since the router(s) peering with the route-server all have the subnet/netmask configured on their connected interface, they can resolve all of the nexthops learned from the routeserver via arp. > Can you help me understand what I'm missing here? Probably that does it. > Thanks! >=20 > Spencer --MXa50EWQQ7PwkQH03VDhfM8OdeAQXLGli-- --1kO9InqVUhLNOlIk02ooEbhis0BQUK3t1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAldg2Z0ACgkQ8AA1q7Z/VrJRLgCeOsCwRa6hrQr7Wk1rm/hRZn8A oPUAnRfFv18KHwlewduswC36SQJJXmQ/ =VRbd -----END PGP SIGNATURE----- --1kO9InqVUhLNOlIk02ooEbhis0BQUK3t1-- From nobody Tue Jun 14 22:00:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4709C12B05B; Tue, 14 Jun 2016 22:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOWT8r70V6TL; Tue, 14 Jun 2016 22:00:13 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63AF912B03B; Tue, 14 Jun 2016 22:00:13 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id c72so10413551ywb.1; Tue, 14 Jun 2016 22:00: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:from:date:message-id:subject:to :cc; bh=NptP4w7RDxyfoGvHmSjE7ZsJOUbMRXGcVx8H2LmDPZU=; b=F/dc09weKkkohSAG3Ya2sMrUlVCetWNd7TmVAUsz2HwqykySsGvqentfuhZm7Y3l1z AOqUeobLCCkGukfiF8Yzqk3z6Xpz4elMYKC7dUnPR0/84gT23wJFgb4b/d9nAlxVdkWL jeUsmtKUMWecI6B3JUVUFEG/eVwSeIOzI3f6W1DOzm8Wa2y9ZLobvaKRq8SEaJKkWmsr 3CVjC9OxeQR9B5UhbzPTeX7zI1WFON7s/93piUVs/sH3mWgOYRExPQcvx6jtqkLQ5K/e 2S8m3yuPtZPl22H+/nLYsGb92i42xiPOnZOHwZ6FOA+Oe6EF+fp51GlsB3FqPjzPy0rt GEgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NptP4w7RDxyfoGvHmSjE7ZsJOUbMRXGcVx8H2LmDPZU=; b=T/H/5hANVn9aOqofQ7/ClFCX1PrQLVJ3UWMUP/twtVlZ09INo/4fVjNPSFHOHOlb6R Il7SnVz0VxPS4r4K1QUaiFqLgHoRvRJQSxIAYk+vcEIMKogWCG+f628kuyO7i1BHXVRc O0eqlR+2o8SO4jjQ/ToshJJy9Q9/0olHeaU+9RtqFJCGjHyGebLrGmcDUnQJPzociJjj cUHkl5LRwtwPqnC1x3A5My4fYscd+zzPGlC3NBegHGjsjAX/Dl3ACirtr0+6ayRkPwjT JjLJDafjyZA5MGYJY12d5b5oPh28QQJgtF/WMKZvLgYJ/kHofNXIQa3jffi0xb5tNIMP 8DUw== X-Gm-Message-State: ALyK8tItVei/mR8o7YgYFYOAgCJw3vTGmNIvMnn0a3y6TTICw/Jwd/uEICiK5BfpDiVEp6b/BuXbVJRUMwvGJg== X-Received: by 10.129.73.18 with SMTP id w18mr3920701ywa.176.1465966812407; Tue, 14 Jun 2016 22:00:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.101.84 with HTTP; Tue, 14 Jun 2016 22:00:11 -0700 (PDT) In-Reply-To: <3402d769-1683-5854-fdcb-295421a06f30@bogus.com> References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <3402d769-1683-5854-fdcb-295421a06f30@bogus.com> From: Spencer Dawkins at IETF Date: Wed, 15 Jun 2016 00:00:11 -0500 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=001a114dae4a1b325b053549ff5c Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, "Mirja Kuehlewind \(IETF\)" , The IESG , Susan Hares , draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 05:00:15 -0000 --001a114dae4a1b325b053549ff5c Content-Type: text/plain; charset=UTF-8 Joel, On Tue, Jun 14, 2016 at 11:29 PM, joel jaeggli wrote: > On 6/14/16 9:19 PM, Spencer Dawkins at IETF wrote: > > Hi, Nick, > > > > On Mon, Jun 13, 2016 at 4:35 PM, Nick Hilliard > > wrote: > > > > Mirja Kuehlewind (IETF) wrote: > > > Great! Thanks! > > > > this is now changed as follows: > > > > > > > > https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508 > > > > Nick > > > > > > I had the same question as Mirja, but balloted No Objection because the > > discussion was already taking place in this thread. > > > > I've looked at > > > https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508 > , > > but I'm still confused. > > > > The document defines a route server as "not a router", because it > > doesn't forward packets - the text is > > > > Although a route server uses BGP to exchange reachability information > > with each of its clients, it does not forward traffic itself and is > > > > therefore not a router. > > > > If the route server does prepend its own AS number to the AS_PATH, won't > > it then receive packets that it can't forward? > > Nah, the AS path only counts for path selection. What matters as far as > forwarding goes is what the nexthop on the route is. > > In a normally functioning exchange the routeserver will never set itself > to be the nexthop of a learned so the nexthop route will remain the > originator of the route which is another router on the same (connected) > subnet. Since the router(s) peering with the route-server all have the > subnet/netmask configured on their connected interface, they can resolve > all of the nexthops learned from the routeserver via arp. > > > Can you help me understand what I'm missing here? > > Probably that does it. Thanks - it does. Spencer > > Thanks! > > > > Spencer > > > --001a114dae4a1b325b053549ff5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joel,

On Tue, Jun 14, 2016 at 11:29 PM, joel jaeggli <<= a href=3D"mailto:joelja@bogus.com" target=3D"_blank">joelja@bogus.com&g= t; wrote:
On 6/14= /16 9:19 PM, Spencer Dawkins at IETF wrote:
> Hi, Nick,
>
> On Mon, Jun 13, 2016 at 4:35 PM, Nick Hilliard <nick@foobar.org
> <mailto:= nick@foobar.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Mirja Kuehlewind (IETF) wrote:
>=C2=A0 =C2=A0 =C2=A0> Great! Thanks!
>
>=C2=A0 =C2=A0 =C2=A0this is now changed as follows:
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0= 508
>
>=C2=A0 =C2=A0 =C2=A0Nick
>
>
> I had the same question as Mirja, but balloted No Objection because th= e
> discussion was already taking place in this thread.
>
> I've looked at
> https://github.com= /fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508,
> but I'm still confused.
>
> The document defines a route server as "not a router", becau= se it
> doesn't forward packets - the text is
>
> Although a route server uses BGP to exchange reachability information<= br> > with each of its clients, it does not forward traffic itself and is >
>=C2=A0 =C2=A0 therefore not a router.
>
> If the route server does prepend its own AS number to the AS_PATH, won= 't
> it then receive packets that it can't forward?

Nah, the AS path only counts for path selection. What matters as far= as
forwarding goes is what the nexthop on the route is.

In a normally functioning exchange the routeserver will never set itself to be the nexthop of a learned so the nexthop route will remain the
originator of the route which is another router on the same (connected)
subnet. Since the router(s) peering with the route-server all have the
subnet/netmask configured on their connected interface, they can resolve all of the nexthops learned from the routeserver via arp.

> Can you help me understand what I'm missing here?

Probably that does it.

Thanks - it d= oes.

Spencer
=C2=A0
> Thanks!
>
> Spencer



--001a114dae4a1b325b053549ff5c-- From nobody Wed Jun 15 00:13:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D50512D0B2; Wed, 15 Jun 2016 00:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsO3fLWWk-NR; Wed, 15 Jun 2016 00:13:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E304712D097; Wed, 15 Jun 2016 00:13:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bD50g-0005fK-G9; Wed, 15 Jun 2016 07:13:10 +0000 Date: Wed, 15 Jun 2016 16:13:07 +0900 Message-ID: From: Randy Bush To: Spencer Dawkins at IETF In-Reply-To: References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, "Mirja Kuehlewind \(IETF\)" , The IESG , Susan Hares , draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 07:13:22 -0000 > If the route server does prepend its own AS number to the AS_PATH, won't it > then receive packets that it can't forward? AS numbers and AS_PATHs are not used for forwarding. randy From nobody Wed Jun 15 02:31:45 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C80C12D09D; Wed, 15 Jun 2016 02:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD2mylSyAFQj; Wed, 15 Jun 2016 02:31:38 -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 B712112B028; Wed, 15 Jun 2016 02:31:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQV60413; Wed, 15 Jun 2016 09:31:34 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 15 Jun 2016 10:31:33 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.42]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Wed, 15 Jun 2016 17:31:25 +0800 From: Mach Chen To: "draft-ietf-idr-bgp-gr-notification@tools.ietf.org" , Susan Hares , "'John G. Scudder'" Thread-Index: AdHG6K7G5p6rjU2XRv2Es7cAWu69lw== Date: Wed, 15 Jun 2016 09:31:24 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57612077.0121, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.42, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1b6808299cd8da34f654ee2b6a1d794a Archived-At: Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , "idr@ietf.org" , "Zhangxian \(Xian\)" , "rtg-ads@tools.ietf.org" Subject: [Idr] (no subject) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 09:31:40 -0000 Hi Authors, I was assigned to do a QA review on draft-ietf-idr-bgp-gr-notification-07. = For more detail what's is RtgDir QA review, please refer to https://trac.to= ols.ietf.org/area/rtg/trac/wiki/RtgDirDocQa=20 Overall, the document is well-written and clear, after review, I have the f= ollowing comments.=20 1. Abstract s/BGP NOTIFICATION Message/ BGP NOTIFICATION message; 2. Section 2: " 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" (which was defined in a previous draft version of this specification) is deprecated. This bit MUST be advertised as 0 and MUST be ignored upon receipt. " The "N" bit was firstly introduced in a previous version of this document, = but deprecated in later version. I don't understand why a document need dep= recate a functionality introduced by itself, why not just remove it? If we = really want to keep this history, maybe a better way is to move above text = to an appendix. =20 If you agree above, then the last sentence of the first paragraph of sectio= n 2 should be changed as bellow: OLD: "the Restart flags field and the Flags field for Address Family are augment= ed as follows:" New: "the Restart flags field are augmented as follows:" 3. Section 3.1 "Subcode is a BGP Error Subcode (as documented in the IANA BGP Error Subcodes registry) as appropriate for the ErrCode. Similarly, Data is as appropriate for the ErrCode and Subcode." This is just an introduction to the Subcode itself, it's better to explicit= ly state that the subcode should be set to the Hard Reset (9). Hope you find above review useful. Best regards, Mach=20 From nobody Wed Jun 15 02:42:23 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A0212D0FE; Wed, 15 Jun 2016 02:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3ZL54iGy05i; Wed, 15 Jun 2016 02:42: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 9E12012D09D; Wed, 15 Jun 2016 02:33:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLZ50081; Wed, 15 Jun 2016 09:33:32 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 15 Jun 2016 10:33:31 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.42]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Wed, 15 Jun 2016 17:33:22 +0800 From: Mach Chen To: "draft-ietf-idr-bgp-gr-notification@tools.ietf.org" , Susan Hares , "'John G. Scudder'" Thread-Topic: RtgDir QA review on draft-ietf-idr-bgp-gr-notification-07 Thread-Index: AdHG6PR/x2LfjUXuTCG85tlH1QdySg== Date: Wed, 15 Jun 2016 09:33:21 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.576120ED.0151, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.42, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 374cfd1819078a730277bfa8be34444d Archived-At: Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , "idr@ietf.org" , "Zhangxian \(Xian\)" , "rtg-ads@tools.ietf.org" Subject: [Idr] RtgDir QA review on draft-ietf-idr-bgp-gr-notification-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 09:42:21 -0000 Hi Authors, I was assigned to do a QA review on draft-ietf-idr-bgp-gr-notification-07. = For more detail what's is RtgDir QA review, please refer to https://trac.to= ols.ietf.org/area/rtg/trac/wiki/RtgDirDocQa=20 Overall, the document is well-written and clear, after review, I have the f= ollowing comments.=20 1. Abstract s/BGP NOTIFICATION Message/ BGP NOTIFICATION message; 2. Section 2: " 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" (which was defined in a previous draft version of this specification) is deprecated. This bit MUST be advertised as 0 and MUST be ignored upon receipt. " The "N" bit was firstly introduced in a previous version of this document, = but deprecated in later version. I don't understand why a document need dep= recate a functionality introduced by itself, why not just remove it? If we = really want to keep this history, maybe a better way is to move above text = to an appendix. =20 If you agree above, then the last sentence of the first paragraph of sectio= n 2 should be changed as bellow: OLD: "the Restart flags field and the Flags field for Address Family are augment= ed as follows:" New: "the Restart flags field are augmented as follows:" 3. Section 3.1 "Subcode is a BGP Error Subcode (as documented in the IANA BGP Error Subcodes registry) as appropriate for the ErrCode. Similarly, Data is as appropriate for the ErrCode and Subcode." This is just an introduction to the Subcode itself, it's better to explicit= ly state that the subcode should be set to the Hard Reset (9). Hope you find above review useful. Best regards, Mach From nobody Wed Jun 15 07:32:34 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CACB12D692 for ; Wed, 15 Jun 2016 07:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1jpbiFkUqX2 for ; Wed, 15 Jun 2016 07:32:32 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1716412D669 for ; Wed, 15 Jun 2016 07:32:31 -0700 (PDT) Received: by seele.lamehost.it (Postfix, from userid 33) id 5A029744A7; Wed, 15 Jun 2016 16:32:29 +0200 (CEST) To: Randy Bush X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 15 Jun 2016 16:32:29 +0200 From: Marco Marzetti In-Reply-To: References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> Message-ID: X-Sender: marco@lamehost.it User-Agent: Roundcube Webmail/1.1.5 Archived-At: Cc: idr wg , Robert Raszuk Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:32:34 -0000 On 2016-06-14 06:28, Randy Bush wrote: >> Let's observe that nothing prevents such "one" to extend it's inbound >> AS_PATH for nets he learns from RS with additional AS to make it less >> preffered ... without any special action to be taken by RS itself. >>>> i think what might be said is "creating an undesirably longer >>>> AS_PATH" >>>> and thus biasing receivers against using the exchange. >>> >>> my bad (trans-pac and not enough coffee). we're discussing the >>> opposite, why one might want the RS to have an AS in my path. well, >>> to >>> me it would be because i have one a path directly from peer and one >>> via >>> the RS. i would prefer the former. see draft-ietf-idr-rs-bfd-01.txt >>> for why i kinda like to know layer two is up. > > and the sender can prepend when sending to the RS. and and and. the > point is not to explore all possible hacks, but to explain why this > SHOULD is not a MUST. > > life can be simple. I raised the same question a few weeks ago on this list. The answer was: because you can never know and IDR should always address all the possible cases. My opinion is that this brings more problems than benefits (because stupid people do stupid things), but i think that the new lines make it clear enough that adding the ASn of the RS in the AS_PATH is a very bad idea. -- Marco From nobody Wed Jun 15 07:40:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3516812D747 for ; Wed, 15 Jun 2016 07:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndpB-DJAWC-W for ; Wed, 15 Jun 2016 07:40:14 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C848A12D734 for ; Wed, 15 Jun 2016 07:40:13 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id a186so20061229qkf.0 for ; Wed, 15 Jun 2016 07:40:13 -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:from:date:message-id :subject:to:cc; bh=KWd02zomezfLXohQfn8QsnkAsEY0tkKGKNEmz8s8W8M=; b=BlhdFj0MUOQOsE3aOU1alUghc165a9Zup/eDleUMJFrWPJ5l0cvuxG7iZkbpluQ6Rk UvJxLYs/DXiSSEDRe0Dlh5XijvNYzFzne39rdrglxJlu2ybMnobGYJxvJY/DMuhkW9KW W35ImQrfhLtHW8kuZOzi4q1b6X0BW0x9tXiRqK1AXRTHRT1rcmuhnR4Il6tzZYlZuAQt uLANCU7TkrzBDX/vt66oIzMSlW/2i6iPBNpc/vwrWxXyDY8isU/oN8bNjk7ZuRwOk7Ys QF7wc1PJWRtGNeRHq3MQj4nxyIoQbmQmOrtlmzdAhHK0RRWnbXTGHHlNELboI6gQuf// nUjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KWd02zomezfLXohQfn8QsnkAsEY0tkKGKNEmz8s8W8M=; b=hyXsOzlwwQgLhngnAkACyYYOewYFUpqRm/yoL94ujWxa/50+Bwvn1wL0Spy3ZnFpyn iTqWp69Bxq7AApOl59rEnmW3kir26zdXa7N9YpI9vkMeOr2PTi1w1z52DO7vrXPjC7gb gOHmIC17SBNpEU8BGQpV/GMbBGjflDAiOdcaKPuE6EDUVj7uc2C+iUmv2O+QPAnQSyGx yRuIEP0hLb7LbOPS2zzf7/2lUnhiaGdEm0IATFwFC9DeMCGq3qwG+FY4WMg2e6N9St8r jKsMomGs0AeVsIrLxeoEB9oVwV+rPbFPMBIdpgaN5mUij0GBFtWsVppWxz65Skzvkm40 jhfA== X-Gm-Message-State: ALyK8tJpKeLqllJZUidfKRMNeEnSw00/paC5yB5+k9ZjiqeDpi/y8fOWiVrLyARR8Dfc7GrBzuXIeD/0FoPCpQ== X-Received: by 10.13.207.129 with SMTP id r123mr5953666ywd.274.1466001612763; Wed, 15 Jun 2016 07:40:12 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.129.146.130 with HTTP; Wed, 15 Jun 2016 07:40:12 -0700 (PDT) In-Reply-To: References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> From: Christopher Morrow Date: Wed, 15 Jun 2016 10:40:12 -0400 X-Google-Sender-Auth: QFA-02l5ANV2Uv2LkN0X-ms86TM Message-ID: To: Marco Marzetti Content-Type: multipart/alternative; boundary=001a114e68865e7a4605355219d1 Archived-At: Cc: idr wg , Robert Raszuk Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:40:18 -0000 --001a114e68865e7a4605355219d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 15, 2016 at 10:32 AM, Marco Marzetti wrote: > but i think that the new lines make it clear enough that adding the ASn o= f > the RS in the AS_PATH is a very bad idea. =E2=80=8Bso... for clarity... 'very bad idea', isn't really right. It's inconvenient, and a change in behaviour of a running RS would be chaotic/painful/etc, but .. if you knew going into the RS connection/process that this was the case you could adjust for it. Admittedly it's painful, but it's not 'very bad idea', like 'our rs only does eigrp!' (or similar tomfoolery). We should be careful about overly hyperbolic phrasing, I think.=E2=80=8B --001a114e68865e7a4605355219d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jun 15, 2016 at 10:32 AM, Marco Marzetti <marco@lamehost.it>= ; wrote:
but i think that the new = lines make it clear enough that adding the ASn of the RS in the AS_PATH is = a very bad idea.

=E2=80=8Bso... for clarity... 'very bad idea',= isn't really right. It's inconvenient, and a change in behaviour o= f a running RS would =C2=A0be chaotic/painful/etc, but .. if you knew going= into the RS connection/process that this was the case you could adjust for= it.

=
Admittedly it's = painful, but it's not 'very bad idea', like 'our rs only do= es eigrp!' (or similar tomfoolery). We should be careful about overly h= yperbolic phrasing, I think.=E2=80=8B

--001a114e68865e7a4605355219d1-- From nobody Wed Jun 15 07:53:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B47C12D10E; Wed, 15 Jun 2016 07:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPCd9GEuQ_Bb; Wed, 15 Jun 2016 07:53:19 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E725E12D0C0; Wed, 15 Jun 2016 07:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=566; q=dns/txt; s=iport; t=1466002399; x=1467211999; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=guGcBDRFJGB/mWeWOgOoz5g4KHd4ZqtfgW7ELGgYAqM=; b=kPU2F1F2ifA6GKkwNdFgZaeviZblaQH84cLEms6RJ4V4V4lMR51Kf3kv +H2RR4bTJIlbKuoT6THVYNrs0KlUSv/FbDHN0ndcz4NcUj9NNTXfVdHRd X935JjTv6u98B7p+KkdSfzYh8YxkU5iYomtqKxAyq7ASayGVybgYTJJ2K k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgBQa2FX/51dJa1dgz6BUwa4V4IPg?= =?us-ascii?q?XmGFwKBMTgUAQEBAQEBAWUnhEwBAQQ6PxACAQg2EDIlAgQBDQUbiBW/GwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARyGJ4RNhCqFcQEEk0SFJQGOKIFTjU+PcwEeNoI6g?= =?us-ascii?q?TVuiQl/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,476,1459814400"; d="scan'208";a="284092571" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 14:53:18 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u5FErIJg005463 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2016 14:53:18 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Jun 2016 09:53:17 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 15 Jun 2016 09:53:17 -0500 From: "Alvaro Retana (aretana)" To: Nick Hilliard , Joel Jaeggli Thread-Topic: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) Thread-Index: AQHRxlK4BlmFtbG8c0mpsfV8+gQKLZ/pdViAgAEpSQA= Date: Wed, 15 Jun 2016 14:53:17 +0000 Message-ID: References: <20160614153754.19291.870.idtracker@ietfa.amsl.com> <57602C27.10803@foobar.org> In-Reply-To: <57602C27.10803@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.250.152] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "idr-chairs@ietf.org" , The IESG , "shares@ndzh.com" , "draft-ietf-idr-ix-bgp-route-server@ietf.org" Subject: Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:53:20 -0000 On 6/14/16, 11:09 AM, "iesg on behalf of Nick Hilliard" wrote: Nick: Hi! >Given that ietf-idr-add-paths has been in the ietf process since 2002 >and it's now 2016, we figured it was probably a more practical solution >to move ahead with this draft as-is, and if someone wants to document >multiple ribs in future, this draft can be updated. :-) FYI.. draft-ietf-idr-add-paths is already in the RFC Editor's queue, so it'll most likely be published as an RFC before this document. Alvaro. From nobody Wed Jun 15 07:54:53 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C1312D839 for ; Wed, 15 Jun 2016 07:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A08XPgvFJ1tK for ; Wed, 15 Jun 2016 07:54:48 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088AE12D82C for ; Wed, 15 Jun 2016 07:54:41 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5FEsY8V058185 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 15:54:35 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <57616C29.1010404@foobar.org> Date: Wed, 15 Jun 2016 15:54:33 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Alvaro Retana (aretana)" References: <20160614153754.19291.870.idtracker@ietfa.amsl.com> <57602C27.10803@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "idr@ietf.org" , "idr-chairs@ietf.org" , Joel Jaeggli , The IESG , "shares@ndzh.com" , "draft-ietf-idr-ix-bgp-route-server@ietf.org" Subject: Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:54:50 -0000 Alvaro Retana (aretana) wrote: >> Given that ietf-idr-add-paths has been in the ietf process since 2002 >> and it's now 2016, we figured it was probably a more practical solution >> to move ahead with this draft as-is, and if someone wants to document >> multiple ribs in future, this draft can be updated. > > :-) > > FYI.. draft-ietf-idr-add-paths is already in the RFC Editor's queue, so > it'll most likely be published as an RFC before this document. Hopefully! The most widely-used workaround - multiple RIBs - has never been defined anywhere :-( Nick From nobody Wed Jun 15 08:01:08 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB7812D78F; Wed, 15 Jun 2016 08:01:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615150104.20296.66089.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 08:01:04 -0700 Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, shares@ndzh.com, draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: [Idr] Benoit Claise's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:01:04 -0000 Benoit Claise has entered the following ballot position for draft-ietf-idr-ix-bgp-route-server-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >From an operational point of view, when an ISP wants to go change from bilateral interconnections to the multilateral interconnection within one IXP, is this correct to say that all bilateral interconnections should be removed? So that basically the ISP must chose between the two models, and not combined them? If this is the case, it should be mentioned. I thought it was clear to me until I saw figure 1: The dotted line is the IXP or the IXP Route Server? At first glance, I thought that it was the IXP and that AS1 was connected to the IXP Route Server while still having a bilateral connection with AS4. I hope now that the dotted line is the IXP Route Server, otherwise I've confused. From nobody Wed Jun 15 08:04:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6002712D836; Wed, 15 Jun 2016 08:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfcBLxaupUkQ; Wed, 15 Jun 2016 08:04:03 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE92C12D807; Wed, 15 Jun 2016 08:04:02 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id j7so16234912lfg.1; Wed, 15 Jun 2016 08:04: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:from:date:message-id :subject:to:cc; bh=UAxs354tdXaqyzthGGN6LQTDslgdnbAq8ZUdvOCKXm8=; b=y0wpn6z+laFKAYg7gKahxrbi0m0CTC7fsJ8eqcUButdpeMiCHQ9ARAGKDV/c2aCF25 wIQY6oC1AaIF2hRFT6vEzHPCIuHGaZ3aFAXIUG8MJ+bdhuIyH43Y2Y4j1vn9ggIx6+E+ rTmdCGoaObHzU4zlKefJSFbrr21G4W4KSpbHJzNtBWUj0O5Gu8UVVr/qW8/SpQ3TM/V4 nWb1rWmZrzg6yD42V5sDEnO1QkCwo7uO4MYHld7xzNfF/QHhyJRrglnbVffThyKXYze1 m9wTF1HmLvSU6bmojRSXpr8hcl9L97N4S4M7XnPqKWjSDa8kXsPI92OcYXJtyv+C0WEQ ohlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UAxs354tdXaqyzthGGN6LQTDslgdnbAq8ZUdvOCKXm8=; b=bNGYSd/RAYTBXxNnOxKWubi3ZBS+Wj8tE1KRmL5c04ZAxhFwuAiPNbMxEHz5jxY8QL zsTWaf4oksMySvTkDx4bVueUe2/z/tz0cwwKUQlfaTQPvZd7ApI8PauEpfVbwL8Fgpn3 Le0rF7jE1o6mJ+0nXGIfgWVfwzX35+OljFQsEfvo3J6BX1AmmQhUSvmgLN8EW3BCdIB5 ipe9V9WZx11YAiYE6yeHBmHsNt9BKfD/D1tUPKMeWtQ4M5Hu8eccWJOcUkWhSRVptKjR 1v/pw/VH8izUEa04y+nyfwki+D96DOKlCH8nYBb3zaR4P8+3Gb0YNHNblH8c24Z53xe6 QY/Q== X-Gm-Message-State: ALyK8tIVDnDsz15OR3h8JkBRRzLk94PQwRvFEWwdfmoirOo8uSXN4ieqa+Df2rwUWvLRhM8PzWl/+sqB+yXe9A== X-Received: by 10.46.32.223 with SMTP id g92mr7142837lji.32.1466003040925; Wed, 15 Jun 2016 08:04:00 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Wed, 15 Jun 2016 08:04:00 -0700 (PDT) In-Reply-To: <20160615150104.20296.66089.idtracker@ietfa.amsl.com> References: <20160615150104.20296.66089.idtracker@ietfa.amsl.com> From: Robert Raszuk Date: Wed, 15 Jun 2016 17:04:00 +0200 X-Google-Sender-Auth: 5P-DesrFw7hQM0AaEEUl-WlEf1Q Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=001a1146a90a7e7d3c0535526e52 Archived-At: Cc: idr wg , idr-chairs@ietf.org, The IESG , Susan Hares , draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] Benoit Claise's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:04:09 -0000 --001a1146a90a7e7d3c0535526e52 Content-Type: text/plain; charset=UTF-8 Benoit, > IXP, is this correct to say that all bilateral interconnections should be removed? Not really. It is quite common to see IX participants having direct peerings as well as peerings via RS. All is driven by BGP policies both at the peering routers directly as well as on the RS. Thx, R. On Wed, Jun 15, 2016 at 5:01 PM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-idr-ix-bgp-route-server-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > >From an operational point of view, when an ISP wants to go change from > bilateral interconnections to the multilateral interconnection within one > IXP, is this correct to say that all bilateral interconnections should be > removed? > So that basically the ISP must chose between the two models, and not > combined them? If this is the case, it should be mentioned. > I thought it was clear to me until I saw figure 1: The dotted line is the > IXP or the IXP Route Server? > At first glance, I thought that it was the IXP and that AS1 was connected > to the IXP Route Server while still having a bilateral connection with > AS4. > I hope now that the dotted line is the IXP Route Server, otherwise I've > confused. > > > --001a1146a90a7e7d3c0535526e52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Benoit,


> IXP, is this correct to say that= all bilateral interconnections should be=C2=A0removed?
Not really. It is quite common to see IX participants h= aving direct peerings as well as peerings via RS. All is driven by BGP poli= cies both at the peering routers directly as well as on the RS.

Thx,
R.
<= br>

On Wed, Jun 15, 2016 at 5:01 PM, Benoit Claise <<= a href=3D"mailto:bclaise@cisco.com" target=3D"_blank">bclaise@cisco.com= > wrote:
Benoit Claise has ente= red the following ballot position for
draft-ietf-idr-ix-bgp-route-server-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-idr-ix-bgp-route-server/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

>From an operational point of view, when an ISP wants to go change from<= br> bilateral interconnections to the multilateral interconnection within one IXP, is this correct to say that all bilateral interconnections should be removed?
So that basically the ISP must chose between the two models, and not
combined them? If this is the case, it should be mentioned.
I thought it was clear to me until I saw figure 1: The dotted line is the IXP or the IXP Route Server?
At first glance, I thought that it was the IXP and that AS1 was connected to the IXP Route Server while still having a bilateral connection with
AS4.
I hope now that the dotted line is the IXP Route Server, otherwise I've=
confused.



--001a1146a90a7e7d3c0535526e52-- From nobody Wed Jun 15 08:16:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03BE12D8A7; Wed, 15 Jun 2016 08:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PN-9JO7bsIk; Wed, 15 Jun 2016 08:16:13 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99FF12D883; Wed, 15 Jun 2016 08:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2607; q=dns/txt; s=iport; t=1466003772; x=1467213372; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r3rfAcg8xdyqy/jmxI3z3diomC0HhdtUv7LQqOZ/9KM=; b=fPnXwluU3yYyowJKhgUfW4T6rGb88Y6hrXkE77wN1JFkzURe1vxF4MPC TUqz1Pz5yHNOlUd72xygoBLJgy8g1BVtiMvlbLn5MUWNCjKZhhn/gyQCh t+HOfL5PyUCF5Yix96Bbj8mMQzTEp3k29FqzCRhNk9B0wQgiHABG1gveW A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgD4b2FX/5tdJa1dgnBOgVMGrmSHA?= =?us-ascii?q?YJygg+BeYYXAoExOBQBAQEBAQEBZSeETAEBBHkQAgEIBDsHIREUEQIEAQ0FiBY?= =?us-ascii?q?DF7spDYNzAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYnhE2CQ4FnhXEFk0SEcTQBj?= =?us-ascii?q?C6Beo8iiAeHbAEeNoI6gTVuiQl/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,476,1459814400"; d="scan'208,217";a="285290378" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 15:16:11 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5FFGBTM007905 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2016 15:16:11 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Jun 2016 10:16:11 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 15 Jun 2016 10:16:11 -0500 From: "Alvaro Retana (aretana)" To: Robert Raszuk , "Benoit Claise (bclaise)" Thread-Topic: Benoit Claise's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) Thread-Index: AQHRxxbEEW4JkdwiT0G+NRH0/upASZ/q8+8A//+vjQA= Date: Wed, 15 Jun 2016 15:16:11 +0000 Message-ID: References: <20160615150104.20296.66089.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.250.152] Content-Type: multipart/alternative; boundary="_000_D386DB2612E3F0aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg , "idr-chairs@ietf.org" , The IESG , Susan Hares , "draft-ietf-idr-ix-bgp-route-server@ietf.org" Subject: Re: [Idr] Benoit Claise's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:16:14 -0000 --_000_D386DB2612E3F0aretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 6/15/16, 10:04 AM, "rraszuk@gmail.com on behal= f of Robert Raszuk" on behalf = of robert@raszuk.net> wrote: It is quite common to see IX participants having direct peerings as well as= peerings via RS. All is driven by BGP policies both at the peering routers= directly as well as on the RS. Agreed. To Benoit's point, it would be nice to clarify the meaning of the = different line types in Figure 1, and not leave it up to interpretation. Thanks! Alvaro. --_000_D386DB2612E3F0aretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On 6/15/16, 10:04 AM, "rrasz= uk@gmail.com on behalf of Robert Raszuk" <rraszuk@gmail.com on behalf of robert@raszuk.net> wrote:

I= t is quite common to see IX participants having direct peerings as well as p= eerings via RS. All is driven by BGP policies both at the peering routers d= irectly as well as on the RS.

Agreed.  To Benoit's point, it would be nice to clarify the meani= ng of the different line types in Figure 1, and not leave it up to interpre= tation.

Thanks!

Alvaro.
--_000_D386DB2612E3F0aretanaciscocom_-- From nobody Wed Jun 15 08:16:54 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B37A12D89F; Wed, 15 Jun 2016 08:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul52kznhrfL1; Wed, 15 Jun 2016 08:16:45 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D5812D883; Wed, 15 Jun 2016 08:16:44 -0700 (PDT) Received: from mb-2.local ([8.18.217.194]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u5FFGe0K026822 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 15 Jun 2016 15:16:40 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [8.18.217.194] claimed to be mb-2.local To: Robert Raszuk , Benoit Claise References: <20160615150104.20296.66089.idtracker@ietfa.amsl.com> From: joel jaeggli Message-ID: Date: Wed, 15 Jun 2016 08:16:41 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3JMixVoPRctxHjfoSBWgTPTO89xW6IOxv" Archived-At: Cc: idr wg , idr-chairs@ietf.org, The IESG , Susan Hares , draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] Benoit Claise's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:16:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3JMixVoPRctxHjfoSBWgTPTO89xW6IOxv Content-Type: multipart/mixed; boundary="lmKWrTphmNpACabk7gWt5uDeRJEfwaAnU" From: joel jaeggli To: Robert Raszuk , Benoit Claise Cc: idr wg , idr-chairs@ietf.org, The IESG , "Alvaro Retana (aretana)" , warren kumari , Susan Hares , draft-ietf-idr-ix-bgp-route-server@ietf.org Message-ID: Subject: Re: Benoit Claise's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) References: <20160615150104.20296.66089.idtracker@ietfa.amsl.com> In-Reply-To: --lmKWrTphmNpACabk7gWt5uDeRJEfwaAnU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/15/16 8:04 AM, Robert Raszuk wrote: > Benoit, >=20 >=20 >> IXP, is this correct to say that all bilateral interconnections should= be removed? >=20 > Not really. It is quite common to see IX participants having direct > peerings as well as peerings via RS. All is driven by BGP policies both= > at the peering routers directly as well as on the RS. When networks grow and add multiple ports to an IX it is common to migrate neighbors from the mlpe to blp sessions in part so you have better coordination and control (the hidden route problem again, also it unreasonable to expect routes learned via the route servers to load balance between ports etc). So in fact both styles will almost always be well represented on an exchange, with the cavaet that the more restrictive your peering policy is the less likely you are to appear on or accept routes from the mlpe. > Thx, > R. >=20 >=20 > On Wed, Jun 15, 2016 at 5:01 PM, Benoit Claise > wrote: >=20 > Benoit Claise has entered the following ballot position for > draft-ietf-idr-ix-bgp-route-server-11: No Objection >=20 > When responding, please keep the subject line intact and reply to a= ll > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here:= > https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server= / >=20 >=20 >=20 > -------------------------------------------------------------------= --- > COMMENT: > -------------------------------------------------------------------= --- >=20 > >From an operational point of view, when an ISP wants to go change = from > bilateral interconnections to the multilateral interconnection > within one > IXP, is this correct to say that all bilateral interconnections > should be > removed? > So that basically the ISP must chose between the two models, and no= t > combined them? If this is the case, it should be mentioned. > I thought it was clear to me until I saw figure 1: The dotted line > is the > IXP or the IXP Route Server? > At first glance, I thought that it was the IXP and that AS1 was > connected > to the IXP Route Server while still having a bilateral connection w= ith > AS4. > I hope now that the dotted line is the IXP Route Server, otherwise = I've > confused. >=20 >=20 >=20 --lmKWrTphmNpACabk7gWt5uDeRJEfwaAnU-- --3JMixVoPRctxHjfoSBWgTPTO89xW6IOxv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAldhcVkACgkQ8AA1q7Z/VrKLugCfTquGuAQvutH+S8Jcp5hRIeA2 flwAn27Ab/bRVLzNKoAvrjcntDyWNoOn =P9tp -----END PGP SIGNATURE----- --3JMixVoPRctxHjfoSBWgTPTO89xW6IOxv-- From nobody Wed Jun 15 09:13:59 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B4B12D790; Wed, 15 Jun 2016 09:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzsneBqPN5nC; Wed, 15 Jun 2016 09:13:48 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0A612D8EB; Wed, 15 Jun 2016 09:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3597; q=dns/txt; s=iport; t=1466007226; x=1467216826; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=shecUaSUbDfAYAWC4uhzdPmd1kK72c+dxLrDycJ+UiQ=; b=NEihUIO24ip5DlPXLxt8xsBEu4zz3oKSkgfVskDI5F2woJOPTo4hqCAb 0bjE7P7ZsweO0cEHs2zduD/a7AZonNfiiGc9tTp2tny3zuSr15/LNoKts MEjuvL/+F/TyUNkkXg8XTqnpla0YXumcZa2J4jlf2dico6HtASWkFu3Zg M=; X-IronPort-AV: E=Sophos;i="5.26,476,1459814400"; d="scan'208,217";a="638034633" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 16:13:44 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5FGDiiP028135; Wed, 15 Jun 2016 16:13:44 GMT To: "Alvaro Retana (aretana)" , Robert Raszuk References: <20160615150104.20296.66089.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <2bdc68fc-2c4c-ac3f-a970-0a12c3cb1778@cisco.com> Date: Wed, 15 Jun 2016 18:13:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8C3AD13072818DDD839C677A" Archived-At: Cc: idr wg , "idr-chairs@ietf.org" , The IESG , Susan Hares , "draft-ietf-idr-ix-bgp-route-server@ietf.org" Subject: Re: [Idr] Benoit Claise's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 16:13:50 -0000 This is a multi-part message in MIME format. --------------8C3AD13072818DDD839C677A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 6/15/2016 5:16 PM, Alvaro Retana (aretana) wrote: > On 6/15/16, 10:04 AM, "rraszuk@gmail.com on > behalf of Robert Raszuk" > on behalf of robert@raszuk.net > wrote: > > It is quite common to see IX participants having direct peerings > as well as peerings via RS. All is driven by BGP policies both at > the peering routers directly as well as on the RS. > > > Agreed. To Benoit's point, it would be nice to clarify the meaning of > the different line types in Figure 1, and not leave it up to > interpretation. Yes, and a sentence stressing that mlpe and blp sessions are not inconsistent in an IXP would be useful IMO. Regards, Benoit > > Thanks! > > Alvaro. > . --------------8C3AD13072818DDD839C677A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 6/15/2016 5:16 PM, Alvaro Retana (aretana) wrote:
On 6/15/16, 10:04 AM, "rraszuk@gmail.com on behalf of Robert Raszuk" <rraszuk@gmail.com on behalf of robert@raszuk.net> wrote:

It is quite common to see IX participants having direct peerings as well as peerings via RS. All is driven by BGP policies both at the peering routers directly as well as on the RS.

Agreed.  To Benoit's point, it would be nice to clarify the meaning of the different line types in Figure 1, and not leave it up to interpretation.
Yes, and a sentence stressing that mlpe and blp sessions are not inconsistent in an IXP would be useful IMO.

Regards, Benoit

Thanks!

Alvaro.
.

--------------8C3AD13072818DDD839C677A-- From nobody Wed Jun 15 13:23:24 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0762112D5D1; Wed, 15 Jun 2016 13:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLNF98iX7m4O; Wed, 15 Jun 2016 13:23:19 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AFA12D61B; Wed, 15 Jun 2016 13:23:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=210.255.219.250; From: "Susan Hares" To: "'Mach Chen'" , , "'John G. Scudder'" Date: Wed, 15 Jun 2016 16:22:55 -0400 Message-ID: <04ee01d1c743$b50c6640$1f2532c0$@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: AdHHQ6WVSH/gkUU0QaGMk9Q8aQOyzA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jonathan Hardwick' , rtg-dir@ietf.org, idr@ietf.org, "'Zhangxian \(Xian\)'" , rtg-ads@tools.ietf.org Subject: Re: [Idr] draft-ietf-bgp-gr-notification-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:23:21 -0000 Mach: Thank you for reviewing draft-ietf-bgp-gr-notification-07.txt. Sue -----Original Message----- From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Wednesday, June 15, 2016 5:31 AM To: draft-ietf-idr-bgp-gr-notification@tools.ietf.org; Susan Hares; 'John G. Scudder' Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; Jonathan Hardwick; Zhangxian (Xian); idr@ietf.org Subject: Hi Authors, I was assigned to do a QA review on draft-ietf-idr-bgp-gr-notification-07. For more detail what's is RtgDir QA review, please refer to https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Overall, the document is well-written and clear, after review, I have the following comments. 1. Abstract s/BGP NOTIFICATION Message/ BGP NOTIFICATION message; 2. Section 2: " 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" (which was defined in a previous draft version of this specification) is deprecated. This bit MUST be advertised as 0 and MUST be ignored upon receipt. " The "N" bit was firstly introduced in a previous version of this document, but deprecated in later version. I don't understand why a document need deprecate a functionality introduced by itself, why not just remove it? If we really want to keep this history, maybe a better way is to move above text to an appendix. If you agree above, then the last sentence of the first paragraph of section 2 should be changed as bellow: OLD: "the Restart flags field and the Flags field for Address Family are augmented as follows:" New: "the Restart flags field are augmented as follows:" 3. Section 3.1 "Subcode is a BGP Error Subcode (as documented in the IANA BGP Error Subcodes registry) as appropriate for the ErrCode. Similarly, Data is as appropriate for the ErrCode and Subcode." This is just an introduction to the Subcode itself, it's better to explicitly state that the subcode should be set to the Hard Reset (9). Hope you find above review useful. Best regards, Mach From nobody Wed Jun 15 19:57:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342EE12D0B0; Wed, 15 Jun 2016 19:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.149 X-Spam-Level: *** X-Spam-Status: No, score=3.149 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2JMKSBkHgOY; Wed, 15 Jun 2016 19:57:46 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739F712D68B; Wed, 15 Jun 2016 19:57:45 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=118.21.137.13; From: "Susan Hares" To: "'Stewart Bryant'" , , , , References: In-Reply-To: Date: Wed, 15 Jun 2016 22:57:28 -0400 Message-ID: <001e01d1c77a$d2d113b0$78733b10$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01D1C759.4BC03700" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAWJ7bdNeFYEFKYJBCfC8w71vB+p+OREKw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jonathan Hardwick' Subject: Re: [Idr] QA review of draft-ietf-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 02:57:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001F_01D1C759.4BC03700 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Stewart: =20 Thank you for your review. We will talk with Alvaro ( our AD) regarding = the longer list. =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Friday, June 10, 2016 12:25 PM To: draft-ietf-idr-te-pm-bgp@tools.ietf.org; idr-chairs@tools.ietf.org; = idr@ietf.org; rtg-dir@ietf.org Cc: Jonathan Hardwick Subject: [Idr] QA review of draft-ietf-idr-te-pm-bgp-03 =20 I was asked to do a QA review of draft-ietf-idr-te-pm-bgp-03 =20 This is a short, simple, well written draft that integrates two existing technologies.=20 =20 It is ready to move onto its next stage. =20 The only (minor) observation that I would make, is that=20 the front page author list is longer than is normally=20 acceptable by the IESG.=20 =20 Assuming that all the TLVs that are needed are included,=20 the draft looks about finished. =20 - Stewart=20 =20 ------=_NextPart_000_001F_01D1C759.4BC03700 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Stewart:

 

Thank you for your review.=C2=A0 We will talk with Alvaro ( our AD) = regarding the longer list.

 

Sue

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Stewart = Bryant
Sent: Friday, June 10, 2016 12:25 PM
To: = draft-ietf-idr-te-pm-bgp@tools.ietf.org; idr-chairs@tools.ietf.org; = idr@ietf.org; rtg-dir@ietf.org
Cc: Jonathan = Hardwick
Subject: [Idr] QA review of = draft-ietf-idr-te-pm-bgp-03

 

I was asked to do a QA =
review of =
draft-ietf-idr-te-pm-bgp-03
 
<= pre>This is a short, simple, well written draft that integrates = two
existing technologies. =

 
It is ready to move =
onto its next =
stage.
 
The only (minor) =
observation that I would make, is that 
the front =
page author list is longer than is normally =

acceptable by the IESG. =

 
Assuming that all the =
TLVs that are needed are included, 
the draft looks =
about finished.
 
- =
Stewart 
 
------=_NextPart_000_001F_01D1C759.4BC03700-- From nobody Thu Jun 16 02:33:29 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 392FD12D0E0; Thu, 16 Jun 2016 02:33:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160616093327.10504.94334.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2016 02:33:27 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-prefix-sid-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 09:33:27 -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 of the IETF. Title : Segment Routing Prefix SID extensions for BGP Authors : Stefano Previdi Clarence Filsfils Acee Lindem Keyur Patel Arjun Sreekantiah Saikat Ray Hannes Gredler Filename : draft-ietf-idr-bgp-prefix-sid-03.txt Pages : 16 Date : 2016-06-16 Abstract: Segment Routing (SR) architecture allows a node to steer a packet flow through any topological path and service chain by leveraging source routing. The ingress node prepends a SR header to a packet containing a set of "segments". Each segment represents a topological or a service-based instruction. Per-flow state is maintained only at the ingress node of the SR domain. This document describes the BGP extension for announcing BGP Prefix Segment Identifier (BGP Prefix SID) information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-prefix-sid-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 Thu Jun 16 03:32:53 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08FA12B028 for ; Thu, 16 Jun 2016 03:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNOUNeO49i21 for ; Thu, 16 Jun 2016 03:32:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA82127078 for ; Thu, 16 Jun 2016 03:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2269; q=dns/txt; s=iport; t=1466073170; x=1467282770; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FdDkaWX5A0ViVRtAzVAKWSDRzE8WWUZLjQrSb1sc8uU=; b=QxhZXWwjXHUvlaU6sfXvZr5Cq2UCc2gk9NtZ/ZhVtZgygQm2P8IUspxn Al/j2sc/WHcY6BwVdnkFTyIidVxlR6LjKYU0TzDDUw8NIF8p/URK4R8KP XBPKZzbsrWXUBj79pepSYrfck4RsPuwWrK6PVI+Y17joNZWQlGiFR4t+p o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgC2f2JX/4QNJK1dgz5WfQa6VYF6F?= =?us-ascii?q?wuFdQKBJjgUAQEBAQEBAWUnhEsBAQEDAQEBATc0EAsCAQgSBh4QJwsXDgIEE4g?= =?us-ascii?q?oCA6/SQEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4F3glaEQIMsgi8FmHABhgSIJ?= =?us-ascii?q?IFpToQEiGePcwEeNoIHHIFMbokFfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,480,1459814400"; d="scan'208";a="115686057" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jun 2016 10:32:49 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5GAWmKx014094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Jun 2016 10:32:49 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 16 Jun 2016 06:32:47 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Thu, 16 Jun 2016 06:32:47 -0400 From: "Stefano Previdi (sprevidi)" To: idr wg Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgp-prefix-sid-03.txt Thread-Index: AQHRx7ptKbmX4luYtUacwP5vqwf3UQ== Date: Thu, 16 Jun 2016 10:32:47 +0000 Message-ID: <340FA018-4A27-46E4-94C2-6E72C1685DE5@cisco.com> References: <20160616093327.10504.94334.idtracker@ietfa.amsl.com> In-Reply-To: <20160616093327.10504.94334.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.234.64] Content-Type: text/plain; charset="us-ascii" Content-ID: <97CB55F2D76EE94AB0640F43FB1F6DC6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-prefix-sid-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 10:32:52 -0000 Hi, just a refresh with updated references. This draft has multiple implementations and it is now pretty stable. The authors believe it is ready for wg lc. Thanks. s. > On Jun 16, 2016, at 11:33 AM, internet-drafts@ietf.org 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 of the IETF. >=20 > Title : Segment Routing Prefix SID extensions for BGP > Authors : Stefano Previdi > Clarence Filsfils > Acee Lindem > Keyur Patel > Arjun Sreekantiah > Saikat Ray > Hannes Gredler > Filename : draft-ietf-idr-bgp-prefix-sid-03.txt > Pages : 16 > Date : 2016-06-16 >=20 > Abstract: > Segment Routing (SR) architecture allows a node to steer a packet > flow through any topological path and service chain by leveraging > source routing. The ingress node prepends a SR header to a packet > containing a set of "segments". Each segment represents a > topological or a service-based instruction. Per-flow state is > maintained only at the ingress node of the SR domain. >=20 > This document describes the BGP extension for announcing BGP Prefix > Segment Identifier (BGP Prefix SID) information. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-prefix-sid-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 Thu Jun 16 03:37:03 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F219127078 for ; Thu, 16 Jun 2016 03:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klxiaT-7B-TZ for ; Thu, 16 Jun 2016 03:36:59 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CCC12D104 for ; Thu, 16 Jun 2016 03:36:58 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id l188so35272149lfe.2 for ; Thu, 16 Jun 2016 03:36:58 -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; bh=mPfOvrysaQk+EBCBe14AjrdBOuw16jsojG5v3MmdTyA=; b=l+hV9inJf9iSJ4+Rdfw8TV4ukSI/rCqU/OI5zYHiDu+PXkjIp+g1sD8mGwv5XSUhSL g499/9NfSPZ1vLiex4KQWtW6oBvOraoPdUcDpXExOlubqgFlEKIJLTBaUSC5eon4CCDP h+Q6CgkLiLGHOPbOZgl3lhkNlZM7Wq7PkXZ+V3jxolnuVI7AuCOpwbuQZw+g9wqKurDE ZIiCnom7pCK0uhgWS6oCHDhAvZGgxFC/bjmmhZnJNCFHMx/cMuQEUrogmVvkaZTfuMOh iiapKESuoxu7KjWDDgjdcHEM1W3LThuiqLdEZTCpFVStnhWdvMzN+WVMOYcB9q416iHQ 892Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mPfOvrysaQk+EBCBe14AjrdBOuw16jsojG5v3MmdTyA=; b=PS3qxn7cPepCaAMegoAVSWr4gKsLSVTve9oRatF0WC3egZjhwsfhy7hlwnZY31KUHU aXtBCPP1fXRdzpuIRR+JRlJOrXCbpZqA9UNOJhlr00IKa7zPsksMlA2JEnIcMsqVmHA6 2tfkIE3EmL/sNzkXoph92t9WmKTkM1nnOyzMk1fAwgIduaNWdJmXdfU+yRVA4/4v95hf JJa2w/zTzN+QDX80Yt+P0zkgteHkFR/JbXpUrfYPcOxrvTnQNSrwdWB3g+29p1E6a/Cu fGbzvJmADmi7eVnWVhvb0Pq5A1i9lYJddtPsa0sgNRPIUMiQ6ke6CkWslUtU5sxEl9WI IOig== X-Gm-Message-State: ALyK8tLPAV2rw/bZISOChm0IiSC4XZZL+Oa8W6ZnYKGJU/n6mmUMM5NTRKi0vWMyh03fAxYR+lQExmCpqgHIPA== MIME-Version: 1.0 X-Received: by 10.25.210.12 with SMTP id j12mr863424lfg.4.1466073417027; Thu, 16 Jun 2016 03:36:57 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Thu, 16 Jun 2016 03:36:56 -0700 (PDT) Received: by 10.25.21.30 with HTTP; Thu, 16 Jun 2016 03:36:56 -0700 (PDT) In-Reply-To: <340FA018-4A27-46E4-94C2-6E72C1685DE5@cisco.com> References: <20160616093327.10504.94334.idtracker@ietfa.amsl.com> <340FA018-4A27-46E4-94C2-6E72C1685DE5@cisco.com> Date: Thu, 16 Jun 2016 12:36:56 +0200 X-Google-Sender-Auth: leczLitMYqP5zhGH1agULBJ_2U0 Message-ID: From: Robert Raszuk To: stefano previdi Content-Type: multipart/alternative; boundary=001a11410c623c95d7053562d155 Archived-At: Cc: idr wg Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-prefix-sid-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 10:37:01 -0000 --001a11410c623c95d7053562d155 Content-Type: text/plain; charset=UTF-8 Hey Stefano, Can you share pointer to implementation report ? Thx, R. On Jun 16, 2016 06:32, "Stefano Previdi (sprevidi)" wrote: > Hi, > > just a refresh with updated references. > > This draft has multiple implementations and it is now pretty stable. > > The authors believe it is ready for wg lc. > > Thanks. > s. > > > > On Jun 16, 2016, at 11:33 AM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Inter-Domain Routing of the IETF. > > > > Title : Segment Routing Prefix SID extensions for BGP > > Authors : Stefano Previdi > > Clarence Filsfils > > Acee Lindem > > Keyur Patel > > Arjun Sreekantiah > > Saikat Ray > > Hannes Gredler > > Filename : draft-ietf-idr-bgp-prefix-sid-03.txt > > Pages : 16 > > Date : 2016-06-16 > > > > Abstract: > > Segment Routing (SR) architecture allows a node to steer a packet > > flow through any topological path and service chain by leveraging > > source routing. The ingress node prepends a SR header to a packet > > containing a set of "segments". Each segment represents a > > topological or a service-based instruction. Per-flow state is > > maintained only at the ingress node of the SR domain. > > > > This document describes the BGP extension for announcing BGP Prefix > > Segment Identifier (BGP Prefix SID) information. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-prefix-sid-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/ > > > > _______________________________________________ > > 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 > --001a11410c623c95d7053562d155 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hey Stefano,

Can you share pointer to implementation report ?

Thx,
R.

On Jun 16, 2016 06:32, "Stefano Previdi (sp= revidi)" <sprevidi@cisco.com<= /a>> wrote:
Hi,
just a refresh with updated references.

This draft has multiple implementations and it is now pretty stable.

The authors believe it is ready for wg lc.

Thanks.
s.


> On Jun 16, 2016, at 11:33 AM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Inter-Domain Routing of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Segment Routing Prefix SID extensions for BGP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Stefano Previdi
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Clarence Filsfils
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Acee Lindem
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Keyur Patel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Arjun Sreekantiah
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Saikat Ray
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Hannes Gredler
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-idr-bgp-prefix-sid-03.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 16
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2016-06-16
>
> Abstract:
>=C2=A0 =C2=A0Segment Routing (SR) architecture allows a node to steer a= packet
>=C2=A0 =C2=A0flow through any topological path and service chain by lev= eraging
>=C2=A0 =C2=A0source routing.=C2=A0 The ingress node prepends a SR heade= r to a packet
>=C2=A0 =C2=A0containing a set of "segments".=C2=A0 Each segme= nt represents a
>=C2=A0 =C2=A0topological or a service-based instruction.=C2=A0 Per-flow= state is
>=C2=A0 =C2=A0maintained only at the ingress node of the SR domain.
>
>=C2=A0 =C2=A0This document describes the BGP extension for announcing B= GP Prefix
>=C2=A0 =C2=A0Segment Identifier (BGP Prefix SID) information.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc= /draft-ietf-idr-bgp-prefix-sid/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-i= etf-idr-bgp-prefix-sid-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-idr-bgp-prefix-sid-03
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>
> _______________________________________________
> 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
--001a11410c623c95d7053562d155-- From nobody Thu Jun 16 19:21:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CE612DC28 for ; Thu, 16 Jun 2016 19:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTo7hrQWSiNP for ; Thu, 16 Jun 2016 19:21:22 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F183512DBF1 for ; Thu, 16 Jun 2016 19:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1354; q=dns/txt; s=iport; t=1466130081; x=1467339681; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BxS0h+60ZdUGK5HIlHQlRa3kw7GrynrKVP2l5/kp1BU=; b=ggz9OcvIxOB4NaKSpUpTe8MI0aDD+XjZ2YH0N2FaJdX6wbEMrQ3ySKZZ QZTX3gpyUs4VcMkD+jp47eGibQDx/nSu35OIh1DhixykKrGtVWCY01hG4 yZ4UkyOUZxtDtlJPNdwOa+MPpe/qRw3zSFw/SWhdoashVdyxaJ5XGRhDq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgBeXmNX/4kNJK1egz5WfQa6VoF6J?= =?us-ascii?q?IVzAoEsOBQBAQEBAQEBZSeESwEBAQQdbAIBCA4DAwECJAsyHQgBAQQBEogwDsB?= =?us-ascii?q?XAQEBAQEBAQEBAQEBAQEBAQEBARkFhieETYobBY4shRuFKgGGBIgkgWmEUohnj?= =?us-ascii?q?3QBHjaCCBwXgTVuiHx/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,481,1459814400"; d="scan'208";a="286586288" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jun 2016 02:21:21 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5H2LKFL014210 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jun 2016 02:21:21 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 16 Jun 2016 22:21:20 -0400 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Thu, 16 Jun 2016 22:21:20 -0400 From: "Mohammed Mirza (mohamirz)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) Thread-Index: AdHAElYAB9sVfa6xQkej61auMDdHAwIE3GsA Date: Fri, 17 Jun 2016 02:21:20 +0000 Message-ID: References: <017501d1c01a$41156960$c3403c20$@ndzh.com> In-Reply-To: <017501d1c01a$41156960$c3403c20$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.162.33] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <88F5EDA9BDB3F14C922D668254F41359@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 02:21:24 -0000 Support. Its a good extension for future optional attributes as it defines their scopes at the time of their definition. Because of this extra control it will possibly become a useful tool for more per-scope optional attributes down the road. Thanks, Mohammed From: Idr on behalf of Susan Hares Date: Monday, June 6, 2016 at 10:38 AM To: "idr@ietf.org" Subject: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) This begins a 2 week WG Adoption call for draft-keyupate-idr-bgp-attribute-announcement. You can find the draft at: https://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-attribute-announcem ent/ =20 This draft defines attribute extensions that help confine the scope of Optional attributes within a given AS or a given BGP member-AS in Confederation. In your comments please include: 1) =20 =B3Support=B2 or =B3No support=B2 for this draft as an IDR WG draft, 2) =20 Experiences with debugging optional attributes errors that this draft would aid, 3) =20 Deployments that use AS confederations where this draft=B9s ability to confined scope of the optional attributes would help restrict errors, =20 =20 Sue Hares and John Scudder =20 =20 =20 From nobody Fri Jun 17 02:02:20 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BC412B012; Fri, 17 Jun 2016 02:02:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160617090218.19171.2045.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2016 02:02:18 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-li-idr-flowspec-rpd-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 09:02:18 -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 of the IETF. Title : BGP FlowSpec Extensions for Routing Policy Distribution (RPD) Authors : Zhenbin Li Liang Ou Yujia Luo Sujian Lu Shunwan Zhuang Nan Wu Filename : draft-li-idr-flowspec-rpd-02.txt Pages : 23 Date : 2016-06-17 Abstract: This document describes a mechanism to use BGP Flowspec address family as routing-policy distribution protocol. This mechanism is called BGP FlowSpec Extensions for Routing Policy Distribution (BGP- FS RPD). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-li-idr-flowspec-rpd/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-li-idr-flowspec-rpd-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-li-idr-flowspec-rpd-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 17 03:45:30 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E749012D11D for ; Fri, 17 Jun 2016 03:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go_WYL7tqGOg for ; Fri, 17 Jun 2016 03:45:26 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7CE12D11A for ; Fri, 17 Jun 2016 03:45:25 -0700 (PDT) Received: (qmail 1134 invoked from network); 17 Jun 2016 12:45:23 +0200 Received: from p5dec287c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.40.124) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Jun 2016 12:45:23 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 17 Jun 2016 12:45:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> To: Randy Bush X-Mailer: Apple Mail (2.3124) Archived-At: Cc: idr wg Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 10:45:28 -0000 Hi all, sorry for my late reply. Yes, that was not capturing my point. Please = provide some reasoning with the SHOULD is not a MUST. What are the cases = where you should not follow the SHOULD. Mirja > Am 14.06.2016 um 19:08 schrieb Randy Bush : >=20 >> Does the proposed wording work for you? >>=20 >>> While it is technically possible to operate a route server which >>> prepends its own AS to the AS_PATH, it is not recommended to do so >>> because creating an undesirably longer AS_PATH may adversely affect >>> the resulting network topology between the route server clients. >=20 > i suspect that the AD is competent to speak for herself. but imiho = this > misses her point, why is the SHOULD not a MUST? this says why it = might > be a MUST. why allow the loophole? i admit my example was baroque. >=20 > randy From nobody Fri Jun 17 10:06:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3447912D7CB; Fri, 17 Jun 2016 10:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZdRevBovRWZ; Fri, 17 Jun 2016 10:06:46 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0104.outbound.protection.outlook.com [23.103.201.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C5E12B069; Fri, 17 Jun 2016 10:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3CpUsvN5jXozZrApQP78E33peyD5IolLGzI29Jr1E8I=; b=G7xNi3eurfei9xxbMQwsWk1+8J3GV5xySDf9nFFASeINnFfW0eL35ldhcRsOmOKk4IDbG3hL8d9X/I5kDFs6Z2TI0WaniESYj5zVWs1HT57p9CPgMb1jjGs/xpMac5Wr4AO023z7JxfWZM0Z29v48OSk2jJaCu2SOOmyWUZBKLU= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (TLS) id 15.1.523.12; Fri, 17 Jun 2016 17:06:44 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0523.015; Fri, 17 Jun 2016 17:06:44 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "aa@qrator.net" Thread-Topic: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) Thread-Index: AdHAEXYm+R0yr9NBRVeLkrezdS25EQA9XwKQAC3yRAABvZxAcA== Date: Fri, 17 Jun 2016 17:06:44 +0000 Message-ID: References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: 6fd74e25-e471-4553-a317-08d396d1c2a4 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 6:PoOfljDV/DeA5uIAXY/pgooACoWnf2nh+Z1WxNfoIC+wkpUfIm+rLPvT04FuHHR4TYAqW7XIVFaj4Hz7yDBdi7oqwZ6mkmDnpk/HEL2kbU4K5T+ebArjyNRRb0kW4VsQ6Ev1NRvKoR432OuZjUNVvJ28HH9HrCCrIHBr/b/TFmu6wf996bc4u4PBoITZL5ytXZz+WJ64HS72z3xCuXWkr/SVuaILuYYBPuYO6F1gkMmJr30vIVLSY+ONu+6LoUFdb9MOfCJLT0JdwZV2MJilSryryJ5hM50eTrp+fyVUB/nO8xDhDOIaAlYms5D0W+QjmLzJZCmk62R6XkEspt4jqw==; 5:4sQXGfRab9c0KCP2m4XO1iVZRkDxwPdm55BO8olOfFFxar+1IHshjcylW2MiZNNz0ktO/+pzSj5Hh57vKpIe8enMMyd/G5YohNxh7DEcsYcegdQocgcZtRd7O1cvBmnLsryDvUGDHCaHh1PDkwxicQ==; 24:beZKT/gwZj8wJHyJl91yA/E1LGf6rRlaLCFxACVGBwEGmfST9M75VUS/6CxCs2OlWcucvVZb16PyGHucQCBZWVjUZIf8034N+IPyajR5WZE=; 7:t3OoxeKB5xfERLdnqnOnOgEhtR+ufXzdmioo3sfh17uVShk4B+2Et7TX0DSuK2V6lhIPL4HZbs+lVJlRT38dXKK0+AVc8E68jZk347bciR0IFu5Rcwq1XAgvZNMDFn9IpnTqrakGOSEgBkljxPxBpm93LBo/LILaT1dASlogritJuaQrKEPE3m/QXd8xb9gYlrphLLq62uT1AQni/5FlByPYyq8nMHXK7GIMQmugCp9N07g27CXhwj0HPq6j9+e1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(5423002)(199003)(189002)(19300405004)(7906002)(19617315012)(230783001)(19580395003)(15975445007)(99286002)(5003600100002)(2351001)(77096005)(8666005)(92566002)(97736004)(5004730100002)(19625215002)(1730700003)(76176999)(561944003)(54356999)(81156014)(81166006)(50986999)(87936001)(7846002)(4326007)(8676002)(2906002)(74316001)(105586002)(5002640100001)(33656002)(9686002)(19609705001)(122556002)(2501003)(8936002)(110136002)(101416001)(76576001)(66066001)(5630700001)(189998001)(106356001)(2950100001)(2900100001)(11100500001)(86362001)(68736007)(586003)(3660700001)(790700001)(5640700001)(3846002)(6116002)(3280700002)(10400500002)(16236675004)(102836003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0446B1EE79006D28E67BD88B84570DM2PR09MB0446namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2016 17:06:44.1718 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-route-leak-detection-mitigation@ietf.org" , Susan Hares Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 17:06:50 -0000 --_000_DM2PR09MB0446B1EE79006D28E67BD88B84570DM2PR09MB0446namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxleGFuZGVyLA0KDQpTb3JyeSBmb3IgdGhlIGRlbGF5IGluIG15IHJlc3BvbnNlLg0KDQo+SW4g b3VyIHByb3Bvc2FsLCBBUzIgd291bGQgc2V0IE9UQyBmbGFnIG9ubHkgaWYgQVMzIGlzIG5vdCBz dXBwb3J0aW5nIHJvbGVzLA0KPmFuZCB0aGlzIGNhbiBlYXNpbHkgYmUgcmV0cmlldmVkIGZyb20g T1BFTiBtZXNzYWdlLg0KPlNvIHRoZSBwcm9ibGVtIGlzIG5vdCB3aXRoIHBlci11cGRhdGUgYmFz aXMgYXBwcm9hY2gsDQotLSBzbmlwIC0tDQoNCkluIHRoZSBTSURSL0lEUi9HUk9XIFdHcywgdGhl IGRlc2lnbiBjaG9pY2Ugb2YgcGVyLXVwZGF0ZSB2cy4gcGVyLWhvcA0Kd2FzIGRpc2N1c3NlZCBh dCBsZWFzdCBzaW5jZSAyMDEyLiBJIHRyaWVkIHRvIGV4cGxhaW4gdGhlIHJhdGlvbmFsZSBmb3IN CnBlci1ob3AgUkxQIGF0dHJpYnV0ZSBpbiBteSByZXNwb25zZSB0byBFcmljIHdpdGggYSBzaW1w bGUgZXhhbXBsZToNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZHIvY3Vy cmVudC9tc2cxNTc3NS5odG1sDQoNCj5XaGVuIGRlYWxpbmcgd2l0aCByb3V0ZSBsZWFrcyBpdOKA mXMgaW1wb3J0YW50IHRvIHNvbHZlIHRoZSBwcm9ibGVtLiBOb3QganVzdCBkZXRlY3QgaXQuDQot LSBzbmlwIC0tDQoNCltyb3V0ZS1sZWFrLWRldGVjdGlvbi1taXRpZ2F0aW9uXSBkb2VzIG5vdCBp Z25vcmUgcHJldmVudGlvbi9taXRpZ2F0aW9uIG9mIHJvdXRlIGxlYWtzLg0KU2VjdGlvbiAzLjIg ZGVhbHMgd2l0aCBpbnRyYS1BUyBtZXNzYWdpbmcgZm9yIHJvdXRlIGxlYWsgcHJldmVudGlvbi4N CkFuZCB0aGUgYXBwcm9hY2ggcmVjb21tZW5kZWQgdGhlcmUgaXMgYmFzZWQgb24gdGhlIGNvbW1v biBwcmFjdGljZSBhcHByb2FjaA0Kb2YgbWFqb3IgSVNQcyAocGxlYXNlIHNlZSB0aGUgcmVjZW50 IE5BTk9HIHRocmVhZCBvbiB0aGlzIHRvcGljKS4NCkFsc28sIFNlY3Rpb24gMy40IGlzIGFib3V0 IOKAnFBvc3NpYmxlIEFjdGlvbnMgYXQgYSBSZWNlaXZpbmcgUm91dGVyIGZvciBNaXRpZ2F0aW9u LuKAnQ0KSSB3YXMgb25seSBtYWtpbmcgdGhlIHdlbGwgYXBwcmVjaWF0ZWQgcG9pbnQgdGhhdCwg dGhlIHNvbHV0aW9uIHNob3VsZCBwdXQNCm1vcmUgZW1waGFzaXMgb24gcHJldmVudGlvbiBhbmQg ZGV0ZWN0aW9uLCBidXQgdGhlIG1pdGlnYXRpb24gKGZvbGxvd2luZyBkZXRlY3Rpb24pDQpuZWVk cyB0byBhbGxvdyAqb3BlcmF0b3IgcHJlZmVyZW5jZXMqIGZvciBob3cgdG8gaGFuZGxlIGV4dGVy bmFsbHkgKGVCR1ApIGxlYXJuZWQgcm91dGVzDQp0aGF0IGFyZSBkZXRlY3RlZCBhbmQgbWFya2Vk IGFzIHJvdXRlIGxlYWsuDQoNClNyaXJhbQ0KDQoNCg== --_000_DM2PR09MB0446B1EE79006D28E67BD88B84570DM2PR09MB0446namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFsZXhhbmRlciw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29ycnkgZm9yIHRo ZSBkZWxheSBpbiBteSByZXNwb25zZS4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtJbiBv dXIgcHJvcG9zYWwsIEFTMiB3b3VsZCBzZXQgT1RDIGZsYWcgb25seSBpZiBBUzMgaXMgbm90IHN1 cHBvcnRpbmcgcm9sZXMsDQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O2FuZCB0aGlzIGNhbiBlYXNp bHkgYmUgcmV0cmlldmVkIGZyb20gT1BFTiBtZXNzYWdlLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDtTbyB0aGUgcHJvYmxlbSBpcyBub3Qgd2l0aCBwZXItdXBkYXRl IGJhc2lzIGFwcHJvYWNoLCA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS0gc25pcCAtLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgU0lEUi9JRFIvR1JPVyBX R3MsIHRoZSBkZXNpZ24gY2hvaWNlIG9mIHBlci11cGRhdGUgdnMuIHBlci1ob3ANCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2FzIGRpc2N1c3NlZCBhdCBsZWFzdCBzaW5j ZSAyMDEyLiBJIHRyaWVkIHRvIGV4cGxhaW4gdGhlIHJhdGlvbmFsZSBmb3INCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cGVyLWhvcCBSTFAgYXR0cmlidXRlIGluIG15IHJl c3BvbnNlIHRvIEVyaWMgd2l0aCBhIHNpbXBsZSBleGFtcGxlOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2lkci9jdXJyZW50L21zZzE1Nzc1Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9pZHIvY3VycmVudC9tc2cxNTc3NS5odG1sPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7V2hlbiBkZWFsaW5nIHdpdGggcm91dGUgbGVha3MgaXTigJlzIGltcG9y dGFudCB0byBzb2x2ZSB0aGUgcHJvYmxlbS4gTm90IGp1c3QgZGV0ZWN0IGl0Lg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0tIHNuaXAgLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W3JvdXRlLWxlYWst ZGV0ZWN0aW9uLW1pdGlnYXRpb25dIGRvZXMgbm90IGlnbm9yZSBwcmV2ZW50aW9uL21pdGlnYXRp b24gb2Ygcm91dGUgbGVha3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T ZWN0aW9uIDMuMiBkZWFscyB3aXRoIGludHJhLUFTIG1lc3NhZ2luZyBmb3Igcm91dGUgbGVhayBw cmV2ZW50aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIHRoZSBh cHByb2FjaCByZWNvbW1lbmRlZCB0aGVyZSBpcyBiYXNlZCBvbiB0aGUgY29tbW9uIHByYWN0aWNl IGFwcHJvYWNoDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9mIG1ham9y IElTUHMgKHBsZWFzZSBzZWUgdGhlIHJlY2VudCBOQU5PRyB0aHJlYWQgb24gdGhpcyB0b3BpYyku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBTZWN0aW9uIDMuNCBp cyBhYm91dCDigJxQb3NzaWJsZSBBY3Rpb25zIGF0IGEgUmVjZWl2aW5nIFJvdXRlciBmb3IgTWl0 aWdhdGlvbi7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzIG9u bHkgbWFraW5nIHRoZSB3ZWxsIGFwcHJlY2lhdGVkIHBvaW50IHRoYXQsIHRoZSBzb2x1dGlvbiBz aG91bGQgcHV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tb3JlIGVtcGhh c2lzIG9uIHByZXZlbnRpb24gYW5kIGRldGVjdGlvbiwgYnV0IHRoZSBtaXRpZ2F0aW9uIChmb2xs b3dpbmcgZGV0ZWN0aW9uKQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5u ZWVkcyB0byBhbGxvdyAqb3BlcmF0b3IgcHJlZmVyZW5jZXMqIGZvciBob3cgdG8gaGFuZGxlIGV4 dGVybmFsbHkgKGVCR1ApIGxlYXJuZWQgcm91dGVzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnRoYXQgYXJlIGRldGVjdGVkIGFuZCBtYXJrZWQgYXMgcm91dGUgbGVhay48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3JpcmFtJm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM2PR09MB0446B1EE79006D28E67BD88B84570DM2PR09MB0446namp_-- From nobody Fri Jun 17 10:37:24 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEBF12D8F8; Fri, 17 Jun 2016 10:37:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160617173723.9664.13224.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2016 10:37:23 -0700 Archived-At: Cc: idr-chairs@ietf.org, idr@ietf.org, smccammon@amsl.com Subject: [Idr] idr - Update to a Meeting Session Request for IETF 96 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 17:37:23 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the idr working group. --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: trill i2rs i2nsf netconf bess sidr netmod rtgwg Second Priority: sdnrg nfvrg teas Third Priority: dots rtgarea Special Requests: Please group at beginning of week or end of week. You can also do a 2.5 hr session if that works for the schedule. --------------------------------------------------------- From nobody Mon Jun 20 06:05:12 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F02F12D0B3 for ; Mon, 20 Jun 2016 06:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TamHUCspqVIR for ; Mon, 20 Jun 2016 06:05:10 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF4312B05C for ; Mon, 20 Jun 2016 06:05:10 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 00CAA1E1DF; Mon, 20 Jun 2016 09:11:12 -0400 (EDT) Date: Mon, 20 Jun 2016 09:11:12 -0400 From: Jeffrey Haas To: Randy Bush Message-ID: <20160620131112.GE2950@pfrc.org> References: <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> 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: Cc: idr wg , Mirja Kuehlewind Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 13:05:11 -0000 On Wed, Jun 15, 2016 at 02:08:02AM +0900, Randy Bush wrote: > > Does the proposed wording work for you? > > > >> While it is technically possible to operate a route server which > >> prepends its own AS to the AS_PATH, it is not recommended to do so > >> because creating an undesirably longer AS_PATH may adversely affect > >> the resulting network topology between the route server clients. > > i suspect that the AD is competent to speak for herself. but imiho this > misses her point, why is the SHOULD not a MUST? this says why it might > be a MUST. why allow the loophole? i admit my example was baroque. I am somewhat late in chiming in on this thread, but I'm also supportive of making this a MUST. If you're intending to inject your AS number into the path, then you're acting as a standard BGP speaker, not a Route Server. If the intent of the text in the current internet-draft is to leave wiggle room for a device operating as a RS to also act as a standard BGP speaker without RS functionality, I think that's unnecessary. -- Jeff From nobody Mon Jun 20 09:10:43 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5593512D51C for ; Mon, 20 Jun 2016 09:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJskEPVTiale for ; Mon, 20 Jun 2016 09:10:40 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [IPv6:2001:5e8:2:46::6a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F9112D1CA for ; Mon, 20 Jun 2016 09:10:39 -0700 (PDT) Received: from dengue.psc.edu (dengue.psc.edu [128.182.160.217]) (authenticated bits=0) by mailer2.psc.edu (8.13.8/8.13.8) with ESMTP id u5KGAcRb008352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jun 2016 12:10:39 -0400 From: Michael H Lambert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2016 12:10:55 -0400 To: idr@ietf.org Message-Id: <0F2F74E2-B3CB-4447-9C7C-028F47E6490F@psc.edu> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Idr] draft-ietf-idr-ix-bgp-route-server-11 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 16:10:41 -0000 This may have been discussed before and I just couldn't find it in the = archives, and it may be too late in the process to ask the question, but = should RFC 7606 (Revised Error Handling for BGP) apply to peering = sessions with route server clients? It does run counter to attribute = transparency, but it can help insure that the "right" session is reset = and that known (or knowable) bad announcements are properly propagated. Michael From nobody Mon Jun 20 09:31:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCE512D7CD for ; Mon, 20 Jun 2016 09:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRbmotF-UVhs for ; Mon, 20 Jun 2016 09:30:51 -0700 (PDT) Received: from excession.bakker.net (tunnel55.ipv6.xs4all.nl [IPv6:2001:888:10:37::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8804D12D7A8 for ; Mon, 20 Jun 2016 09:30:51 -0700 (PDT) Received: by excession.bakker.net (Postfix, from userid 910) id 81287173C; Mon, 20 Jun 2016 18:30:49 +0200 (CEST) Date: Mon, 20 Jun 2016 18:30:49 +0200 From: niels@bakker.net (Niels Bakker) To: idr@ietf.org Message-ID: <20160620163049.GA58314@excession.tpb.net> References: <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> <20160620131112.GE2950@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20160620131112.GE2950@pfrc.org> Archived-At: Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 16:30:58 -0000 * jhaas@pfrc.org (Jeffrey Haas) [Mon 20 Jun 2016, 15:05 CEST]: >If you're intending to inject your AS number into the path, then >you're acting as a standard BGP speaker, not a Route Server. Not if you're doing multiple (per-peer) RIBs to avoid the path-hiding problem. -- Niels. -- From nobody Mon Jun 20 11:24:22 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DDC12D629 for ; Mon, 20 Jun 2016 11:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M5jFW_DPAfn for ; Mon, 20 Jun 2016 11:24:20 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B56127078 for ; Mon, 20 Jun 2016 11:24:19 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id f6so43191431lfg.0 for ; Mon, 20 Jun 2016 11:24:19 -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:from:date:message-id :subject:to:cc; bh=QkbMAu9Vl62E3usw3V2N3cAQd+AMWBgn+x0vUFVXqyE=; b=Woev9xkVgEucN3P9CrDcKdDugnpLky2d62Mm05V7PybjJ0Y9qoJijVpPH9XH/D2ku6 0tujxzlHhVPvFjS3qP6hbD/Ml1aXNmj6U+vlXpM2UNMyVmKcZueyKSTQX3QEyPvREgSa mIM9IkduAiSflmTEem7Hf/sts1ZN+T090iizRcDwK7rjIqNndGcVRHpY/9VsyL/OjQ3O cllXgy66JmKR5nAnYUuCqhidjsYSub25QrNx/s7u7o829IVvbZ+GUVO+iV5248tK+sFi 9kKXaP825dq54696f4Vdaom7vUcybeJ1ja0Fgjw94jV0ZdrZyoXaEc4GszVUeWNzps8e momw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QkbMAu9Vl62E3usw3V2N3cAQd+AMWBgn+x0vUFVXqyE=; b=gxcXI4ov/ZE/z1tITNDaUmq53zRYHGKSudVgp7sjzRlPuO36CzI3Ts4SbAiLRFWKgF aP5MqTRWKbhLXf2T6/owAaxVozNM3iX0WIf/Grg8jP2AnMAW/SlxD1QTfMdTZx4Mbm5z nwMa8WJIL4Lr0EXdqKfFEDLPZ2VmP6kXOz83hVx1u6oy2UwP8U4FC6jbC3i203oPONbA F1FuYX9c22R7mtOKbG+n7bKIYw22jVkNo+PN9Jf2gtSzaBaU/MP6wtKGVPZV4OxSKuhx BsPJF6s/TDHY8W3DaUfCdgAywdXubB0JHS56Xwqp8ZGoeV1+cCchARWYC821ulBBkRMs DGUw== X-Gm-Message-State: ALyK8tKHv0iAMSln3WWQ49+8jobEFU0jhV+qzJeXRoWv+e3t+pZa7hdxgc711xCnYadVa177TGV8rGDc6c8G5A== X-Received: by 10.46.5.213 with SMTP id 204mr4584973ljf.64.1466447055179; Mon, 20 Jun 2016 11:24:15 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Mon, 20 Jun 2016 11:24:14 -0700 (PDT) In-Reply-To: <20160620131112.GE2950@pfrc.org> References: <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> <20160620131112.GE2950@pfrc.org> From: Robert Raszuk Date: Mon, 20 Jun 2016 20:24:14 +0200 X-Google-Sender-Auth: Q7jIIPbdsaEWm0F_tIlQ2QDjIpI Message-ID: To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a114a683ece54e60535b9cffe Archived-At: Cc: idr wg Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 18:24:21 -0000 --001a114a683ece54e60535b9cffe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jeff, I am somewhat late in chiming in on this thread, but I'm also supportive of > making this a MUST. > =E2=80=8BAs discussed before I disagree. Injecting AS(es) is a simplest for= m of making some paths less preferable then others. =E2=80=8BAnd per peer policy= asking RS send my paths to peers X,Y, Z with + 4 ASes, but to peer A, B, C do not prepend as Niels points out maybe there already today. > If you're intending to inject your AS number into the path, then you're > acting as a standard BGP speaker, not a Route Server. > =E2=80=8BTo me the Route Server is a Route Reflector for EBGP sessions. It = really does not matter if you are messing with AS_PATH there or not. What actually matters =E2=80=8Bis that you do not set next hop to yourself there. Cheers, R. --001a114a683ece54e60535b9cffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff,

I am somewhat late in chiming in on this thread, but I'm als= o supportive of
making this a MUST.

= =E2=80=8BAs discussed before I disagree. Injecting AS(es) is a simplest for= m of making some paths less preferable then others. =E2=80=8BAnd per peer p= olicy asking RS send my paths to peers X,Y, Z with + 4 ASes, but to peer A,= B, C do not prepend as Niels points out maybe there already today.=C2=A0
=C2=A0
If you&#= 39;re intending to inject your AS number into the path, then you're
acting as a standard BGP speaker, not a Route Server.
=
=E2=80=8BTo me the Route Server is a Rout= e Reflector for EBGP sessions. It really does not matter if you are messing= with AS_PATH there or not. What actually matters =E2=80=8Bis that you do n= ot set next hop to yourself there.=C2=A0

=
Cheers,
R.

--001a114a683ece54e60535b9cffe-- From nobody Mon Jun 20 14:43:58 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A24B12D18C for ; Mon, 20 Jun 2016 14:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70kT4QFkf7re for ; Mon, 20 Jun 2016 14:43:54 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9205812DA76 for ; Mon, 20 Jun 2016 14:43:54 -0700 (PDT) Received: by seele.lamehost.it (Postfix, from userid 33) id 8375F743F8; Mon, 20 Jun 2016 23:43:52 +0200 (CEST) To: Robert Raszuk X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 20 Jun 2016 23:43:52 +0200 From: Marco Marzetti In-Reply-To: References: <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> <20160620131112.GE2950@pfrc.org> Message-ID: X-Sender: marco@lamehost.it User-Agent: Roundcube Webmail/1.1.5 Archived-At: Cc: idr wg Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 21:43:56 -0000 On 2016-06-20 20:24, Robert Raszuk wrote: > Jeff, > >> I am somewhat late in chiming in on this thread, but I'm also >> supportive of >> making this a MUST. > > ​As discussed before I disagree. Injecting AS(es) is a simplest form > of making some paths less preferable then others. ​And per peer > policy asking RS send my paths to peers X,Y, Z with + 4 ASes, but to > peer A, B, C do not prepend as Niels points out maybe there already > today. > >> If you're intending to inject your AS number into the path, then >> you're >> acting as a standard BGP speaker, not a Route Server. > > ​To me the Route Server is a Route Reflector for EBGP sessions. It > really does not matter if you are messing with AS_PATH there or not. > What actually matters ​is that you do not set next hop to yourself > there. I would like to underline that this draft depicts the behavior of a route server in an IXP environment. And, for many reasons, an IXP should be as transparent as possible when it comes to route propagation. -- Marco From nobody Mon Jun 20 14:56:52 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C6812DA8F for ; Mon, 20 Jun 2016 14:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Uthr9Il4G3i for ; Mon, 20 Jun 2016 14:56:49 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AF212DA8E for ; Mon, 20 Jun 2016 14:56:48 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id f6so48506150lfg.0 for ; Mon, 20 Jun 2016 14:56:48 -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:from:date:message-id :subject:to:cc; bh=tMOGAKgIdkf4xX4NY3iApvrwp3NusKtAITVK4W+Gm5c=; b=QfpgygeFxwjjHmnfe6HKnL8AK3JC1zOlYPNFMSJ7ImBZTrVyBcVJCd3F22ZBd4Id5p 3mYvAXYBt+iFiQJiC/PLXx2ZLgIZRdXxhlfZ07f6l654FoNyM1p1vcF5DjPFJwCeL3BA q3/y3T4Yg/hc/9sxbk+VmuycliPeOHq1CG0z2kBBJQ1vqk7Q7KWi0MLiaeulrlt86QPW gA6y1vwILJMJrDwKuvEuKBrQzXmwWGGTHDUsIV/Adjy8Cc8W3sWGtBTb8/OXAKLBhQ7Z Uf2DLcqswRjUjRIVQQypqGS4TmQ/vb6quAiydgCuPxGD9pEsJUWBQ7a9WhXUvj7dlUOR CYbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tMOGAKgIdkf4xX4NY3iApvrwp3NusKtAITVK4W+Gm5c=; b=GQBKS0cWrTRD8DkuEZ/HzqzwR3hye1qCmMB7PcUWDIZbWyKaleRFB4cc8vkYc5Ty+Z +94EPzgzqfFYahMoTjZZqZwKtQVcyYrqD/b4prAa8b5IpzFJgNKAf46wf8hoQJvBlZlz BV5zvodZFm7ErhB3tnAxUOxXaR6jipVhWBOQUncOrVaAXJdyBcv6JIsv5WpyF9/ieVd1 GqcrBB2YdbbORAflVSjwZoXSrqQ8lBQp7vmoLQ1+W+DP4eWMalsaYmmTN0hCENZX70ZK shuNDnPx1zuBJc7dzMK37Ww21UQPNLRL09mHfN8yXyJz2a+SY0Z00mC2UOWT3qrsC93G HgjQ== X-Gm-Message-State: ALyK8tK6uD9tI4DETRb3iiflGQnqKjh785jXrG8R6hpGHcJ5ma6HfgWNWX9zf/rgEAcBz8xnwICzFynRQDRmCQ== X-Received: by 10.25.33.133 with SMTP id h127mr3921351lfh.82.1466459806931; Mon, 20 Jun 2016 14:56:46 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Mon, 20 Jun 2016 14:56:46 -0700 (PDT) In-Reply-To: References: <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> <20160620131112.GE2950@pfrc.org> From: Robert Raszuk Date: Mon, 20 Jun 2016 23:56:46 +0200 X-Google-Sender-Auth: -LRhmaON45E1taJ0swEK7DcdY3I Message-ID: To: Marco Marzetti Content-Type: multipart/alternative; boundary=001a113f1888dea0e00535bcc7bf Archived-At: Cc: idr wg Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 21:56:52 -0000 --001a113f1888dea0e00535bcc7bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Marco, Altering AS_PATH indeed does not happen that often. Let's put that one aside keeping in mind that practical use cases exists where adding an AS is needed which to me precludes "MUST". But I can't agree with statement that IXP RS "should be as transparent as possible to route propagation" as every IX which assists in routes handling offers extensive RS to client (and to some level even client to RS) filtering policies. Ref: https://ams-ix.net/technical/specifications-descriptions/ams-ix-route-serve= rs That proves black on white that "transparency" is gone. Now the question is if we should RFC something which would be completely unpractical or unusable ? Many thx, R. On Mon, Jun 20, 2016 at 11:43 PM, Marco Marzetti wrote: > On 2016-06-20 20:24, Robert Raszuk wrote: > >> Jeff, >> >> I am somewhat late in chiming in on this thread, but I'm also >>> supportive of >>> making this a MUST. >>> >> >> =E2=80=8BAs discussed before I disagree. Injecting AS(es) is a simplest = form >> of making some paths less preferable then others. =E2=80=8BAnd per peer >> policy asking RS send my paths to peers X,Y, Z with + 4 ASes, but to >> peer A, B, C do not prepend as Niels points out maybe there already >> today. >> >> If you're intending to inject your AS number into the path, then >>> you're >>> acting as a standard BGP speaker, not a Route Server. >>> >> >> =E2=80=8BTo me the Route Server is a Route Reflector for EBGP sessions. = It >> really does not matter if you are messing with AS_PATH there or not. >> What actually matters =E2=80=8Bis that you do not set next hop to yourse= lf >> there. >> > > I would like to underline that this draft depicts the behavior of a route > server in an IXP environment. > And, for many reasons, an IXP should be as transparent as possible when i= t > comes to route propagation. > > -- > Marco > --001a113f1888dea0e00535bcc7bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Marco,

<= /div>
Altering AS_PATH indeed does not happen that often.= Let's put that one aside keeping in mind that practical use cases exis= ts where adding an AS is needed which to me precludes "MUST".

But I can't agree wit= h statement that IXP RS "should be as transparent as possible to route= propagation" as every IX which assists in routes handling offers exte= nsive RS to client (and to some level even client to RS) filtering policies= .=C2=A0

Ref:=C2=A0https://ams-ix.net/technical/specifications-descriptions/ams-ix-= route-servers

That= proves black on white that "transparency" is gone. Now the quest= ion is if we should RFC something which would be completely unpractical or = unusable ?

Many thx,R.

On Mon, Jun 20, 2016 at 11:43 PM, Marco Marzett= i <marco@lamehost.it> wrote:
On 2016-06-20 20:24, Robert Raszuk wrote:
Jeff,

I am somewhat late in chiming in on this thread, but I'm also
supportive of
making this a MUST.

=E2=80=8BAs discussed before I disagree. Injecting AS(es) is a simplest for= m
of making some paths less preferable then others. =E2=80=8BAnd per peer
policy asking RS send my paths to peers X,Y, Z with + 4 ASes, but to
peer A, B, C do not prepend as Niels points out maybe there already
today.

If you're intending to inject your AS number into the path, then
you're
acting as a standard BGP speaker, not a Route Server.

=E2=80=8BTo me the Route Server is a Route Reflector for EBGP sessions. It<= br> really does not matter if you are messing with AS_PATH there or not.
What actually matters =E2=80=8Bis that you do not set next hop to yourself<= br> there.

 I would like to underline that this draft depicts the behavior of a route s= erver in an IXP environment.
And, for many reasons, an IXP should be as transparent as possible when it = comes to route propagation.<= br>
--
Marco

--001a113f1888dea0e00535bcc7bf-- From nobody Tue Jun 21 03:10:36 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D793D12D0AD; Tue, 21 Jun 2016 03:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEpk69WCnW5J; Tue, 21 Jun 2016 03:10:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8C112D093; Tue, 21 Jun 2016 03:10:26 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id E830A60945EF5; Tue, 21 Jun 2016 10:10:21 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5LAANHo005444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2016 10:10:24 GMT 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 u5LAAL9U009174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jun 2016 12:10:23 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 21 Jun 2016 12:10:22 +0200 From: "Bocci, Matthew (Nokia - GB)" To: "idr@ietf.org" , Susan Hares , "jgs@juniper.net" , "rtg-dir@ietf.org" , "draft-ietf-idr-ext-opt-param@ietf.org" Thread-Topic: Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 Thread-Index: AQHRy6UfQEUW7Xqfm0G1XhSr365WJw== Date: Tue, 21 Jun 2016 10:10:22 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_A203A2D74F074790B996AB0310CBEF0Dnokiacom_" MIME-Version: 1.0 Archived-At: Subject: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 10:10:32 -0000 --_000_A203A2D74F074790B996AB0310CBEF0Dnokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXV0aG9ycywNCg0KSSBoYXZlIGJlZW4gYXNrZWQgdG8gZG8gYSBRQSByZXZpZXcgb2YgZHJhZnQt aWV0Zi1pZHItZXh0LW9wdC1wYXJhbS0wNC50eHQuDQoNCg0KDQpTdW1tYXJ5Og0KDQpUaGUgZG9j dW1lbnQgaXMgcmVhc29uYWJseSBzdHJhaWdodCBmb3J3YXJkIGFuZCBpcyB3ZWxsIHdyaXR0ZW4u IEkgaGF2ZSBhIGZldyBjb21tZW50cyBiZWxvdy4NCg0KDQpDb21tZW50czoNCg0KTWlub3IgSXNz dWVzOg0KDQoxKSBTZWN0aW9uIDIsIFByb3RvY29sIEV4dGVuc2lvbnMuDQpZb3UgaGF2ZSBsYWJl bGxlZCB0aGUgZXhpc3RpbmcgTGVuZ3RoIGFuZCBUeXBlIGZpZWxkcyBhcyAweEZGLiBJIGFzc3Vt ZSB0aGUgbWVhbmluZyBvZiB0aGUgc2Vjb25kIGlzIHN0aWxsICdUeXBlJyBzaW5jZSB0aGF0IGlz DQp3aGF0IGFueSBpbXBsZW1lbnRhdGlvbiB3b3VsZCByZWFzb25hYmx5IGludGVycHJldCBpdCBh cywgYW5kIHRoYXQgaXMgdGhlIHJlZ2lzdHJ5IHlvdSBhcmUgdXNpbmcgYSBjb2RlIHBvaW50IGZy b20uIFNvIGl0DQptaWdodCBiZSBiZXR0ZXIgdG8gc2F5IGluIHRoZSB0ZXh0IGFib3ZlIHRoZSBm aWd1cmUgYXQgdGhlIHRvcCBvZiBwYWdlIDMgdGhhdCB0aGUgbGVuZ3RoIGFuZCB0eXBlIGZpZWxk cyBpbiBbUkZDNDI3MV0NCmFyZSBzZXQgdG8gMHhGRi4NCg0KQWxzbywgeW91IGRvbid0IGV4cGxp Y2l0bHkgZGVmaW5lIHdoYXQgYSByZWNlaXZlciBzaG91bGQgZG8gd2l0aCB0aGUgbGVuZ3RoIGZp ZWxkIGlmIHRoZSB0eXBlIGlzIDB4RkYuIERvZXMgaXQgaWdub3JlIGl0LA0Kb3IgZG9lcyBpdCBj aGVjayB0aGF0IGl0IGlzIDB4RkYgYW5kIHRyZWF0IHRoZSBPUEVOIG1lc3NhZ2UgYXMgbWFsZm9y bWVkIGlmIGl0IGlzIDwgMHhGRj8NCg0KU2luY2UgdGhlIGRvY3VtZW50IGNoYW5nZXMgdGhlIHBy b2NlZHVyZXMgaW4gUkZDNDI3MSBmb3IgQkdQIE9wZW4gb3B0aW9uYWwgcGFyYW1ldGVycyB3aGVy ZSBsZW5ndGggPiAyNTUsIGluIHRoYXQgdGhlDQpvcmlnaW5hbCBsZW5ndGggZmllbGQgaXMgbm8g bG9uZ2VyIHRvIGJlIGludGVycHJldGVkIGFzIHRoZSBhY3R1YWwgbGVuZ3RoLCB0aGVuIEkgdGhp bmsgeW91IHNob3VsZCBtYXJrIHRoaXMgZHJhZnQgYXMNCidVcGRhdGVzOiA0MjcxJy4NCg0KMikg U2VjdGlvbiA1OiBTZWN1cml0eSBFeHRlbnNpb25zDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgc2VjdGlvbiBzZWVtcyB0byBiZSBsYWNraW5nIGRldGFpbCBhbmQgYW1vdW50cyB0byBvbmUg bGluZToNCiAiVGhpcyBleHRlbnNpb24gdG8gQkdQIGRvZXMgbm90IGNoYW5nZSB0aGUgdW5kZXJs eWluZyBzZWN1cml0eSBpc3N1ZXMiDQogSXQgbWlnaHQgYmUgd29ydGggYmVpbmcgYSBsaXR0bGUg bW9yZSBleHBsaWNpdCwgb3IgYXQgbGVhc3QgdXNlIHdvcmRpbmcgc2ltaWxhciB0byBSRkM1NDky LCBhbmQgc2F5aW5nIHRoYXQgaXQgZG9lcyBub3QNCiBhZGQgYW55IG5ldyBzZWN1cml0eSBpc3N1 ZXMgdGhhdCBhcmUgbm90IGluaGVyZW50IGluIEJHUCBbUkZDNDI3Ml0uDQoNCg0KDQoNClJlZ2Fy ZHMNCg0KTWF0dGhldw0K --_000_A203A2D74F074790B996AB0310CBEF0Dnokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <8CAF22DC544F3142A74B025E888FDC4F@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu az0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BdXRo b3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBoYXZlIGJl ZW4gYXNrZWQgdG8gZG8gYSBRQSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pZHItZXh0LW9wdC1wYXJh bS0wNC50eHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlN1bW1hcnk6IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIGRvY3VtZW50IGlz IHJlYXNvbmFibHkgc3RyYWlnaHQgZm9yd2FyZCBhbmQgaXMgd2VsbCB3cml0dGVuLiBJIGhhdmUg YSBmZXcgY29tbWVudHMgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q29tbWVudHM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NaW5vciBJc3N1ZXM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4xKSBTZWN0aW9uIDIsIFByb3RvY29sIEV4dGVu c2lvbnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+WW91IGhhdmUgbGFiZWxsZWQgdGhlIGV4aXN0aW5n IExlbmd0aCBhbmQgVHlwZSBmaWVsZHMgYXMgMHhGRi4gSSBhc3N1bWUgdGhlIG1lYW5pbmcgb2Yg dGhlIHNlY29uZCBpcyBzdGlsbCAnVHlwZScgc2luY2UgdGhhdCBpcw0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPndoYXQgYW55IGltcGxlbWVudGF0aW9uIHdvdWxkIHJlYXNvbmFibHkgaW50ZXJwcmV0IGl0 IGFzLCBhbmQgdGhhdCBpcyB0aGUgcmVnaXN0cnkgeW91IGFyZSB1c2luZyBhIGNvZGUgcG9pbnQg ZnJvbS4gU28gaXQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5taWdodCBiZSBiZXR0ZXIgdG8gc2F5IGlu IHRoZSB0ZXh0IGFib3ZlIHRoZSBmaWd1cmUgYXQgdGhlIHRvcCBvZiBwYWdlIDMgdGhhdCB0aGUg bGVuZ3RoIGFuZCB0eXBlIGZpZWxkcyBpbiBbUkZDNDI3MV0NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5h cmUgc2V0IHRvIDB4RkYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5BbHNvLCB5b3UgZG9uJ3QgZXhwbGljaXRseSBkZWZpbmUgd2hhdCBhIHJlY2VpdmVyIHNob3Vs ZCBkbyB3aXRoIHRoZSBsZW5ndGggZmllbGQgaWYgdGhlIHR5cGUgaXMgMHhGRi4gRG9lcyBpdCBp Z25vcmUgaXQsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+b3IgZG9lcyBpdCBjaGVjayB0aGF0IGl0IGlz IDB4RkYgYW5kIHRyZWF0IHRoZSBPUEVOIG1lc3NhZ2UgYXMgbWFsZm9ybWVkIGlmIGl0IGlzICZs dDsgMHhGRj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNpbmNl IHRoZSBkb2N1bWVudCBjaGFuZ2VzIHRoZSBwcm9jZWR1cmVzIGluIFJGQzQyNzEgZm9yIEJHUCBP cGVuIG9wdGlvbmFsIHBhcmFtZXRlcnMgd2hlcmUgbGVuZ3RoICZndDsgMjU1LCBpbiB0aGF0IHRo ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPm9yaWdpbmFsIGxlbmd0aCBmaWVsZCBpcyBubyBsb25nZXIg dG8gYmUgaW50ZXJwcmV0ZWQgYXMgdGhlIGFjdHVhbCBsZW5ndGgsIHRoZW4gSSB0aGluayB5b3Ug c2hvdWxkIG1hcmsgdGhpcyBkcmFmdCBhcw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPidVcGRhdGVzOiA0 MjcxJy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjIpIFNlY3Rp b24gNTogU2VjdXJpdHkgRXh0ZW5zaW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzZWVtcyB0byBiZSBsYWNraW5nIGRldGFpbCBhbmQgYW1v dW50cyB0byBvbmUgbGluZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZxdW90O1RoaXMgZXh0ZW5zaW9uIHRvIEJHUCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHVuZGVy bHlpbmcgc2VjdXJpdHkgaXNzdWVzJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDtJdCBtaWdodCBiZSB3b3J0aCBiZWluZyBhIGxpdHRsZSBtb3JlIGV4cGxp Y2l0LCBvciBhdCBsZWFzdCB1c2Ugd29yZGluZyBzaW1pbGFyIHRvIFJGQzU0OTIsIGFuZCBzYXlp bmcgdGhhdCBpdCBkb2VzIG5vdA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwO2FkZCBhbnkgbmV3 IHNlY3VyaXR5IGlzc3VlcyB0aGF0IGFyZSBub3QgaW5oZXJlbnQgaW4gQkdQIFtSRkM0MjcyXS4m bmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+TWF0dGhldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_A203A2D74F074790B996AB0310CBEF0Dnokiacom_-- From nobody Tue Jun 21 05:12:17 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528B012D79C; Mon, 20 Jun 2016 19:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4DMm3j8YXwK; Mon, 20 Jun 2016 19:27:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr680117.outbound.protection.outlook.com [40.107.68.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A905712D88C; Mon, 20 Jun 2016 19:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yNrSZSRiGz9+Zv+0NJPy58qIp0FzCLQCKFFaUV5wyBA=; b=kS7fwutu0PbHZWgSv0RYUkod8aLper1lx/jx0mTfVyjuS9Ldu8NgO9EUSFT7vqzmvscZ5+DfAtzsJTwBe0cBbUBrJAWg4biLpCOefTkcWuRfBdFbNceAhrj4DClqmsF6KXGT/SV5FkKPnbkWPDd8et/eN967tLYQ5Mcg1eTZWCY= Received: from DM2PR05MB573.namprd05.prod.outlook.com (10.141.159.16) by DM2PR05MB576.namprd05.prod.outlook.com (10.141.159.26) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 21 Jun 2016 02:27:52 +0000 Received: from DM2PR05MB573.namprd05.prod.outlook.com ([10.141.159.16]) by DM2PR05MB573.namprd05.prod.outlook.com ([10.141.159.16]) with mapi id 15.01.0523.015; Tue, 21 Jun 2016 02:27:52 +0000 From: Ross Callon To: "haoweiguo@huawei.com" , Donald Eastlake , Susan Hares , "sujay.gupta@ipinfusion.com" , "mdurrani@cisco.com" , 'Yizhou Li' , John Scudder Thread-Topic: routing directorate QA review of draft-ietf-idr-ls-trill-01.txt Thread-Index: AdHLZIDwzATvmHF5Tgi9n3A+2f5ymw== Date: Tue, 21 Jun 2016 02:27:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: bcd8fbfc-447b-469d-f0ab-08d3997ba59d x-microsoft-exchange-diagnostics: 1; DM2PR05MB576; 6:Yqf9mOVZDE/QrBYy0npsqAeuL2HzWykbUQ2ctAVmO4MWfVNb29bdIjlEP5UiQiAjk+OvUdzJeNzxJppQi5v2fmnzC2e9e3pLVxdxyBNENqKJaQihNDKhsyy1160ICFQ0Glt8j/F88scNT+b9JN3o6KL4P87bWn0SeTeykli1A5yH2Dt4gwvmbdCKp+YPx0SOwnYtr8bNzlGqXOJjGZpHn787tzBNdDdGxJvm6YM1RAbDdTtEbmcKR19+d6TEvdi91GdicYv2X1wTLiEUJmas+Vm0LpfdL2aUNhO4KffhsjWauyq5X7gYyzShK14CFqy1A5qN8DZcfAD7+X8CSF20zw==; 5:M8abhHqoY4shTiKziAxiXHCPo1WECW9E/kIRWWRACRm1qoBG5yjJxja7c4FV5YiqMvmB/aicT0IS5oTpJfN+N1sbJZj7jnsW9Z1Crk3eQRu9zq1E+SZG7ku6YyP8lprY/TJ+WX4ic7uA+IqOvWNg7A==; 24:TLaxdIKotTV4bOf840okn8pUNR9/c/NPaBnHrVYiNiKZW2qwVda/9IfTnmi35JhnmQ6dxEgVSUowSBOSLfq93P5/ZblR0ZrGsZkiHPJITPY=; 7:Mkr1NMuR4FtEEWLRGsW4aEa2TNqTk4ZDL+B8p8LS56UTnthcrp0JvWKS80I/QX52uFdA41Nx3wMLZC8n/wEYl8Sn81F2lrS3+Em+wVZWhSBHb/7P5rFwmJlHK7pYc1DZ7W71YYbVoBYmmN2mEO80ufRD/zWNJ+J26TBDAbj+uaynIVfoDamKRMVl2Dfeuu1nrzLTbfJxVPWpLsUrUGRCkdbeRdgLEuche4mByHjEXeXkcugJ33c+ojOVbjGy5Dru x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB576; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:DM2PR05MB576; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB576; x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(51444003)(189002)(199003)(77096005)(229853001)(15975445007)(19580395003)(97736004)(5001770100001)(2900100001)(76576001)(3660700001)(8936002)(11100500001)(92566002)(9686002)(4001450100002)(3280700002)(101416001)(33656002)(105586002)(106356001)(2201001)(10400500002)(575784001)(86362001)(586003)(2906002)(50986999)(1941001)(122556002)(8676002)(5002640100001)(4001430100002)(102836003)(6116002)(2501003)(7846002)(66066001)(189998001)(87936001)(3846002)(54356999)(4326007)(68736007)(74316001)(230783001)(107886002)(81166006)(81156014)(5003600100003)(7696003)(7736002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB576; H:DM2PR05MB573.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR05MB5730CEEFE1F13EB5EA57ED4A52B0DM2PR05MB573namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2016 02:27:52.6429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB576 Archived-At: X-Mailman-Approved-At: Tue, 21 Jun 2016 05:12:16 -0700 Cc: "idr@ietf.org" , "rtg-dir@ietf.org" , "trill@ietf.org" Subject: [Idr] routing directorate QA review of draft-ietf-idr-ls-trill-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 02:27:58 -0000 --_000_DM2PR05MB5730CEEFE1F13EB5EA57ED4A52B0DM2PR05MB573namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been selected as the QA reviewer for draft-ietf-idr-ls-trill-01.txt.= For more information about the Routing Directorate, please see http://trac= .tools.ietf.org/area/rtg/trac/wiki/RtgDir Summary: I think that this draft is straightforward and well written. I have only a = couple of questions and some very minor nits. I can see situations in which putting TRILL information into BGP may make s= ense, particularly in the case of providing TRILL information to a SDN cont= roller as pointed out in the draft. Due to the close relationship of this d= raft to the work in TRILL I have CC'd the TRILL working group on this revie= w and I assume that the TRILL working group will similarly be informed when= the document goes to WGLC. Questions: Section 1, second to last paragraph states: If ESADI (End Station Address Distribution Information) protocol [RFC7357] is used for control plane MAC learning in each data center, BGP LS also can be used for MAC address reachability information synchronization across multiple TRILL domains. End-to-end unicast forwarding paths can be calculated based on the synchronized information. Would this be limited to the case where routes are computed by SDN controll= ers? I am thinking that if instead the MAC reachability from one data cente= r is passed via BGP and fed back into TRILL in a different data center then= this would lead to significant issues which have not been discussed in thi= s document. Section 5 (security considerations) states: Procedures and protocol extensions defined in this document do not affect the BGP security model. See [RFC6952] for details. I am not a TRILL expert and therefore might not fully understand all cases = in which TRILL is used. I am however wondering if there are TRILL-specific = issues in that the TRILL information must only be passed to TRILL capable d= evices. I am also wondering whether there is any valid use of "TRILL in BGP= " other than passing TRILL information to SDN controllers. Passing TRILL in= formation from one TRILL domain to another TRILL domain and then redistribu= ting the information back into normal TRILL packets seems like a bad idea a= t first glance. I am wondering if this section should say something like "t= his protocol MUST be used ONLY for passing TRILL information from TRILL dev= ices to SDN controllers, and for passing TRILL information between SDN cont= rollers. Very minor nits: Section 2 defines the RFC2119 terms and abbreviations used in this document= in the same section with no subsections. I think that it is more normal to= have a subsection for RFC 2119 terms and a different subsection for abbrev= iations used in this document. Section 3, first paragraph, last sentence: "...multicast group address, and= etc." should be "...multicast group address, etc.". Section 3.1, "iS-IS" should be "IS-IS". Section 4, second paragraph, I thought that it was a bit odd for a document= to reference itself, as in "An implementation of this specification[idr-ls= -trill], MUST do...". Would this be a bit less awkward as: "Any implementat= ion of the protocol in this specification (ie that distributes TRILL Link-S= tate information using BGP), MUST do...". That is all that I found in a couple of readings of this document, Thanks, Ross --_000_DM2PR05MB5730CEEFE1F13EB5EA57ED4A52B0DM2PR05MB573namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have been selected as the QA reviewer for draft-ietf-idr-ls-trill-01= .txt. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
 
Summary:
 
I think that this draft is straightforward and well written. I have on= ly a couple of questions and some very minor nits.
 
I can see situations in which putting TRILL information into BGP may m= ake sense, particularly in the case of providing TRILL information to a SDN= controller as pointed out in the draft. Due to the close relationship of t= his draft to the work in TRILL I have CC’d the TRILL working group on this review and I assume that th= e TRILL working group will similarly be informed when the document goes to = WGLC.
 
 
Questions:
 
Section 1, second to last paragraph states:
 
   If ESADI (End Station Address Distribution Information) p= rotocol
   [RFC7357] is used for control plane MAC learning in each = data center,
   BGP LS also can be used for MAC address reachability info= rmation
   synchronization across multiple TRILL domains.  End-= to-end unicast
   forwarding paths can be calculated based on the synchroni= zed
   information.
 
Would this be limited to the case where routes are computed by SDN con= trollers? I am thinking that if instead the MAC reachability from one data = center is passed via BGP and fed back into TRILL in a different data center= then this would lead to significant issues which have not been discussed in this document.
 
 
Section 5 (security considerations) states:
 
   Procedures and protocol extensions defined in this docume= nt do not
   affect the BGP security model.  See [RFC6952] for de= tails.
 
I am not a TRILL expert and therefore might not fully understand all c= ases in which TRILL is used. I am however wondering if there are TRILL-spec= ific issues in that the TRILL information must only be passed to TRILL capa= ble devices. I am also wondering whether there is any valid use of “TRILL in BGP” other than pas= sing TRILL information to SDN controllers. Passing TRILL information from o= ne TRILL domain to another TRILL domain and then redistributing the informa= tion back into normal TRILL packets seems like a bad idea at first glance. I am wondering if this section should say somet= hing like “this protocol MUST be used ONLY for passing TRILL informat= ion from TRILL devices to SDN controllers, and for passing TRILL informatio= n between SDN controllers.
 
 
Very minor nits:
 
Section 2 defines the RFC2119 terms and abbreviations used in this doc= ument in the same section with no subsections. I think that it is more norm= al to have a subsection for RFC 2119 terms and a different subsection for a= bbreviations used in this document.
 
Section 3, first paragraph, last sentence: “…multicast gro= up address, and  etc.” should be “…multicast group a= ddress, etc.”.
 
Section 3.1, “iS-IS” should be “IS-IS”.
 
Section 4, second paragraph, I thought that it was a bit odd for a doc= ument to reference itself, as in “An implementation of this specifica= tion[idr-ls-trill], MUST do…”. Would this be a bit less awkward= as: “Any implementation of the protocol in this specification (ie that distributes TRILL Link-State information using BGP), MUST do…= ;”.
 
 
That is all that I found in a couple of readings of this document,
Thanks, Ross
 
 --_000_DM2PR05MB5730CEEFE1F13EB5EA57ED4A52B0DM2PR05MB573namprd_-- From nobody Tue Jun 21 17:05:53 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2857812DAA2; Tue, 21 Jun 2016 17:05:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160622000550.25062.28983.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2016 17:05:50 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 00:05:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Extended Message support for BGP Authors : Randy Bush Keyur Patel Dave Ward Filename : draft-ietf-idr-bgp-extended-messages-13.txt Pages : 5 Date : 2016-06-21 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates the BGP specification by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-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 Wed Jun 22 09:07:21 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CABF12D868; Wed, 22 Jun 2016 09:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_jxoWYmybfU; Wed, 22 Jun 2016 09:07:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F7F12DE36; Wed, 22 Jun 2016 08:57:23 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-ba-576ab5619d9e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 54.F3.18043.165BA675; Wed, 22 Jun 2016 17:57:22 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 22 Jun 2016 17:57:21 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oeFXz9ecQl82BdZhYncw8VTWzjTo8ihpXC/mNtV0tok=; b=Y5k/m1mw6KyzLRP7R9EsiiJQPg1JHBTqMkkUamjnMvXfGgnRlMc1jr+cSFaSL4slHOXKhjDOfE1SYLqFCbv5cy3nyqn2GFkDCaaDAEX8MGbpzb/vW1MIihkvESySBKO6XYUfNKeL6GlifseSjz3CZjZCid8Pc8V55EUEEWVObFA= Received: from VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) by VI1PR07MB1006.eurprd07.prod.outlook.com (10.161.110.22) with Microsoft SMTP Server (TLS) id 15.1.523.12; Wed, 22 Jun 2016 15:57:20 +0000 Received: from VI1PR07MB1005.eurprd07.prod.outlook.com ([10.161.110.21]) by VI1PR07MB1005.eurprd07.prod.outlook.com ([10.161.110.21]) with mapi id 15.01.0523.015; Wed, 22 Jun 2016 15:57:20 +0000 From: Daniele Ceccarelli To: "draft-ietf-idr-bgp-optimal-route-reflection.all@tools.ietf.org" Thread-Topic: RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection Thread-Index: AdHMiqSYAER1UXQQQXKhr6277cbfMw== Date: Wed, 22 Jun 2016 15:57:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [93.144.137.35] x-ms-office365-filtering-correlation-id: 2474245a-88c6-40d5-6385-08d39ab5e48e x-microsoft-exchange-diagnostics: 1; VI1PR07MB1006; 6:+awxIMrIh0Z77M2o9y+CnPI+DKIKJqxt/jco0i7UUbT1Qlsj7XnxXsBL56FFjfE6ZgDs48mOWOlue2ZVjWL7mMeOZ+4aYsdP9u8ZWjTLbU/q/6XqkleJvVsogtmdnuHdoxLdOyBNxAG+1HnwkV0PgYhOSA93Ay64IfNCCynP0nseFc/QY0SlESgt77bWwUyVU84qadaqaizceknoP0kSGdXv0t0Vv9F3N+wEfB/oQZesYeAmqPI8YMDr9M0kU/9EN0Ewjh7MI6dW9Fi6Rzc4SO4lHHBaxZJP4McUla/Erj8CFSxv8BXO4gLVzltArHc8; 5:0kN+7ugnWvVhHFkSoqY5Jo+2X1vUZiQd+KFG5z8j2gISuySzhpxRrcKi/JPyWm0Yxdzdx0/FznIXaYSGFHJbKAw1Zdu/UuAppkZAU8p97TSDJbZHIoo2kw6JSytM4UIzpiHJnZ9YHu0Ng8eelz13Nw==; 24:FiWlME/PZMpRwxmYRjFBwepCG0owmrexzTgOvh4kZQRid/JY0lw2Tc0oNh+60nnzveAcK0j6oXzfMNBRwqjN4an5ygQdP7FvFg3GYbnA52M=; 7:sQFOH5gc92pbpTlErv8St8jfGtZWqjOpR551AGiPHnF8p6mCiUvcOBDVEvVwXu17uSZUrg1zLXjLfAl6FOCjzP0jwjJsPtFYLqJLdmqVCXRftUxpB6dKR6lwJh5+OAOlv06kgTc3vrSfADFEfwiwV6R4+obWweecLB0z7hKPzJy+9Az6S5pOfCu7vFXBboD1mjHOsBhzrG4bVbgtjyaTwHoOfe9lY6QjvACnNSa0pcwSiCxB9E5XZAHTNCs3N8aaIlGePayLm4H3yQQpyqLCaw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1006; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR07MB1006; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1006; x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(189002)(4326007)(19580395003)(33656002)(2906002)(230783001)(105586002)(106356001)(86362001)(16236675004)(10400500002)(76576001)(11100500001)(54356999)(50986999)(2351001)(19617315012)(19625215002)(66066001)(229853001)(790700001)(6116002)(102836003)(586003)(3846002)(81156014)(8676002)(110136002)(81166006)(2900100001)(97736004)(122556002)(101416001)(3280700002)(189998001)(3660700001)(87936001)(8936002)(5002640100001)(77096005)(9686002)(2501003)(68736007)(7906002)(92566002)(7736002)(5003600100003)(19300405004)(7696003)(15975445007)(7846002)(74316001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1006; H:VI1PR07MB1005.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB1005B3A912A18AB20AF9164CF02C0VI1PR07MB1005eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 15:57:20.1865 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1006 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfSzUcRzH+9797u7n5tavQz6TFrdsQshsmaJiE63in5xEnPzm+ej3uyz+ aKqZPJSY1Wh5KEuFWfJwHlocuVTEKKsTN4dI0rD1QOTuezb/vb7vz/v78Nq+JFdczbMi4+QK mpHLEiV8IVEc0izdH9UYL3VVFYo8urR9hMc3zTTHo7xmSnCU619Z+Yfjvzy0xA/ihAoPR9OJ cak04+IdKYztKA1L0SguVxf3EBmoi85BJiRQ7tC3ksfFvBMGxur4OUhIiqluBAXz4wK8eI1g rWnQ0CKom1x4pg3Hg48IcqdnjK0eBEML3UQOIkk+5QmTqpP63JzKQjB8vUWg382l/OHJei5f z2ZUAJQu9RN6NqdOg3rwO8LsDFOFbQJ8mx1krU4b+iIqDN42/DD00cZbf72p4eAzLeHzZBkH O1BQ2f7e6GMBs7o1Hu5HQV2m0tixBc1iPsJ8Cn4+mOBhLhHAvSoGsx+oB3R8vQtQCdDUADj2 hBsFamO9bsOrSIjZGkbGFpDeF6hlHijHPxneL6ZoqKrNRNjXCr4MZxvZGmZGX/BuI/uSLQqY k+HlhwleiUF5B/QWTxI4d4LytkU+Zkd4VDHH3eR3HTrO1rwcCZ4iC5Zm2aQYNzdnmom7wLLJ cmc5rahHG1+os2HFU4k6vx5TIYpEElORVhknFfNkqWxakgoByZWYi7Kfx0vFomhZWjrNJEcw lxJpVoV2kYTEUhQ4aysVUzEyBZ1A0yk0sznlkCZWGSj3itljmU5reiuo8X6wkzw4KNvi1QlN Pae5xyXp2u+L+bX9vukH21vtZOcVZTZlY15nXH3++qLj6t3eFX5F072thxz2DGgKvYR5heqV IWZuPe/hvgg2tkV1JJJwDFT6rKUkb3P/N2ifdufc/HrIaOhV3V3PgO2rOWf3hksTbG1GtBKC jZUdcOAyrOw/Ydnzpj4DAAA= Archived-At: Cc: "rtg-dir@ietf.org" , "idr@ietf.org" Subject: [Idr] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 16:07:18 -0000 --_000_VI1PR07MB1005B3A912A18AB20AF9164CF02C0VI1PR07MB1005eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I am the Routing Area Directorate member that was assigned the QA review of= draft-ietf-idr-bgp-optimal-route-reflection. If you're not familiar with the QA review process please see: https://trac= .tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa BR Daniele - General comment: The draft is understandable and does not require any major modification in = addition to the minor edits and clarifications suggested below. My concern, which is something the working group probably already discussed= , is about the complexity and usefulness of the idea. The goal of draft is: " The core of this solution is the ability for an operator to specify on a per route reflector basis or per peer/update group basis or per peer basis the virtual IGP location placement of the route reflector. This enables having a given group of clients receive routes with optimal distance to the next hops from the position of the configured virtual IGP location. This also provides for freedom of route reflector location and allows transient or permanent migration of such network control plane function to optimal location." But I understand that there is a number of workarounds and that different p= aths are already used for redundancy reasons, hence my questions is: is it = worth defining a new solution? Is the usage of the actual mechanisms so dis= optimized to require these changes? How many possible paths are there betwe= en the client and the AS border node? - Abstract " This document proposes a solution for BGP route reflectors to allow them to choose the best path their clients would have chosen under the same conditions, without requiring further state or any new features to be placed on the clients" This is really hard to read. Maybe it could be improved stating what is the= problem and what the solution is. You could copy a couple of sentences fro= m section 1.1. which is much clear. - Introduction: " In some situations, this method suffers from non-optimal path selection".= Which path? The one used to forward the packets? The one used to redistrib= ute the route? Or? --- In a number of occurrences acronyms are not explained at first usage, e.g. = POP, L3VPN, 6PE... --- Another general comment: I like the rich intro full of details on the probl= em statement, the existing solutions and the proposed one. However I'm stru= ggling to understand how an implementation could be declared to be complian= t to this ID. The only thing I see is "the implementation MUST NOT prevent = reflecting more than one path" and an analog requirement which is "the rout= e reflector MUST reflect N optimal paths". I would have expected this to be= an amendment to the existing RFC that states that a single path can be ref= lected. --- --_000_VI1PR07MB1005B3A912A18AB20AF9164CF02C0VI1PR07MB1005eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I am the Routing Area Directora= te member that was assigned the QA review of draft-ietf-idr-bgp-optimal-rou= te-reflection.

 

If you’re not familiar wi= th the QA review process please see:  http= s://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

 

BR
Daniele 

 

-  = ;        General comment:

The draft is understandable and= does not require any major modification in addition to the minor edits and= clarifications suggested below.

My concern, which is something = the working group probably already discussed, is about the complexity and u= sefulness of the idea.

The goal of draft is:

“   T=
he core of this solution is the ability for an operator to specify
   on a per route=
 reflector basis or per peer/update group basis or per

   peer basis the=
 virtual IGP location placement of the route reflector.

   This enables h=
aving a given group of clients receive routes with


   optimal distan=
ce to the next hops from the position of the configured

   virtual IGP lo=
cation.  This also provides for freedom of route

   reflector loca=
tion and allows transient or permanent migration of


   such network c=
ontrol plane function to optimal location.”


But I understand that there is =
a number of workarounds and that different paths are already used for redun=
dancy reasons, hence my questions is: is it worth defining a new solution? =
Is the usage of the actual mechanisms
 so disoptimized to require these changes? How many possible paths are ther=
e between the client and the AS border node?


 


-  =
;       
Abstract


“   T=
his document proposes a solution for BGP route reflectors to allow


 &=
nbsp; them to choose the best path their clients would have chosen under


 &=
nbsp; the same conditions, without requiring further state or any new<=
/o:p>


 &=
nbsp; features to be placed on the clients”


Th=
is is really hard to read. Maybe it could be improved stating what is the p=
roblem and what the solution is. You could copy a couple of sentences from =
section 1.1. which is much clear.


 


-  =
;       
Introduction:


 


“ In some situations,=
 this method suffers from non-optimal path selection”. Which path? Th=
e one used to forward the packets? The one used to redistribute the route? =
Or?


--- 


In a number of occurrences acro=
nyms are not explained at first usage, e.g. POP, L3VPN, 6PE…


---


 


Another general comment: I like=
 the rich intro full of details on the problem statement, the existing solu=
tions and the proposed one. However I’m struggling to understand how =
an implementation could be declared to be
 compliant to this ID. The only thing I see is “the implementation MU=
ST NOT prevent reflecting more than one path” and an analog requireme=
nt which is “the route reflector MUST reflect N optimal paths”.=
 I would have expected this to be an amendment to the existing
 RFC that states that a single path can be reflected.


 


---


 
--_000_VI1PR07MB1005B3A912A18AB20AF9164CF02C0VI1PR07MB1005eurp_-- From nobody Wed Jun 22 10:46:51 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B03512B04A; Wed, 22 Jun 2016 10:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rmler3ftabUa; Wed, 22 Jun 2016 10:46:46 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6447E12D991; Wed, 22 Jun 2016 10:46:45 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id f6so79049208lfg.0; Wed, 22 Jun 2016 10:46: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:from:date:message-id :subject:to:cc; bh=xEze6p1+WyJBR9+oxg/dYCmWw3pio+l1q0drkjjsWbU=; b=IK/iWva5anvwXAGa2Gt27cnhDealoEQB7U5I12dwJ4ONOO0UvmhybasfNdYdTox71o Zn8LWmzVRYBUGDcbFKk1bZNGqkxghnQpG0c/UyZGQCdAdrwHMU9oKXST0IOWVnWIJxAv CfGSNzY4A2eRF02LCtbcrB68kumEBfILT44u93wnbJJ3g+RnTai/Hm96G5BZF6QSrh1z 3BHIuDEfeT0G86y9/amOid9ybdeHUVFk+98Drc004lqNboXFOu4qz+dPZL/fAjF5xCAj f0Dp8r8/PR4/DPJ9JrSc1CF7Kg92Ema+iJLeI+6ItE/ylytwpYyBubZfC7L200Br0JeN UeqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xEze6p1+WyJBR9+oxg/dYCmWw3pio+l1q0drkjjsWbU=; b=Kio0+cvhw8P1JS2uYJ6znDU+pUlHsE7kvsw2OqiLVn7cxujbRaw8s2WbbSsVQdP/aD OKBeofe7p3lmPoJ1GP+yOucKd8h10qCdEfUjNjTutpDda8jURSBK7c2e6b6zUu6Cl2TS ww1QZQpSG/yMz22FkjdGsMfPg9uSIQhGVFqLF+QQFEi7/FZ+q9hlQR+WqnBjzg3eoH04 MUsL74FLyjZAiVH8S5CY//kgoQ2IWWxwAzKpuRVyNA7WZAc8NTaZEaLWaCjM8EFQ+0/B 4/+W6X5Ry0hOhhiskww9Zs8XQBhDRz0L4p94psov6pi5Jp45gmy4KPi29PmVO5LoTg/Y 5lug== X-Gm-Message-State: ALyK8tIBVuvEEg//0w9Vzd+mRT9mEhoXJCegN34hHtGC1AyURD3oRnsDUXuc3oOqbcFy0JKQ7wIH6uqUdzaHYA== X-Received: by 10.25.214.97 with SMTP id n94mr10411400lfg.105.1466617603501; Wed, 22 Jun 2016 10:46:43 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Wed, 22 Jun 2016 10:46:42 -0700 (PDT) In-Reply-To: References: From: Robert Raszuk Date: Wed, 22 Jun 2016 19:46:42 +0200 X-Google-Sender-Auth: RxP2IjMf4gapqEURGWSGl87nNec Message-ID: To: Daniele Ceccarelli Content-Type: multipart/alternative; boundary=001a1140ef7a4735d10535e18512 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-idr-bgp-optimal-route-reflection.all@tools.ietf.org" , "idr@ietf.org" Subject: Re: [Idr] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 17:46:49 -0000 --001a1140ef7a4735d10535e18512 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Daniele, Many thx for your review. While I will clarify some text you pointed to in the draft let me also answer some of your questions below. But I understand that there is a number of workarounds and that different > paths are already used for redundancy reasons, hence my questions is: is = it > worth defining a new solution? > =E2=80=8BActually current workarounds are very limited to either installing =E2=80=8Bphysical hardware at various IGP locations or what is quite unlike= ly to attach Route Reflectors over manually created tunnels. Let's also observe here that the paradigm of control plane is shifting from traditional routers to x86 virtual space or even cloud. As result without this proposal operators have choice of their route reflectors distributing suboptimal paths or distributing all paths and in turn allowing clients to make independent best path selection. Now while the latter could be even an option in router's world more and more BGP is being observed on the compute servers where sending there all present in an AS BGP paths would be for one undesired as well would require to run also IGP on those compute machines. Of course I am talking about the case where we use IBGP in such setup. Is the usage of the actual mechanisms so disoptimized to require these > changes? > =E2=80=8BIt is unfortunately. Traditionally RRs were all fine as they were = in the data path. Then came MPLS and later other encapsulations where only ingress node started to make a decision to which next hop tunnel the packet hece RRs migrated from data plane to somewhere on the stick. And that was the origin of the problem we face today that either each ingress much have all the paths or it get's to exit via suboptimal egress. How many possible paths are there between the client and the AS border node= ? > =E2=80=8BThat depends. I have seen anywhere from 2-4 to 100s where say each= AS (out of three major SPs in the country) is EBGP peering locally with other two in each metro or in each prefecture - and they do it to optimize exit rather then always traverse Tokyo or Osaka. Another general comment: I like the rich intro full of details on the > problem statement, the existing solutions and the proposed one. However I= =E2=80=99m > struggling to understand how an implementation could be declared to be > compliant to this ID. The only thing I see is =E2=80=9Cthe implementation= MUST NOT > prevent reflecting more than one path=E2=80=9D and an analog requirement = which is > =E2=80=9Cthe route reflector MUST reflect N optimal paths=E2=80=9D. I wou= ld have expected > this to be an amendment to the existing RFC that states that a single pat= h > can be reflected. > =E2=80=8BImplementation basically should allow =E2=80=8Bto configure per in= stance or per group of peers logical location from which either for the entire instance or for set of peers best path will be computed. Many thx once again, Robert. --001a1140ef7a4735d10535e18512 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Daniele,
Many thx for your review. While I will clarify so= me text you pointed to in the draft let me also answer some of your questio= ns below.

But I understand that there is a number of workarounds and that different = paths are already used for redundancy reasons, hence my questions is: is it= worth defining a new solution?

=E2=80=8BActually current workarounds are v= ery limited to either installing =E2=80=8Bphysical hardware at various IGP = locations or what is quite unlikely to attach Route Reflectors over manuall= y created tunnels.=C2=A0

Let's also observe here that the paradigm of control plane is shifti= ng from traditional routers to x86 virtual space or even cloud. As result w= ithout this proposal operators have choice of their route reflectors distri= buting suboptimal paths or distributing all paths and in turn allowing clie= nts to make independent best path selection.=C2=A0
=
Now while the latter could be even an option i= n router's world more and more BGP is being observed on the compute ser= vers where sending there all present in an AS BGP paths would be for one un= desired as well would require to run also IGP on those compute machines. Of= course I am talking about the case where we use IBGP in such setup.=C2=A0<= /div>

Is the = usage of the actual mechanisms so disoptimized to require these changes?


=E2=80=8BIt is unfortunately. Tr= aditionally RRs were all fine as they were in the data path. Then came MPLS= and later other encapsulations where only ingress node started to make a d= ecision to which next hop tunnel the packet hece RRs migrated from data pla= ne to somewhere on the stick.=C2=A0

And that was the origin of the problem we face today that eit= her each ingress much have all the paths or it get's to exit via subopt= imal egress.=C2=A0


How many possible paths are there between the cl= ient and the AS border node?


=E2=80=8BThat depends. I have seen anywhere fro= m 2-4 to 100s where say each AS (out of three major SPs in the country) is = EBGP peering locally with other two in each metro or in each prefecture - a= nd they do it to optimize exit rather then always traverse Tokyo or Osaka.= =C2=A0


Another general comment: I like the rich i= ntro full of details on the problem statement, the existing solutions and t= he proposed one. However I=E2=80=99m struggling to understand how an implem= entation could be declared to be compliant to this ID. The only thing I see is =E2=80=9Cthe implementation = MUST NOT prevent reflecting more than one path=E2=80=9D and an analog requi= rement which is =E2=80=9Cthe route reflector MUST reflect N optimal paths= =E2=80=9D. I would have expected this to be an amendment to the existing RFC that states that a single path can be reflected.


=E2=80=8BImplementation b= asically should allow =E2=80=8Bto configure per instance or per group of pe= ers logical location from which either for the entire instance or for set o= f peers best path will be computed.=C2=A0

Many thx once again,
Robert.

--001a1140ef7a4735d10535e18512-- From nobody Wed Jun 22 15:35:28 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35A812DD92; Wed, 22 Jun 2016 15:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAZulbEUqneD; Wed, 22 Jun 2016 15:35:24 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE8612DD7D; Wed, 22 Jun 2016 15:34:40 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.122.226; Date: Wed, 22 Jun 2016 18:34:33 -0400 Message-ID: Importance: normal From: Susan Hares To: "Bocci, Matthew (Nokia - GB)" , "idr@ietf.org" , "jgs@juniper.net" , "rtg-dir@ietf.org" , "draft-ietf-idr-ext-opt-param@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_189308569651720" X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 22:35:27 -0000 ----_com.samsung.android.email_189308569651720 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 TWF0dGhldwpUaGFuayB5b3UgZm9yIHRoZSBRQSByZXZpZXcuIMKgVGhlIGF1dGhvcnMgd2lsbCBn ZXQgYmFjayB0byB5b3Ugd2l0aCB0aGVpciBjaGFuZ2VzLlN1ZQoKClNlbnQgdmlhIHRoZSBTYW1z dW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQmVCA0RyBMVEUgc21hcnRwaG9uZS0tLS0tLS0tIE9yaWdp bmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiAiQm9jY2ksIE1hdHRoZXcgKE5va2lhIC0gR0IpIiA8 bWF0dGhldy5ib2NjaUBub2tpYS5jb20+IERhdGU6IDYvMjEvMjAxNiAgNjoxMCBBTSAgKEdNVC0w NTowMCkgVG86IGlkckBpZXRmLm9yZywgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4sIGpn c0BqdW5pcGVyLm5ldCwgcnRnLWRpckBpZXRmLm9yZywgZHJhZnQtaWV0Zi1pZHItZXh0LW9wdC1w YXJhbUBpZXRmLm9yZyBTdWJqZWN0OiBbSWRyXSBSb3V0aW5nIGRpcmVjdG9yYXRlIFFBIHJldmll dyBvZglkcmFmdC1pZXRmLWlkci1leHQtb3B0LXBhcmFtLTA0IAoKCkF1dGhvcnMsCsKgCkkgaGF2 ZSBiZWVuIGFza2VkIHRvIGRvIGEgUUEgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaWRyLWV4dC1vcHQt cGFyYW0tMDQudHh0LgrCoArCoArCoApTdW1tYXJ5OiAKwqAKVGhlIGRvY3VtZW50IGlzIHJlYXNv bmFibHkgc3RyYWlnaHQgZm9yd2FyZCBhbmQgaXMgd2VsbCB3cml0dGVuLiBJIGhhdmUgYSBmZXcg Y29tbWVudHMgYmVsb3cuCsKgCsKgCkNvbW1lbnRzOgrCoApNaW5vciBJc3N1ZXM6CsKgCjEpIFNl Y3Rpb24gMiwgUHJvdG9jb2wgRXh0ZW5zaW9ucy4KCllvdSBoYXZlIGxhYmVsbGVkIHRoZSBleGlz dGluZyBMZW5ndGggYW5kIFR5cGUgZmllbGRzIGFzIDB4RkYuIEkgYXNzdW1lIHRoZSBtZWFuaW5n IG9mIHRoZSBzZWNvbmQgaXMgc3RpbGwgJ1R5cGUnIHNpbmNlIHRoYXQgaXMKCndoYXQgYW55IGlt cGxlbWVudGF0aW9uIHdvdWxkIHJlYXNvbmFibHkgaW50ZXJwcmV0IGl0IGFzLCBhbmQgdGhhdCBp cyB0aGUgcmVnaXN0cnkgeW91IGFyZSB1c2luZyBhIGNvZGUgcG9pbnQgZnJvbS4gU28gaXQKCm1p Z2h0IGJlIGJldHRlciB0byBzYXkgaW4gdGhlIHRleHQgYWJvdmUgdGhlIGZpZ3VyZSBhdCB0aGUg dG9wIG9mIHBhZ2UgMyB0aGF0IHRoZSBsZW5ndGggYW5kIHR5cGUgZmllbGRzIGluIFtSRkM0Mjcx XQoKYXJlIHNldCB0byAweEZGLgrCoApBbHNvLCB5b3UgZG9uJ3QgZXhwbGljaXRseSBkZWZpbmUg d2hhdCBhIHJlY2VpdmVyIHNob3VsZCBkbyB3aXRoIHRoZSBsZW5ndGggZmllbGQgaWYgdGhlIHR5 cGUgaXMgMHhGRi4gRG9lcyBpdCBpZ25vcmUgaXQsCgpvciBkb2VzIGl0IGNoZWNrIHRoYXQgaXQg aXMgMHhGRiBhbmQgdHJlYXQgdGhlIE9QRU4gbWVzc2FnZSBhcyBtYWxmb3JtZWQgaWYgaXQgaXMg PCAweEZGPwrCoApTaW5jZSB0aGUgZG9jdW1lbnQgY2hhbmdlcyB0aGUgcHJvY2VkdXJlcyBpbiBS RkM0MjcxIGZvciBCR1AgT3BlbiBvcHRpb25hbCBwYXJhbWV0ZXJzIHdoZXJlIGxlbmd0aCA+IDI1 NSwgaW4gdGhhdCB0aGUKCm9yaWdpbmFsIGxlbmd0aCBmaWVsZCBpcyBubyBsb25nZXIgdG8gYmUg aW50ZXJwcmV0ZWQgYXMgdGhlIGFjdHVhbCBsZW5ndGgsIHRoZW4gSSB0aGluayB5b3Ugc2hvdWxk IG1hcmsgdGhpcyBkcmFmdCBhcwoKJ1VwZGF0ZXM6IDQyNzEnLgrCoAoyKSBTZWN0aW9uIDU6IFNl Y3VyaXR5IEV4dGVuc2lvbnMKVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gc2Vl bXMgdG8gYmUgbGFja2luZyBkZXRhaWwgYW5kIGFtb3VudHMgdG8gb25lIGxpbmU6CgrCoCJUaGlz IGV4dGVuc2lvbiB0byBCR1AgZG9lcyBub3QgY2hhbmdlIHRoZSB1bmRlcmx5aW5nIHNlY3VyaXR5 IGlzc3VlcyIKCsKgSXQgbWlnaHQgYmUgd29ydGggYmVpbmcgYSBsaXR0bGUgbW9yZSBleHBsaWNp dCwgb3IgYXQgbGVhc3QgdXNlIHdvcmRpbmcgc2ltaWxhciB0byBSRkM1NDkyLCBhbmQgc2F5aW5n IHRoYXQgaXQgZG9lcyBub3QKCsKgYWRkIGFueSBuZXcgc2VjdXJpdHkgaXNzdWVzIHRoYXQgYXJl IG5vdCBpbmhlcmVudCBpbiBCR1AgW1JGQzQyNzJdLsKgCgrCoArCoArCoArCoApSZWdhcmRzCsKg Ck1hdHRoZXcKCg== ----_com.samsung.android.email_189308569651720 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pk1hdHRoZXc8L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlRoYW5rIHlvdSBmb3IgdGhlIFFBIHJldmlldy4gJm5ic3A7VGhlIGF1 dGhvcnMgd2lsbCBnZXQgYmFjayB0byB5b3Ugd2l0aCB0aGVpciBjaGFuZ2VzLjwvZGl2PjxkaXY+ U3VlPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp diBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9y OiM1NzU3NTciPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQmYW1wO1Qg NEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtj b2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdp bmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206ICJCb2NjaSwgTWF0dGhldyAoTm9r aWEgLSBHQikiICZsdDttYXR0aGV3LmJvY2NpQG5va2lhLmNvbSZndDsgPC9kaXY+PGRpdj5EYXRl OiA2LzIxLzIwMTYgIDY6MTAgQU0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IGlkckBpZXRm Lm9yZywgU3VzYW4gSGFyZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDssIGpnc0BqdW5pcGVyLm5l dCwgcnRnLWRpckBpZXRmLm9yZywgZHJhZnQtaWV0Zi1pZHItZXh0LW9wdC1wYXJhbUBpZXRmLm9y ZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFtJZHJdIFJvdXRpbmcgZGlyZWN0b3JhdGUgUUEgcmV2aWV3 IG9mCWRyYWZ0LWlldGYtaWRyLWV4dC1vcHQtcGFyYW0tMDQgPC9kaXY+PGRpdj48YnI+PC9kaXY+ PC9kaXY+CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BdXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgaGF2ZSBiZWVuIGFza2VkIHRvIGRvIGEgUUEgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtaWRyLWV4dC1vcHQtcGFyYW0tMDQudHh0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPlN1bW1hcnk6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlRoZSBkb2N1bWVudCBpcyByZWFzb25hYmx5IHN0cmFpZ2h0IGZvcndhcmQgYW5k IGlzIHdlbGwgd3JpdHRlbi4gSSBoYXZlIGEgZmV3IGNvbW1lbnRzIGJlbG93LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkNv bW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1pbm9yIElz c3Vlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4xKSBTZWN0aW9u IDIsIFByb3RvY29sIEV4dGVuc2lvbnMuCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPllvdSBoYXZlIGxhYmVs bGVkIHRoZSBleGlzdGluZyBMZW5ndGggYW5kIFR5cGUgZmllbGRzIGFzIDB4RkYuIEkgYXNzdW1l IHRoZSBtZWFuaW5nIG9mIHRoZSBzZWNvbmQgaXMgc3RpbGwgJ1R5cGUnIHNpbmNlIHRoYXQgaXMK PG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+d2hhdCBhbnkgaW1wbGVtZW50YXRpb24gd291bGQgcmVhc29uYWJs eSBpbnRlcnByZXQgaXQgYXMsIGFuZCB0aGF0IGlzIHRoZSByZWdpc3RyeSB5b3UgYXJlIHVzaW5n IGEgY29kZSBwb2ludCBmcm9tLiBTbyBpdAo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5taWdodCBiZSBiZXR0 ZXIgdG8gc2F5IGluIHRoZSB0ZXh0IGFib3ZlIHRoZSBmaWd1cmUgYXQgdGhlIHRvcCBvZiBwYWdl IDMgdGhhdCB0aGUgbGVuZ3RoIGFuZCB0eXBlIGZpZWxkcyBpbiBbUkZDNDI3MV0KPG86cD48L286 cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+YXJlIHNldCB0byAweEZGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkFsc28sIHlvdSBkb24ndCBleHBsaWNpdGx5IGRlZmluZSB3aGF0IGEgcmVjZWl2 ZXIgc2hvdWxkIGRvIHdpdGggdGhlIGxlbmd0aCBmaWVsZCBpZiB0aGUgdHlwZSBpcyAweEZGLiBE b2VzIGl0IGlnbm9yZSBpdCwKPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+b3IgZG9lcyBpdCBjaGVjayB0aGF0 IGl0IGlzIDB4RkYgYW5kIHRyZWF0IHRoZSBPUEVOIG1lc3NhZ2UgYXMgbWFsZm9ybWVkIGlmIGl0 IGlzICZsdDsgMHhGRj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5T aW5jZSB0aGUgZG9jdW1lbnQgY2hhbmdlcyB0aGUgcHJvY2VkdXJlcyBpbiBSRkM0MjcxIGZvciBC R1AgT3BlbiBvcHRpb25hbCBwYXJhbWV0ZXJzIHdoZXJlIGxlbmd0aCAmZ3Q7IDI1NSwgaW4gdGhh dCB0aGUKPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+b3JpZ2luYWwgbGVuZ3RoIGZpZWxkIGlzIG5vIGxvbmdl ciB0byBiZSBpbnRlcnByZXRlZCBhcyB0aGUgYWN0dWFsIGxlbmd0aCwgdGhlbiBJIHRoaW5rIHlv dSBzaG91bGQgbWFyayB0aGlzIGRyYWZ0IGFzCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPidVcGRhdGVzOiA0 MjcxJy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4yKSBTZWN0aW9u IDU6IFNlY3VyaXR5IEV4dGVuc2lvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgc2VjdGlvbiBzZWVtcyB0byBiZSBsYWNraW5nIGRldGFpbCBhbmQgYW1vdW50 cyB0byBvbmUgbGluZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsi VGhpcyBleHRlbnNpb24gdG8gQkdQIGRvZXMgbm90IGNoYW5nZSB0aGUgdW5kZXJseWluZyBzZWN1 cml0eSBpc3N1ZXMiPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7SXQg bWlnaHQgYmUgd29ydGggYmVpbmcgYSBsaXR0bGUgbW9yZSBleHBsaWNpdCwgb3IgYXQgbGVhc3Qg dXNlIHdvcmRpbmcgc2ltaWxhciB0byBSRkM1NDkyLCBhbmQgc2F5aW5nIHRoYXQgaXQgZG9lcyBu b3QKPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7YWRkIGFueSBuZXcgc2VjdXJpdHkgaXNzdWVzIHRo YXQgYXJlIG5vdCBpbmhlcmVudCBpbiBCR1AgW1JGQzQyNzJdLiZuYnNwOwo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzPG86cD48 L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TWF0dGhldzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4KPC9kaXY+CjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_189308569651720-- From nobody Wed Jun 22 15:38:25 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50ADC12DD36; Wed, 22 Jun 2016 15:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFUi9c1O0fkd; Wed, 22 Jun 2016 15:38:18 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA6112DD89; Wed, 22 Jun 2016 15:38:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.122.226; Date: Wed, 22 Jun 2016 18:37:53 -0400 Message-ID: Importance: normal From: Susan Hares To: Daniele Ceccarelli , "draft-ietf-idr-bgp-optimal-route-reflection.all@tools.ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_191302545369330" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "rtg-dir@ietf.org" , "idr@ietf.org" Subject: Re: [Idr] [RTG-DIR] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 22:38:20 -0000 ----_com.samsung.android.email_191302545369330 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 RGFuaWVsZToKVGhhbmsgeW91IGZvciByZXZpZXcuIMKgVGhlIGF1dGhvcnMgd2lsbCBnZXQgYmFj ayB0byB5b3Ugd2l0aCB0aGVpciBjaGFuZ2VzLgpTdWUKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBH YWxheHkgTm90ZTUsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUtLS0tLS0tLSBPcmlnaW5hbCBt ZXNzYWdlIC0tLS0tLS0tRnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVs bGlAZXJpY3Nzb24uY29tPiBEYXRlOiA2LzIyLzIwMTYgIDExOjU3IEFNICAoR01ULTA1OjAwKSBU bzogZHJhZnQtaWV0Zi1pZHItYmdwLW9wdGltYWwtcm91dGUtcmVmbGVjdGlvbi5hbGxAdG9vbHMu aWV0Zi5vcmcgQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmcsIGlkckBpZXRmLm9yZyBTdWJqZWN0OiBbUlRH LURJUl0gUlRHIERpciBRQSByZXZpZXcgb2YJZHJhZnQtaWV0Zi1pZHItYmdwLW9wdGltYWwtcm91 dGUtcmVmbGVjdGlvbiAKCgpIZWxsbywKwqAKSSBhbSB0aGUgUm91dGluZyBBcmVhIERpcmVjdG9y YXRlIG1lbWJlciB0aGF0IHdhcyBhc3NpZ25lZCB0aGUgUUEgcmV2aWV3IG9mIGRyYWZ0LWlldGYt aWRyLWJncC1vcHRpbWFsLXJvdXRlLXJlZmxlY3Rpb24uCsKgCklmIHlvdeKAmXJlIG5vdCBmYW1p bGlhciB3aXRoIHRoZSBRQSByZXZpZXcgcHJvY2VzcyBwbGVhc2Ugc2VlOsKgCmh0dHBzOi8vdHJh Yy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyRG9jUWEKwqAKQlIKCkRh bmllbGXCoCAKwqAKLcKgwqDCoMKgwqDCoMKgwqDCoApHZW5lcmFsIGNvbW1lbnQ6ClRoZSBkcmFm dCBpcyB1bmRlcnN0YW5kYWJsZSBhbmQgZG9lcyBub3QgcmVxdWlyZSBhbnkgbWFqb3IgbW9kaWZp Y2F0aW9uIGluIGFkZGl0aW9uIHRvIHRoZSBtaW5vciBlZGl0cyBhbmQgY2xhcmlmaWNhdGlvbnMg c3VnZ2VzdGVkIGJlbG93LgpNeSBjb25jZXJuLCB3aGljaCBpcyBzb21ldGhpbmcgdGhlIHdvcmtp bmcgZ3JvdXAgcHJvYmFibHkgYWxyZWFkeSBkaXNjdXNzZWQsIGlzIGFib3V0IHRoZSBjb21wbGV4 aXR5IGFuZCB1c2VmdWxuZXNzIG9mIHRoZSBpZGVhLgoKVGhlIGdvYWwgb2YgZHJhZnQgaXM6CuKA nMKgwqAgVGhlIGNvcmUgb2YgdGhpcyBzb2x1dGlvbiBpcyB0aGUgYWJpbGl0eSBmb3IgYW4gb3Bl cmF0b3IgdG8gc3BlY2lmeQrCoMKgIG9uIGEgcGVyIHJvdXRlIHJlZmxlY3RvciBiYXNpcyBvciBw ZXIgcGVlci91cGRhdGUgZ3JvdXAgYmFzaXMgb3IgcGVyCsKgwqAgcGVlciBiYXNpcyB0aGUgdmly dHVhbCBJR1AgbG9jYXRpb24gcGxhY2VtZW50IG9mIHRoZSByb3V0ZSByZWZsZWN0b3IuCsKgwqAg VGhpcyBlbmFibGVzIGhhdmluZyBhIGdpdmVuIGdyb3VwIG9mIGNsaWVudHMgcmVjZWl2ZSByb3V0 ZXMgd2l0aArCoMKgIG9wdGltYWwgZGlzdGFuY2UgdG8gdGhlIG5leHQgaG9wcyBmcm9tIHRoZSBw b3NpdGlvbiBvZiB0aGUgY29uZmlndXJlZArCoMKgIHZpcnR1YWwgSUdQIGxvY2F0aW9uLsKgIFRo aXMgYWxzbyBwcm92aWRlcyBmb3IgZnJlZWRvbSBvZiByb3V0ZQrCoMKgIHJlZmxlY3RvciBsb2Nh dGlvbiBhbmQgYWxsb3dzIHRyYW5zaWVudCBvciBwZXJtYW5lbnQgbWlncmF0aW9uIG9mCsKgwqAg c3VjaCBuZXR3b3JrIGNvbnRyb2wgcGxhbmUgZnVuY3Rpb24gdG8gb3B0aW1hbCBsb2NhdGlvbi7i gJ0KQnV0IEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGlzIGEgbnVtYmVyIG9mIHdvcmthcm91bmRz IGFuZCB0aGF0IGRpZmZlcmVudCBwYXRocyBhcmUgYWxyZWFkeSB1c2VkIGZvciByZWR1bmRhbmN5 IHJlYXNvbnMsIGhlbmNlIG15IHF1ZXN0aW9ucyBpczogaXMgaXQgd29ydGggZGVmaW5pbmcgYSBu ZXcgc29sdXRpb24/IElzIHRoZSB1c2FnZSBvZiB0aGUgYWN0dWFsIG1lY2hhbmlzbXMKIHNvIGRp c29wdGltaXplZCB0byByZXF1aXJlIHRoZXNlIGNoYW5nZXM/IEhvdyBtYW55IHBvc3NpYmxlIHBh dGhzIGFyZSB0aGVyZSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBBUyBib3JkZXIgbm9kZT8K wqAKLcKgwqDCoMKgwqDCoMKgwqDCoApBYnN0cmFjdArigJzCoMKgIFRoaXMgZG9jdW1lbnQgcHJv cG9zZXMgYSBzb2x1dGlvbiBmb3IgQkdQIHJvdXRlIHJlZmxlY3RvcnMgdG8gYWxsb3cKwqDCoCB0 aGVtIHRvIGNob29zZSB0aGUgYmVzdCBwYXRoIHRoZWlyIGNsaWVudHMgd291bGQgaGF2ZSBjaG9z ZW4gdW5kZXIKwqDCoCB0aGUgc2FtZSBjb25kaXRpb25zLCB3aXRob3V0IHJlcXVpcmluZyBmdXJ0 aGVyIHN0YXRlIG9yIGFueSBuZXcKwqDCoCBmZWF0dXJlcyB0byBiZSBwbGFjZWQgb24gdGhlIGNs aWVudHPigJ0KVGhpcyBpcyByZWFsbHkgaGFyZCB0byByZWFkLiBNYXliZSBpdCBjb3VsZCBiZSBp bXByb3ZlZCBzdGF0aW5nIHdoYXQgaXMgdGhlIHByb2JsZW0gYW5kIHdoYXQgdGhlIHNvbHV0aW9u IGlzLiBZb3UgY291bGQgY29weSBhIGNvdXBsZSBvZiBzZW50ZW5jZXMgZnJvbSBzZWN0aW9uIDEu MS4gd2hpY2ggaXMgbXVjaCBjbGVhci4KwqAKLcKgwqDCoMKgwqDCoMKgwqDCoApJbnRyb2R1Y3Rp b246CsKgCuKAnCBJbiBzb21lIHNpdHVhdGlvbnMsIHRoaXMgbWV0aG9kIHN1ZmZlcnMgZnJvbSBu b24tb3B0aW1hbCBwYXRoIHNlbGVjdGlvbuKAnS4gV2hpY2ggcGF0aD8gVGhlIG9uZSB1c2VkIHRv IGZvcndhcmQgdGhlIHBhY2tldHM/IFRoZSBvbmUgdXNlZCB0byByZWRpc3RyaWJ1dGUgdGhlIHJv dXRlPyBPcj8KLS0tIApJbiBhIG51bWJlciBvZiBvY2N1cnJlbmNlcyBhY3JvbnltcyBhcmUgbm90 IGV4cGxhaW5lZCBhdCBmaXJzdCB1c2FnZSwgZS5nLiBQT1AsIEwzVlBOLCA2UEXigKYKLS0tCsKg CkFub3RoZXIgZ2VuZXJhbCBjb21tZW50OiBJIGxpa2UgdGhlIHJpY2ggaW50cm8gZnVsbCBvZiBk ZXRhaWxzIG9uIHRoZSBwcm9ibGVtIHN0YXRlbWVudCwgdGhlIGV4aXN0aW5nIHNvbHV0aW9ucyBh bmQgdGhlIHByb3Bvc2VkIG9uZS4gSG93ZXZlciBJ4oCZbSBzdHJ1Z2dsaW5nIHRvIHVuZGVyc3Rh bmQgaG93IGFuIGltcGxlbWVudGF0aW9uIGNvdWxkIGJlIGRlY2xhcmVkIHRvIGJlCiBjb21wbGlh bnQgdG8gdGhpcyBJRC4gVGhlIG9ubHkgdGhpbmcgSSBzZWUgaXMg4oCcdGhlIGltcGxlbWVudGF0 aW9uIE1VU1QgTk9UIHByZXZlbnQgcmVmbGVjdGluZyBtb3JlIHRoYW4gb25lIHBhdGjigJ0gYW5k IGFuIGFuYWxvZyByZXF1aXJlbWVudCB3aGljaCBpcyDigJx0aGUgcm91dGUgcmVmbGVjdG9yIE1V U1QgcmVmbGVjdCBOIG9wdGltYWwgcGF0aHPigJ0uIEkgd291bGQgaGF2ZSBleHBlY3RlZCB0aGlz IHRvIGJlIGFuIGFtZW5kbWVudCB0byB0aGUgZXhpc3RpbmcKIFJGQyB0aGF0IHN0YXRlcyB0aGF0 IGEgc2luZ2xlIHBhdGggY2FuIGJlIHJlZmxlY3RlZC4KwqAKLS0tCsKgCgo= ----_com.samsung.android.email_191302545369330 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkRhbmllbGU6PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5UaGFuayB5b3UgZm9yIHJldmlldy4gJm5ic3A7VGhlIGF1dGhvcnMg d2lsbCBnZXQgYmFjayB0byB5b3Ugd2l0aCB0aGVpciBjaGFuZ2VzLjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+U3VlPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0eWxlPSJmb250LXNpemU6 ODUlO2NvbG9yOiM1NzU3NTciPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBOb3RlNSwgYW4g QVQmYW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNp emU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0t LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IERhbmllbGUgQ2Vj Y2FyZWxsaSAmbHQ7ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbSZndDsgPC9kaXY+PGRp dj5EYXRlOiA2LzIyLzIwMTYgIDExOjU3IEFNICAoR01ULTA1OjAwKSA8L2Rpdj48ZGl2PlRvOiBk cmFmdC1pZXRmLWlkci1iZ3Atb3B0aW1hbC1yb3V0ZS1yZWZsZWN0aW9uLmFsbEB0b29scy5pZXRm Lm9yZyA8L2Rpdj48ZGl2PkNjOiBydGctZGlyQGlldGYub3JnLCBpZHJAaWV0Zi5vcmcgPC9kaXY+ PGRpdj5TdWJqZWN0OiBbUlRHLURJUl0gUlRHIERpciBRQSByZXZpZXcgb2YJZHJhZnQtaWV0Zi1p ZHItYmdwLW9wdGltYWwtcm91dGUtcmVmbGVjdGlvbiA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rp dj4KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gdGhlIFJvdXRpbmcgQXJl YSBEaXJlY3RvcmF0ZSBtZW1iZXIgdGhhdCB3YXMgYXNzaWduZWQgdGhlIFFBIHJldmlldyBvZiBk cmFmdC1pZXRmLWlkci1iZ3Atb3B0aW1hbC1yb3V0ZS1yZWZsZWN0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPklmIHlvdeKAmXJlIG5vdCBmYW1pbGlhciB3aXRoIHRoZSBRQSByZXZpZXcgcHJvY2VzcyBw bGVhc2Ugc2VlOiZuYnNwOwo8YSBocmVmPSJodHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJl YS9ydGcvdHJhYy93aWtpL1J0Z0RpckRvY1FhIj5odHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcv YXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpckRvY1FhPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJSPGJy PgpEYW5pZWxlJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj48IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gbGFuZz0iRU4t VVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2Vu ZGlmXS0tPjxzcGFuIGxhbmc9IkVOLVVTIj5HZW5lcmFsIGNvbW1lbnQ6PG86cD48L286cD48L3Nw YW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGRyYWZ0 IGlzIHVuZGVyc3RhbmRhYmxlIGFuZCBkb2VzIG5vdCByZXF1aXJlIGFueSBtYWpvciBtb2RpZmlj YXRpb24gaW4gYWRkaXRpb24gdG8gdGhlIG1pbm9yIGVkaXRzIGFuZCBjbGFyaWZpY2F0aW9ucyBz dWdnZXN0ZWQgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+TXkgY29uY2Vybiwgd2hpY2ggaXMgc29tZXRoaW5nIHRoZSB3 b3JraW5nIGdyb3VwIHByb2JhYmx5IGFscmVhZHkgZGlzY3Vzc2VkLCBpcyBhYm91dCB0aGUgY29t cGxleGl0eSBhbmQgdXNlZnVsbmVzcyBvZiB0aGUgaWRlYS4KPG86cD48L286cD48L3NwYW4+PC9w Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGdvYWwgb2YgZHJh ZnQgaXM6PG86cD48L286cD48L3NwYW4+PC9wPgo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj7igJw8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGUgY29yZSBvZiB0aGlzIHNv bHV0aW9uIGlzIHRoZSBhYmlsaXR5IGZvciBhbiBvcGVyYXRvciB0byBzcGVjaWZ5PG86cD48L286 cD48L3NwYW4+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvbiBhIHBlciByb3V0ZSByZWZsZWN0b3IgYmFzaXMgb3Ig cGVyIHBlZXIvdXBkYXRlIGdyb3VwIGJhc2lzIG9yIHBlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pgo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBwZWVyIGJhc2lzIHRoZSB2aXJ0dWFsIElHUCBsb2NhdGlvbiBwbGFjZW1lbnQgb2YgdGhlIHJv dXRlIHJlZmxlY3Rvci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVGhpcyBlbmFibGVzIGhhdmlu ZyBhIGdpdmVuIGdyb3VwIG9mIGNsaWVudHMgcmVjZWl2ZSByb3V0ZXMgd2l0aDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBvcHRpbWFsIGRpc3RhbmNlIHRvIHRoZSBuZXh0IGhvcHMgZnJvbSB0aGUg cG9zaXRpb24gb2YgdGhlIGNvbmZpZ3VyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdmlydHVh bCBJR1AgbG9jYXRpb24uJm5ic3A7IFRoaXMgYWxzbyBwcm92aWRlcyBmb3IgZnJlZWRvbSBvZiBy b3V0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyByZWZsZWN0b3IgbG9jYXRpb24gYW5kIGFsbG93 cyB0cmFuc2llbnQgb3IgcGVybWFuZW50IG1pZ3JhdGlvbiBvZjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPgo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBzdWNoIG5ldHdvcmsgY29udHJvbCBwbGFuZSBmdW5jdGlvbiB0byBvcHRpbWFsIGxvY2F0 aW9uLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+QnV0IEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGlzIGEgbnVtYmVyIG9m IHdvcmthcm91bmRzIGFuZCB0aGF0IGRpZmZlcmVudCBwYXRocyBhcmUgYWxyZWFkeSB1c2VkIGZv ciByZWR1bmRhbmN5IHJlYXNvbnMsIGhlbmNlIG15IHF1ZXN0aW9ucyBpczogaXMgaXQgd29ydGgg ZGVmaW5pbmcgYSBuZXcgc29sdXRpb24/IElzIHRoZSB1c2FnZSBvZiB0aGUgYWN0dWFsIG1lY2hh bmlzbXMKIHNvIGRpc29wdGltaXplZCB0byByZXF1aXJlIHRoZXNlIGNoYW5nZXM/IEhvdyBtYW55 IHBvc3NpYmxlIHBhdGhzIGFyZSB0aGVyZSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBBUyBi b3JkZXIgbm9kZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIGxhbmc9IkVOLVVTIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0t LT48c3BhbiBsYW5nPSJFTi1VUyI+QWJzdHJhY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPuKAnDxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBzb2x1dGlvbiBmb3IgQkdQIHJvdXRlIHJlZmxl Y3RvcnMgdG8gYWxsb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wcmU+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpJVCI+Jm5ic3A7Jm5ic3A7IHRoZW0gdG8gY2hvb3NlIHRoZSBiZXN0IHBhdGggdGhl aXIgY2xpZW50cyB3b3VsZCBoYXZlIGNob3NlbiB1bmRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21z by1mYXJlYXN0LWxhbmd1YWdlOklUIj4mbmJzcDsmbmJzcDsgdGhlIHNhbWUgY29uZGl0aW9ucywg d2l0aG91dCByZXF1aXJpbmcgZnVydGhlciBzdGF0ZSBvciBhbnkgbmV3PG86cD48L286cD48L3Nw YW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6SVQiPiZuYnNwOyZuYnNwOyBmZWF0dXJlcyB0byBi ZSBwbGFjZWQgb24gdGhlIGNsaWVudHPigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGlzIGlzIHJlYWxseSBoYXJkIHRvIHJlYWQuIE1heWJlIGl0IGNvdWxkIGJlIGltcHJvdmVk IHN0YXRpbmcgd2hhdCBpcyB0aGUgcHJvYmxlbSBhbmQgd2hhdCB0aGUgc29sdXRpb24gaXMuIFlv dSBjb3VsZCBjb3B5IGEgY291cGxlIG9mIHNlbnRlbmNlcyBmcm9tIHNlY3Rpb24gMS4xLiB3aGlj aCBpcyBtdWNoIGNsZWFyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IS0tW2lmICFzdXBw b3J0TGlzdHNdLS0+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIGxhbmc9IkVOLVVTIj5JbnRy b2R1Y3Rpb246PG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPuKAnCBJbiBzb21lIHNpdHVhdGlvbnMsIHRo aXMgbWV0aG9kIHN1ZmZlcnMgZnJvbSBub24tb3B0aW1hbCBwYXRoIHNlbGVjdGlvbuKAnS4gV2hp Y2ggcGF0aD8gVGhlIG9uZSB1c2VkIHRvIGZvcndhcmQgdGhlIHBhY2tldHM/IFRoZSBvbmUgdXNl ZCB0byByZWRpc3RyaWJ1dGUgdGhlIHJvdXRlPyBPcj88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLSA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBhIG51 bWJlciBvZiBvY2N1cnJlbmNlcyBhY3JvbnltcyBhcmUgbm90IGV4cGxhaW5lZCBhdCBmaXJzdCB1 c2FnZSwgZS5nLiBQT1AsIEwzVlBOLCA2UEXigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5B bm90aGVyIGdlbmVyYWwgY29tbWVudDogSSBsaWtlIHRoZSByaWNoIGludHJvIGZ1bGwgb2YgZGV0 YWlscyBvbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQsIHRoZSBleGlzdGluZyBzb2x1dGlvbnMgYW5k IHRoZSBwcm9wb3NlZCBvbmUuIEhvd2V2ZXIgSeKAmW0gc3RydWdnbGluZyB0byB1bmRlcnN0YW5k IGhvdyBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBiZSBkZWNsYXJlZCB0byBiZQogY29tcGxpYW50 IHRvIHRoaXMgSUQuIFRoZSBvbmx5IHRoaW5nIEkgc2VlIGlzIOKAnHRoZSBpbXBsZW1lbnRhdGlv biBNVVNUIE5PVCBwcmV2ZW50IHJlZmxlY3RpbmcgbW9yZSB0aGFuIG9uZSBwYXRo4oCdIGFuZCBh biBhbmFsb2cgcmVxdWlyZW1lbnQgd2hpY2ggaXMg4oCcdGhlIHJvdXRlIHJlZmxlY3RvciBNVVNU IHJlZmxlY3QgTiBvcHRpbWFsIHBhdGhz4oCdLiBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgdGhpcyB0 byBiZSBhbiBhbWVuZG1lbnQgdG8gdGhlIGV4aXN0aW5nCiBSRkMgdGhhdCBzdGF0ZXMgdGhhdCBh IHNpbmdsZSBwYXRoIGNhbiBiZSByZWZsZWN0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tPG86cD48 L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8L2Rpdj4KPC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_191302545369330-- From nobody Thu Jun 23 06:26:55 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5D812D0A0; Thu, 23 Jun 2016 06:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TT8D0fYyB6Z; Thu, 23 Jun 2016 06:26:47 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E34A12B025; Thu, 23 Jun 2016 06:26:45 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-bc-576be393e0e7 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 18.8E.27088.393EB675; Thu, 23 Jun 2016 15:26:43 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.294.0; Thu, 23 Jun 2016 15:26:42 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+IwxxGo8Ntbw0jVrKSRAUDgcpU2BrFy4fzuDnDpslRA=; b=Z230sQ6C+M0LXqpk/qucWFeQdydwgn1zkI/hp5dsa9b9398V4qUSS5xLR7khfjSeOi3SkVZzAyM15DPLKZwdFb5c/oO5U7BIjqrkqN8n5J/c4yqyoOUc1JApmIjzVk4E+5YxL0qps0KaKuGroHW2XP2Vf2OK+3POKgVZLHVqIvs= Received: from VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) by VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) with Microsoft SMTP Server (TLS) id 15.1.523.12; Thu, 23 Jun 2016 13:26:42 +0000 Received: from VI1PR07MB1005.eurprd07.prod.outlook.com ([10.161.110.21]) by VI1PR07MB1005.eurprd07.prod.outlook.com ([10.161.110.21]) with mapi id 15.01.0523.015; Thu, 23 Jun 2016 13:26:41 +0000 From: Daniele Ceccarelli To: Robert Raszuk Thread-Topic: [Idr] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection Thread-Index: AdHMiqSYAER1UXQQQXKhr6277cbfMwAI2SIAACjHI7A= Date: Thu, 23 Jun 2016 13:26:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [2.112.192.21] x-ms-office365-filtering-correlation-id: 3d43375e-3f09-40ad-bac7-08d39b6a03ad x-microsoft-exchange-diagnostics: 1; VI1PR07MB1005; 6:ez61oSZnigGNsWU9l+iZW7lz9r/8yYlFmbervljOl4Wn5WtmQMSR3//bp1NM2tA71SH7EEqjYLYkBfPdVbPvYBaQx8vJxXpXUxnf4r4p6gi1VPzwbJelB870k2oW+5tEkmcQbsYxEDMb//Zx0XJBpa6+WE/CZW6LKJOGSIMdtkQ1GBmxk2M6mO5iWuDfjj0ZlBvtdv4XKdwtlQlN+ACsO8YTZ80flmDATOqSUPEo+taL99rtXEyW0b6qgaXqEkb/ZSaPnbw4btg7p0YjNx4fytmD0YREjfDBiOxJn3glHg7hP3YEVXZw8aUurs+A7mo/; 5:x0sCL/1QuPSlAe7gw1cJkr7bxwXpJjJNMdP2KaCGkJxfxtXkbVuM45HFDATcVU1uAAofVViqpIxaYV0udO2DYdcWzhPberYy5VRNYzCajWZLey3EnWL7lV1JtSWmOmGh1n2kqDKXx0IpfR9EJvEzCQ==; 24:/bcCA52eWnFeKmzApRhLT0wSj9obuqyH0eMrfKfyPgiLH5tVu4Evp/cbsGj/tltNJV7GZlPJox/YZM+yqLF4AmWVGgcuUyfbdmqeKTbMJKs=; 7:hZwUk1nB4abbNx70W0BUZG3rmHuGd4i5RMfdxWL6t+gh0FufwEexGh+yOOcXB8Gv1y/xyEByXPgHFbjziAKBEmb/ergjYKNWrEQscR8Cfv4g2nit3zoo4PsS5g9FGudm1Yt5Rc/9j/DTM28BeShBY8soRhlApAnIKboj0U4PBJi6WWumnWVvy4PSTi8TE8AEuz1yAxFsncoQFLGlyQtM1FwIHGWBPZkq5aqezZE+TTA519ZNP2I/ZF+sdKYomshF89AOpAdvF3c10MaNPDem8A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1005; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(190756311086443)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR07MB1005; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1005; x-forefront-prvs: 098291215C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(110136002)(106356001)(16236675004)(15975445007)(105586002)(10400500002)(19300405004)(19580405001)(2900100001)(2950100001)(77096005)(189998001)(97736004)(122556002)(87936001)(561944003)(86362001)(33656002)(92566002)(66066001)(19580395003)(7846002)(7736002)(7696003)(19625215002)(50986999)(8936002)(6116002)(5002640100001)(81166006)(790700001)(8676002)(68736007)(9686002)(81156014)(5890100001)(3846002)(586003)(74316001)(102836003)(101416001)(3280700002)(3660700001)(230783001)(5003600100003)(76576001)(2906002)(76176999)(4326007)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1005; H:VI1PR07MB1005.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB1005CECFE6384F10BB611261F02D0VI1PR07MB1005eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2016 13:26:41.6895 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1005 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyzUYRzHe+77/d59j257XOSTbLimkJD541JTrWb+oGjzI7V08h06v3aH 0Ba7sfKridYQYndlDBdT0fVD50eSIlZLP0x3UqfaahUVa/l6tPnv9Xze7/fzeT6fPSwl7WYc 2MSUdE6VokiSCa3oqqhb0dsqzMpIn5e1rvLeqSe0fPb1jECuadBQ8vqW96I9dJBO91sQZGiv FwT9GP8uDKWirXbFcUmJmZzKO+C4VcKlnjyUNlqDsubfForyUFclKkJiFrAfDBc1iwivh9FJ vbAIWbFS3IegtaeR5gUpHkTQ2UrzAo1LKTB9LRcQ1wsEf87OIXIYQPBT188UIZYVYn+YNgbz aVvsCoWDJor3UHgEwU1NKcML63A4WAznGGKKgM/dQzRhfxibKRTwTC+Fm1tMQv5OCT4Kd/MV pJcWga70Os3XxTgMhi+483a0NML8UMtylML28Gr6ioCMhkF3Z4QibAcW81+G+GNBX9C14nGG yY4BIeEQaJ8yLK8CcLUIWg3PaCIEQl9J08q+lNCmXVwJH4ESTSNNAnoEE00GhgiOoB2Zp4gw z8CnwgqGLJWDxtYCVIY8qle9lnAqXGswMTxLsA08qpqmq5cGpbA76G97E4sLXCx+JyLsBgU1 taLV9XokakZ2ak4dmxzv6+vFqRJPqNWpKV4pXHoHWvpQDzoXfLqQ5cNeI8Iskq2VOI+djJQy ikx1drIRAUvJbCUZU8pIqSROkZ3DqVJjVBlJnNqINrK0zF5y0OISKcXxinROyXFpnOq/KmDF Dnmo45s86s0aJ2G0Kcy7f+jjhLhxt4vv/mJz0z6H3Nynp8U74u6HxDz01CTu3BTQ21bOSXXH cgPPO/6aDT6wIdS5oE6WPRftl6W0+Iwdtr4XBpWei3kNB5y0drV1h/RuC8+7N4+O158KeJxp 8yXCHJ6fM5J/42rXzBmD9dYt2uwyw+U4Ga1OUGz3oFRqxT/jhKfSTAMAAA== Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-idr-bgp-optimal-route-reflection.all@tools.ietf.org" , "idr@ietf.org" Subject: Re: [Idr] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 13:26:50 -0000 --_000_VI1PR07MB1005CECFE6384F10BB611261F02D0VI1PR07MB1005eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpUaGFua3MgYSBsb3QgZm9yIHRoZSB1c2VmdWwgaW5mby4gSSBndWVzcyB0 aGlzIGlzIHdlbGwga25vd24gdG8gSURSIGV4cGVydHMgYnV0IGFkZGluZyB0aGlzIGV4cGxhbmF0 aW9uIGNvbnRlbnQgdG8gdGhlIGRyYWZ0IHdvdWxkIGJlIGV4dHJlbWVseSBoZWxwZnVsIGZvciBu ZXdiaWVzLg0KDQpCUg0KRGFuaWVsZQ0KDQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWls dG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBt ZXJjb2xlZMOsIDIyIGdpdWdubyAyMDE2IDE5OjQ3DQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpIDxk YW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPg0KQ2M6IGRyYWZ0LWlldGYtaWRyLWJncC1v cHRpbWFsLXJvdXRlLXJlZmxlY3Rpb24uYWxsQHRvb2xzLmlldGYub3JnOyBydGctZGlyQGlldGYu b3JnOyBpZHJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRyXSBSVEcgRGlyIFFBIHJldmlldyBv ZiBkcmFmdC1pZXRmLWlkci1iZ3Atb3B0aW1hbC1yb3V0ZS1yZWZsZWN0aW9uDQoNCkhpIERhbmll bGUsDQoNCk1hbnkgdGh4IGZvciB5b3VyIHJldmlldy4gV2hpbGUgSSB3aWxsIGNsYXJpZnkgc29t ZSB0ZXh0IHlvdSBwb2ludGVkIHRvIGluIHRoZSBkcmFmdCBsZXQgbWUgYWxzbyBhbnN3ZXIgc29t ZSBvZiB5b3VyIHF1ZXN0aW9ucyBiZWxvdy4NCg0KQnV0IEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJl IGlzIGEgbnVtYmVyIG9mIHdvcmthcm91bmRzIGFuZCB0aGF0IGRpZmZlcmVudCBwYXRocyBhcmUg YWxyZWFkeSB1c2VkIGZvciByZWR1bmRhbmN5IHJlYXNvbnMsIGhlbmNlIG15IHF1ZXN0aW9ucyBp czogaXMgaXQgd29ydGggZGVmaW5pbmcgYSBuZXcgc29sdXRpb24/DQoNCuKAi0FjdHVhbGx5IGN1 cnJlbnQgd29ya2Fyb3VuZHMgYXJlIHZlcnkgbGltaXRlZCB0byBlaXRoZXIgaW5zdGFsbGluZyDi gItwaHlzaWNhbCBoYXJkd2FyZSBhdCB2YXJpb3VzIElHUCBsb2NhdGlvbnMgb3Igd2hhdCBpcyBx dWl0ZSB1bmxpa2VseSB0byBhdHRhY2ggUm91dGUgUmVmbGVjdG9ycyBvdmVyIG1hbnVhbGx5IGNy ZWF0ZWQgdHVubmVscy4NCg0KTGV0J3MgYWxzbyBvYnNlcnZlIGhlcmUgdGhhdCB0aGUgcGFyYWRp Z20gb2YgY29udHJvbCBwbGFuZSBpcyBzaGlmdGluZyBmcm9tIHRyYWRpdGlvbmFsIHJvdXRlcnMg dG8geDg2IHZpcnR1YWwgc3BhY2Ugb3IgZXZlbiBjbG91ZC4gQXMgcmVzdWx0IHdpdGhvdXQgdGhp cyBwcm9wb3NhbCBvcGVyYXRvcnMgaGF2ZSBjaG9pY2Ugb2YgdGhlaXIgcm91dGUgcmVmbGVjdG9y cyBkaXN0cmlidXRpbmcgc3Vib3B0aW1hbCBwYXRocyBvciBkaXN0cmlidXRpbmcgYWxsIHBhdGhz IGFuZCBpbiB0dXJuIGFsbG93aW5nIGNsaWVudHMgdG8gbWFrZSBpbmRlcGVuZGVudCBiZXN0IHBh dGggc2VsZWN0aW9uLg0KDQpOb3cgd2hpbGUgdGhlIGxhdHRlciBjb3VsZCBiZSBldmVuIGFuIG9w dGlvbiBpbiByb3V0ZXIncyB3b3JsZCBtb3JlIGFuZCBtb3JlIEJHUCBpcyBiZWluZyBvYnNlcnZl ZCBvbiB0aGUgY29tcHV0ZSBzZXJ2ZXJzIHdoZXJlIHNlbmRpbmcgdGhlcmUgYWxsIHByZXNlbnQg aW4gYW4gQVMgQkdQIHBhdGhzIHdvdWxkIGJlIGZvciBvbmUgdW5kZXNpcmVkIGFzIHdlbGwgd291 bGQgcmVxdWlyZSB0byBydW4gYWxzbyBJR1Agb24gdGhvc2UgY29tcHV0ZSBtYWNoaW5lcy4gT2Yg Y291cnNlIEkgYW0gdGFsa2luZyBhYm91dCB0aGUgY2FzZSB3aGVyZSB3ZSB1c2UgSUJHUCBpbiBz dWNoIHNldHVwLg0KDQpJcyB0aGUgdXNhZ2Ugb2YgdGhlIGFjdHVhbCBtZWNoYW5pc21zIHNvIGRp c29wdGltaXplZCB0byByZXF1aXJlIHRoZXNlIGNoYW5nZXM/DQoNCuKAi0l0IGlzIHVuZm9ydHVu YXRlbHkuIFRyYWRpdGlvbmFsbHkgUlJzIHdlcmUgYWxsIGZpbmUgYXMgdGhleSB3ZXJlIGluIHRo ZSBkYXRhIHBhdGguIFRoZW4gY2FtZSBNUExTIGFuZCBsYXRlciBvdGhlciBlbmNhcHN1bGF0aW9u cyB3aGVyZSBvbmx5IGluZ3Jlc3Mgbm9kZSBzdGFydGVkIHRvIG1ha2UgYSBkZWNpc2lvbiB0byB3 aGljaCBuZXh0IGhvcCB0dW5uZWwgdGhlIHBhY2tldCBoZWNlIFJScyBtaWdyYXRlZCBmcm9tIGRh dGEgcGxhbmUgdG8gc29tZXdoZXJlIG9uIHRoZSBzdGljay4NCg0KQW5kIHRoYXQgd2FzIHRoZSBv cmlnaW4gb2YgdGhlIHByb2JsZW0gd2UgZmFjZSB0b2RheSB0aGF0IGVpdGhlciBlYWNoIGluZ3Jl c3MgbXVjaCBoYXZlIGFsbCB0aGUgcGF0aHMgb3IgaXQgZ2V0J3MgdG8gZXhpdCB2aWEgc3Vib3B0 aW1hbCBlZ3Jlc3MuDQoNCg0KSG93IG1hbnkgcG9zc2libGUgcGF0aHMgYXJlIHRoZXJlIGJldHdl ZW4gdGhlIGNsaWVudCBhbmQgdGhlIEFTIGJvcmRlciBub2RlPw0KDQrigItUaGF0IGRlcGVuZHMu IEkgaGF2ZSBzZWVuIGFueXdoZXJlIGZyb20gMi00IHRvIDEwMHMgd2hlcmUgc2F5IGVhY2ggQVMg KG91dCBvZiB0aHJlZSBtYWpvciBTUHMgaW4gdGhlIGNvdW50cnkpIGlzIEVCR1AgcGVlcmluZyBs b2NhbGx5IHdpdGggb3RoZXIgdHdvIGluIGVhY2ggbWV0cm8gb3IgaW4gZWFjaCBwcmVmZWN0dXJl IC0gYW5kIHRoZXkgZG8gaXQgdG8gb3B0aW1pemUgZXhpdCByYXRoZXIgdGhlbiBhbHdheXMgdHJh dmVyc2UgVG9reW8gb3IgT3Nha2EuDQoNCg0KQW5vdGhlciBnZW5lcmFsIGNvbW1lbnQ6IEkgbGlr ZSB0aGUgcmljaCBpbnRybyBmdWxsIG9mIGRldGFpbHMgb24gdGhlIHByb2JsZW0gc3RhdGVtZW50 LCB0aGUgZXhpc3Rpbmcgc29sdXRpb25zIGFuZCB0aGUgcHJvcG9zZWQgb25lLiBIb3dldmVyIEni gJltIHN0cnVnZ2xpbmcgdG8gdW5kZXJzdGFuZCBob3cgYW4gaW1wbGVtZW50YXRpb24gY291bGQg YmUgZGVjbGFyZWQgdG8gYmUgY29tcGxpYW50IHRvIHRoaXMgSUQuIFRoZSBvbmx5IHRoaW5nIEkg c2VlIGlzIOKAnHRoZSBpbXBsZW1lbnRhdGlvbiBNVVNUIE5PVCBwcmV2ZW50IHJlZmxlY3Rpbmcg bW9yZSB0aGFuIG9uZSBwYXRo4oCdIGFuZCBhbiBhbmFsb2cgcmVxdWlyZW1lbnQgd2hpY2ggaXMg 4oCcdGhlIHJvdXRlIHJlZmxlY3RvciBNVVNUIHJlZmxlY3QgTiBvcHRpbWFsIHBhdGhz4oCdLiBJ IHdvdWxkIGhhdmUgZXhwZWN0ZWQgdGhpcyB0byBiZSBhbiBhbWVuZG1lbnQgdG8gdGhlIGV4aXN0 aW5nIFJGQyB0aGF0IHN0YXRlcyB0aGF0IGEgc2luZ2xlIHBhdGggY2FuIGJlIHJlZmxlY3RlZC4N Cg0K4oCLSW1wbGVtZW50YXRpb24gYmFzaWNhbGx5IHNob3VsZCBhbGxvdyDigIt0byBjb25maWd1 cmUgcGVyIGluc3RhbmNlIG9yIHBlciBncm91cCBvZiBwZWVycyBsb2dpY2FsIGxvY2F0aW9uIGZy b20gd2hpY2ggZWl0aGVyIGZvciB0aGUgZW50aXJlIGluc3RhbmNlIG9yIGZvciBzZXQgb2YgcGVl cnMgYmVzdCBwYXRoIHdpbGwgYmUgY29tcHV0ZWQuDQoNCk1hbnkgdGh4IG9uY2UgYWdhaW4sDQpS b2JlcnQuDQoNCg== --_000_VI1PR07MB1005CECFE6384F10BB611261F02D0VI1PR07MB1005eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iSVQiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFJvYmVydCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MgYSBsb3QgZm9yIHRoZSB1 c2VmdWwgaW5mby4gSSBndWVzcyB0aGlzIGlzIHdlbGwga25vd24gdG8gSURSIGV4cGVydHMgYnV0 IGFkZGluZyB0aGlzIGV4cGxhbmF0aW9uIGNvbnRlbnQgdG8gdGhlIGRyYWZ0IHdvdWxkIGJlDQog ZXh0cmVtZWx5IGhlbHBmdWwgZm9yIG5ld2JpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+QlI8YnI+DQpEYW5pZWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJh c3p1a0BnbWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8 Yj5TZW50OjwvYj4gbWVyY29sZWTDrCAyMiBnaXVnbm8gMjAxNiAxOTo0Nzxicj4NCjxiPlRvOjwv Yj4gRGFuaWVsZSBDZWNjYXJlbGxpICZsdDtkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gZHJhZnQtaWV0Zi1pZHItYmdwLW9wdGltYWwtcm91dGUtcmVm bGVjdGlvbi5hbGxAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmc7IGlkckBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkcl0gUlRHIERpciBRQSByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1pZHItYmdwLW9wdGltYWwtcm91dGUtcmVmbGVjdGlvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIERhbmllbGUsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5NYW55IHRoeCBmb3IgeW91ciByZXZpZXcuIFdoaWxlIEkgd2lsbCBjbGFyaWZ5IHNvbWUg dGV4dCB5b3UgcG9pbnRlZCB0byBpbiB0aGUgZHJhZnQgbGV0IG1lIGFsc28gYW5zd2VyIHNvbWUg b2YgeW91ciBxdWVzdGlvbnMgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5CdXQgSSB1bmRlcnN0YW5kIHRoYXQgdGhl cmUgaXMgYSBudW1iZXIgb2Ygd29ya2Fyb3VuZHMgYW5kIHRoYXQgZGlmZmVyZW50IHBhdGhzIGFy ZSBhbHJlYWR5IHVzZWQgZm9yIHJlZHVuZGFuY3kgcmVhc29ucywgaGVuY2UgbXkgcXVlc3Rpb25z IGlzOiBpcyBpdCB3b3J0aCBkZWZpbmluZw0KIGEgbmV3IHNvbHV0aW9uPyA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj7igItBY3R1YWxseSBjdXJyZW50IHdvcmthcm91bmRzIGFyZSB2 ZXJ5IGxpbWl0ZWQgdG8gZWl0aGVyIGluc3RhbGxpbmcg4oCLcGh5c2ljYWwgaGFyZHdhcmUgYXQg dmFyaW91cyBJR1AgbG9jYXRpb25zIG9yIHdoYXQgaXMgcXVpdGUgdW5saWtlbHkgdG8gYXR0YWNo IFJvdXRlIFJlZmxlY3RvcnMgb3ZlciBtYW51YWxseSBjcmVhdGVkIHR1bm5lbHMuJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5MZXQncyBhbHNvIG9ic2VydmUgaGVyZSB0aGF0IHRoZSBwYXJhZGlnbSBvZiBjb250cm9s IHBsYW5lIGlzIHNoaWZ0aW5nIGZyb20gdHJhZGl0aW9uYWwgcm91dGVycyB0byB4ODYgdmlydHVh bCBzcGFjZSBvciBldmVuIGNsb3VkLiBBcyByZXN1bHQgd2l0aG91dCB0aGlzIHByb3Bvc2FsIG9w ZXJhdG9ycyBoYXZlIGNob2ljZSBvZiB0aGVpcg0KIHJvdXRlIHJlZmxlY3RvcnMgZGlzdHJpYnV0 aW5nIHN1Ym9wdGltYWwgcGF0aHMgb3IgZGlzdHJpYnV0aW5nIGFsbCBwYXRocyBhbmQgaW4gdHVy biBhbGxvd2luZyBjbGllbnRzIHRvIG1ha2UgaW5kZXBlbmRlbnQgYmVzdCBwYXRoIHNlbGVjdGlv bi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPk5vdyB3aGlsZSB0aGUgbGF0dGVyIGNvdWxkIGJlIGV2ZW4gYW4gb3B0 aW9uIGluIHJvdXRlcidzIHdvcmxkIG1vcmUgYW5kIG1vcmUgQkdQIGlzIGJlaW5nIG9ic2VydmVk IG9uIHRoZSBjb21wdXRlIHNlcnZlcnMgd2hlcmUgc2VuZGluZyB0aGVyZSBhbGwgcHJlc2VudCBp biBhbiBBUyBCR1AgcGF0aHMgd291bGQgYmUgZm9yIG9uZSB1bmRlc2lyZWQNCiBhcyB3ZWxsIHdv dWxkIHJlcXVpcmUgdG8gcnVuIGFsc28gSUdQIG9uIHRob3NlIGNvbXB1dGUgbWFjaGluZXMuIE9m IGNvdXJzZSBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIGNhc2Ugd2hlcmUgd2UgdXNlIElCR1AgaW4g c3VjaCBzZXR1cC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5J cyB0aGUgdXNhZ2Ugb2YgdGhlIGFjdHVhbCBtZWNoYW5pc21zIHNvIGRpc29wdGltaXplZCB0byBy ZXF1aXJlIHRoZXNlIGNoYW5nZXM/DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj7i gItJdCBpcyB1bmZvcnR1bmF0ZWx5LiBUcmFkaXRpb25hbGx5IFJScyB3ZXJlIGFsbCBmaW5lIGFz IHRoZXkgd2VyZSBpbiB0aGUgZGF0YSBwYXRoLiBUaGVuIGNhbWUgTVBMUyBhbmQgbGF0ZXIgb3Ro ZXIgZW5jYXBzdWxhdGlvbnMgd2hlcmUgb25seSBpbmdyZXNzIG5vZGUgc3RhcnRlZCB0byBtYWtl IGEgZGVjaXNpb24gdG8gd2hpY2gNCiBuZXh0IGhvcCB0dW5uZWwgdGhlIHBhY2tldCBoZWNlIFJS cyBtaWdyYXRlZCBmcm9tIGRhdGEgcGxhbmUgdG8gc29tZXdoZXJlIG9uIHRoZSBzdGljay4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPkFuZCB0aGF0IHdhcyB0aGUgb3JpZ2luIG9mIHRoZSBwcm9ibGVtIHdlIGZhY2Ug dG9kYXkgdGhhdCBlaXRoZXIgZWFjaCBpbmdyZXNzIG11Y2ggaGF2ZSBhbGwgdGhlIHBhdGhzIG9y IGl0IGdldCdzIHRvIGV4aXQgdmlhIHN1Ym9wdGltYWwgZWdyZXNzLiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SG93IG1hbnkgcG9zc2libGUgcGF0aHMgYXJl IHRoZXJlIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIEFTIGJvcmRlciBub2RlPzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPuKAi1RoYXQgZGVwZW5kcy4gSSBoYXZlIHNlZW4gYW55 d2hlcmUgZnJvbSAyLTQgdG8gMTAwcyB3aGVyZSBzYXkgZWFjaCBBUyAob3V0IG9mIHRocmVlIG1h am9yIFNQcyBpbiB0aGUgY291bnRyeSkgaXMgRUJHUCBwZWVyaW5nIGxvY2FsbHkgd2l0aCBvdGhl ciB0d28gaW4gZWFjaCBtZXRybyBvciBpbiBlYWNoIHByZWZlY3R1cmUgLSBhbmQNCiB0aGV5IGRv IGl0IHRvIG9wdGltaXplIGV4aXQgcmF0aGVyIHRoZW4gYWx3YXlzIHRyYXZlcnNlIFRva3lvIG9y IE9zYWthLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+QW5vdGhlciBnZW5lcmFsIGNvbW1lbnQ6IEkgbGlrZSB0aGUgcmljaCBpbnRybyBmdWxsIG9m IGRldGFpbHMgb24gdGhlIHByb2JsZW0gc3RhdGVtZW50LCB0aGUgZXhpc3Rpbmcgc29sdXRpb25z IGFuZCB0aGUgcHJvcG9zZWQgb25lLiBIb3dldmVyIEnigJltIHN0cnVnZ2xpbmcgdG8gdW5kZXJz dGFuZCBob3cgYW4NCiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBiZSBkZWNsYXJlZCB0byBiZSBjb21w bGlhbnQgdG8gdGhpcyBJRC4gVGhlIG9ubHkgdGhpbmcgSSBzZWUgaXMg4oCcdGhlIGltcGxlbWVu dGF0aW9uIE1VU1QgTk9UIHByZXZlbnQgcmVmbGVjdGluZyBtb3JlIHRoYW4gb25lIHBhdGjigJ0g YW5kIGFuIGFuYWxvZyByZXF1aXJlbWVudCB3aGljaCBpcyDigJx0aGUgcm91dGUgcmVmbGVjdG9y IE1VU1QgcmVmbGVjdCBOIG9wdGltYWwgcGF0aHPigJ0uIEkgd291bGQgaGF2ZSBleHBlY3RlZA0K IHRoaXMgdG8gYmUgYW4gYW1lbmRtZW50IHRvIHRoZSBleGlzdGluZyBSRkMgdGhhdCBzdGF0ZXMg dGhhdCBhIHNpbmdsZSBwYXRoIGNhbiBiZSByZWZsZWN0ZWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj7igItJbXBsZW1lbnRhdGlvbiBiYXNpY2FsbHkgc2hvdWxkIGFsbG93IOKAi3RvIGNvbmZp Z3VyZSBwZXIgaW5zdGFuY2Ugb3IgcGVyIGdyb3VwIG9mIHBlZXJzIGxvZ2ljYWwgbG9jYXRpb24g ZnJvbSB3aGljaCBlaXRoZXIgZm9yIHRoZSBlbnRpcmUgaW5zdGFuY2Ugb3IgZm9yIHNldCBvZiBw ZWVycyBiZXN0IHBhdGggd2lsbCBiZSBjb21wdXRlZC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk1hbnkgdGh4IG9u Y2UgYWdhaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPlJvYmVydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_VI1PR07MB1005CECFE6384F10BB611261F02D0VI1PR07MB1005eurp_-- From nobody Thu Jun 23 06:27:48 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70D8128874 for ; Thu, 23 Jun 2016 06:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u2IZKsVESRM for ; Thu, 23 Jun 2016 06:27:45 -0700 (PDT) Received: from seele.lamehost.it (seele.lamehost.it [80.76.80.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB3D12D126 for ; Thu, 23 Jun 2016 06:18:38 -0700 (PDT) Received: by seele.lamehost.it (Postfix, from userid 33) id B77E274391; Thu, 23 Jun 2016 15:18:36 +0200 (CEST) To: Robert Raszuk X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 23 Jun 2016 15:18:36 +0200 From: Marco Marzetti In-Reply-To: References: <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> <20160620131112.GE2950@pfrc.org> Message-ID: X-Sender: marco@lamehost.it User-Agent: Roundcube Webmail/1.1.5 Archived-At: Cc: idr wg , rraszuk@gmail.com Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 13:27:47 -0000 On 2016-06-20 23:56, Robert Raszuk wrote: > Hi Marco, > > Altering AS_PATH indeed does not happen that often. Let's put that one > aside keeping in mind that practical use cases exists where adding an > AS is needed which to me precludes "MUST". > > But I can't agree with statement that IXP RS "should be as transparent > as possible to route propagation" as every IX which assists in routes > handling offers extensive RS to client (and to some level even client > to RS) filtering policies. > > Ref: > https://ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers > > That proves black on white that "transparency" is gone. Now the > question is if we should RFC something which would be completely > unpractical or unusable ? > > Many thx, > R. Robert, My apologies if it took me so long to reply. Even if i agree on some of your points we obviously have very different opinions. And it is kinda funny that you've linked a documents that says """ Maintain your peering policy The route server has built in filters that allow you to maintain your peering policies """ How could I maintain my peering policy if for whatever reasons the route server is adding its ASn in the PATH? Anyway, as said, i agree that the are some very particular cases in which that is needed. On top of all of them: the BGP stacks that rely on that behavior for whatever reason. That said i would like to clarify that i'd really prefer that the author use MUST instead of SHOULD (because, in my opinion, we should have those stacks fixed instead of adjusting a standard to embrace them) but i agree that it may not be advisable for the time being. So i think that we can use SHOULD and add further clarification that explains why that should be avoided when possible. Regards -- Marco From nobody Fri Jun 24 09:00:43 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAA612DC46; Fri, 24 Jun 2016 09:00:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160037.10933.255.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:37 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] idr - Requested session has been scheduled for IETF 96 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:38 -0000 Dear Susan Hares, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. idr Session 1 (2:30:00) Tuesday, Morning Session I 1000-1230 Room Name: Schoeneberg size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: trill i2rs i2nsf netconf bess sidr netmod rtgwg Second Priority: sdnrg nfvrg teas Third Priority: dots rtgarea Special Requests: Please group at beginning of week or end of week. You can also do a 2.5 hr session if that works for the schedule. --------------------------------------------------------- From nobody Fri Jun 24 09:14:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9929C12D18A; Fri, 24 Jun 2016 09:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js7P3IeoNKb5; Fri, 24 Jun 2016 09:14:20 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5E212DD7E; Fri, 24 Jun 2016 09:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16151; q=dns/txt; s=iport; t=1466784431; x=1467994031; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OPY5CyJlk2ue9TKxvmkZOevE8QIpWvbJQdkHVTyE4Xo=; b=cGn0i+aezg8f2ismYq5e8dW9KOXo6erSfVIVq5KMtBup9cCaJkF+xzBY DyJ5a2VsmkEjlFK9b5mVm32U7ASSBdm4yz3uyNoFO3zT0ZYcGRxvsfZGb IOR8/oQfEKupqT1XgQ20dwNCAkLEqSkbAksIfMcqgMGy5LB+VheicY+ea M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AgADWm1X/5FdJa1cgnBOVn21JYUBg?= =?us-ascii?q?XsXAQqFdgKBMjgUAQEBAQEBAWUnhE0BAQQBAQEqQQsQAgEIPwcnCxQRAQEEDgU?= =?us-ascii?q?biBUOxnQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYogXeCVodsgi8Fk0yFNAGGB?= =?us-ascii?q?4gsgWmEU4MuhTmGU4kqAR42g3BuAYkvAQEB?= X-IronPort-AV: E=Sophos;i="5.26,521,1459814400"; d="scan'208,217";a="289739036" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jun 2016 16:07:10 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5OG7AXU031706 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Jun 2016 16:07:10 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 24 Jun 2016 11:07:09 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1104.009; Fri, 24 Jun 2016 11:07:09 -0500 From: "Jakob Heitz (jheitz)" To: Daniele Ceccarelli Thread-Topic: [Idr] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection Thread-Index: AdHMiqSYAER1UXQQQXKhr6277cbfMwBp9Fpk Date: Fri, 24 Jun 2016 16:07:09 +0000 Message-ID: <979D933F-1A71-41C2-877B-344921DBC159@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_979D933F1A7141C2877B344921DBC159ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-idr-bgp-optimal-route-reflection.all@tools.ietf.org" , "idr@ietf.org" Subject: Re: [Idr] RTG Dir QA review of draft-ietf-idr-bgp-optimal-route-reflection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:14:22 -0000 --_000_979D933F1A7141C2877B344921DBC159ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Daniele, There are frequently more than 10 paths per net in a route reflector. Sendi= ng all those paths to clients exceeds their memory. It is not cost effectiv= e to upgrade all the clients to be able to consume all the paths. Thanks, Jakob. On Jun 22, 2016, at 9:07 AM, Daniele Ceccarelli > wrote: Hello, I am the Routing Area Directorate member that was assigned the QA review of= draft-ietf-idr-bgp-optimal-route-reflection. If you're not familiar with the QA review process please see: https://trac= .tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa BR Daniele - General comment: The draft is understandable and does not require any major modification in = addition to the minor edits and clarifications suggested below. My concern, which is something the working group probably already discussed= , is about the complexity and usefulness of the idea. The goal of draft is: " The core of this solution is the ability for an operator to specify on a per route reflector basis or per peer/update group basis or per peer basis the virtual IGP location placement of the route reflector. This enables having a given group of clients receive routes with optimal distance to the next hops from the position of the configured virtual IGP location. This also provides for freedom of route reflector location and allows transient or permanent migration of such network control plane function to optimal location." But I understand that there is a number of workarounds and that different p= aths are already used for redundancy reasons, hence my questions is: is it = worth defining a new solution? Is the usage of the actual mechanisms so dis= optimized to require these changes? How many possible paths are there betwe= en the client and the AS border node? - Abstract " This document proposes a solution for BGP route reflectors to allow them to choose the best path their clients would have chosen under the same conditions, without requiring further state or any new features to be placed on the clients" This is really hard to read. Maybe it could be improved stating what is the= problem and what the solution is. You could copy a couple of sentences fro= m section 1.1. which is much clear. - Introduction: " In some situations, this method suffers from non-optimal path selection".= Which path? The one used to forward the packets? The one used to redistrib= ute the route? Or? --- In a number of occurrences acronyms are not explained at first usage, e.g. = POP, L3VPN, 6PE... --- Another general comment: I like the rich intro full of details on the probl= em statement, the existing solutions and the proposed one. However I'm stru= ggling to understand how an implementation could be declared to be complian= t to this ID. The only thing I see is "the implementation MUST NOT prevent = reflecting more than one path" and an analog requirement which is "the rout= e reflector MUST reflect N optimal paths". I would have expected this to be= an amendment to the existing RFC that states that a single path can be ref= lected. --- _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_979D933F1A7141C2877B344921DBC159ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Daniele,

There are frequently more than 10 paths per = net in a route reflector. Sending all those paths to clients exceeds their = memory. It is not cost effective to upgrade all the clients to be able to c= onsume all the paths.

Thanks,
Jakob.


On Jun 22, 2016, at 9:07 AM, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> wrote:<= br>

Hello,

 

I am the Routing Area Directora= te member that was assigned the QA review of draft-ietf-idr-bgp-optimal-rou= te-reflection.

 

If you’re not familiar wi= th the QA review process please see:  http= s://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

 

BR
Daniele 

 

- &= nbsp;        General comment:

The draft is understandable and= does not require any major modification in addition to the minor edits and= clarifications suggested below.

My concern, which is something = the working group probably already discussed, is about the complexity and u= sefulness of the idea.

The goal of draft is:

“   T=
he core of this solution is the ability for an operator to specify
   on a per route=
 reflector basis or per peer/update group basis or per

   peer basis the=
 virtual IGP location placement of the route reflector.

   This enables h=
aving a given group of clients receive routes with


   optimal distan=
ce to the next hops from the position of the configured

   virtual IGP lo=
cation.  This also provides for freedom of route

   reflector loca=
tion and allows transient or permanent migration of


   such network c=
ontrol plane function to optimal location.”


But I understand that there is =
a number of workarounds and that different paths are already used for redun=
dancy reasons, hence my questions is: is it worth defining a new solution? =
Is the usage of the actual mechanisms
 so disoptimized to require these changes? How many possible paths are ther=
e between the client and the AS border node?


 


- &=
nbsp;       
Abstract=



“   T=
his document proposes a solution for BGP route reflectors to allow


 &=
nbsp; them to choose the best path their clients would have chosen under


 &=
nbsp; the same conditions, without requiring further state or any new<=
/o:p>


 &=
nbsp; features to be placed on the clients”


Th=
is is really hard to read. Maybe it could be improved stating what is the p=
roblem and what the solution is. You could copy a couple of sentences from =
section 1.1. which is much clear.


 


- &=
nbsp;       
Introduction:<=
/o:p>


 


“ In some situations,=
 this method suffers from non-optimal path selection”. Which path? Th=
e one used to forward the packets? The one used to redistribute the route? =
Or?


--- 


In a number of occurrences acro=
nyms are not explained at first usage, e.g. POP, L3VPN, 6PE…


---


 


Another general comment: I like=
 the rich intro full of details on the problem statement, the existing solu=
tions and the proposed one. However I’m struggling to understand how =
an implementation could be declared to be
 compliant to this ID. The only thing I see is “the implementation MU=
ST NOT prevent reflecting more than one path” and an analog requireme=
nt which is “the route reflector MUST reflect N optimal paths”.=
 I would have expected this to be an amendment to the existing
 RFC that states that a single path can be reflected.


 


---


 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_979D933F1A7141C2877B344921DBC159ciscocom_-- From nobody Fri Jun 24 09:26:06 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BA312DC0A for ; Fri, 24 Jun 2016 09:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97IBzZUlCPXn for ; Fri, 24 Jun 2016 09:26:04 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCEE612DCD0 for ; Fri, 24 Jun 2016 09:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=432; q=dns/txt; s=iport; t=1466785067; x=1467994667; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=QERDiOpTQpm9XttLfwvE0C4XRtRuO3F3avoXj0fjUpw=; b=b0/F7+p8Ah3urJWfZdLZ9TzI6I/dhU479pin47jd30cr3tpE32ooIbx6 dAjjtBUcwH4jmVQTqGP7MO+ELaSq3voFtxmOEgVHmaYmhELWBbZT1aMJX Fn4zKlmWsdia0NVlb5g15+Ac0hPKYhwgjq4XXG+Ptxa/5NkGq6euT8q6M A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgBdXG1X/4sNJK1cgz5WfQa6IYF7G?= =?us-ascii?q?oYcgRc4FAEBAQEBAQFlJ4RTIxFXASICJgIEMBUSBIhDpnGPYpA2AQEBBwEBAQE?= =?us-ascii?q?BIoEBkTWCWgWZAAGGB4gsgVMBFU6EBYhnj30BHjaDcG6IMX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,521,1459814400"; d="scan'208";a="116544976" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jun 2016 16:17:46 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u5OGHkR0019829 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 24 Jun 2016 16:17:46 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 24 Jun 2016 12:17:45 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 24 Jun 2016 12:17:45 -0400 From: "Acee Lindem (acee)" To: IDR List Thread-Topic: Interim Meeting on Monday? Thread-Index: AQHRzjPxBgWjQm8j7kGHYI28jrcZ1g== Date: Fri, 24 Jun 2016 16:17:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.200] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Idr] Interim Meeting on Monday? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:26:05 -0000 SGkgU3VlLCBKb2huLCANCg0KSSBoYXZlIGEgY2FsZW5kYXIgcGxhY2UtaG9sZGVyIGF0IDEwIEFN IEVEVCBvbiBNb25kYXkgZm9yIGFuIElEUiBpbnRlcmltLg0KSXMgdGhlcmUgYSBtZWV0aW5nIGFu ZCwgaWYgc28sIGNhbiB5b3UgcGxlYXNlIHJlc2VuZCB0aGUgbGluayB0byB0aGUgV2ViRXgNCmFu ZCBhZ2VuZGE/IEkga25vdyBJIHByb2JhYmx5IGNvdWxkIGhhdmUgZm91bmQgdGhlIGluZm8gb24g aWV0Zi5vcmcgYnV0DQpmaWd1cmVkIHRoZSBxdWVzdGlvbiB3YXMgb2YgZ2VuZXJhdGlvbiBXRyBp bnRlcmVzdC4NCg0KVGhhbmtzLA0KQWNlZSANCg0K From nobody Fri Jun 24 09:27:50 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514EE12DCB1; Fri, 24 Jun 2016 09:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5_2nGba4Mhi; Fri, 24 Jun 2016 09:27:40 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA9612DE0E; Fri, 24 Jun 2016 09:21:15 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5OGKoAD039604 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2016 17:20:51 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <576D5DE1.8030103@foobar.org> Date: Fri, 24 Jun 2016 17:20:49 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Benoit Claise References: <20160615150104.20296.66089.idtracker@ietfa.amsl.com> In-Reply-To: <20160615150104.20296.66089.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, The IESG , shares@ndzh.com, draft-ietf-idr-ix-bgp-route-server@ietf.org Subject: Re: [Idr] Benoit Claise's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:27:42 -0000 Benoit Claise wrote: > I thought it was clear to me until I saw figure 1: The dotted line is the > IXP or the IXP Route Server? > At first glance, I thought that it was the IXP and that AS1 was connected > to the IXP Route Server while still having a bilateral connection with > AS4. > I hope now that the dotted line is the IXP Route Server, otherwise I've > confused. The lines represent interconnection arrangements, whether multilateral or bilateral. I've updated the draft to reflect this. Nick From nobody Fri Jun 24 09:31:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000E212DC1D; Fri, 24 Jun 2016 09:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4JX-Tl2Poar; Fri, 24 Jun 2016 09:31:23 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D89912DC84; Fri, 24 Jun 2016 09:26:38 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5OGQUUq039787 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2016 17:26:30 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <576D5F35.4040500@foobar.org> Date: Fri, 24 Jun 2016 17:26:29 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Benoit Claise References: <20160615150104.20296.66089.idtracker@ietfa.amsl.com> <2bdc68fc-2c4c-ac3f-a970-0a12c3cb1778@cisco.com> In-Reply-To: <2bdc68fc-2c4c-ac3f-a970-0a12c3cb1778@cisco.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr wg , Robert Raszuk , "idr-chairs@ietf.org" , The IESG , Susan Hares , "draft-ietf-idr-ix-bgp-route-server@ietf.org" Subject: Re: [Idr] Benoit Claise's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:31:25 -0000 Benoit Claise wrote: > Yes, and a sentence stressing that mlpe and blp sessions are not > inconsistent in an IXP would be useful IMO. Good suggestion, but this draft is about the changes required for the BGP protocol. This is more appropriate to draft-ietf-grow-ix-bgp-route-server-operations, section 3. I've made a note to add it in there. Nick From nobody Fri Jun 24 09:54:31 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A459712D0FD for ; Fri, 24 Jun 2016 09:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Gu6dM7JDvAN for ; Fri, 24 Jun 2016 09:54:28 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8639B12D0F9 for ; Fri, 24 Jun 2016 09:54:28 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5OGsPYR040525 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2016 17:54:26 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be crumpet.local Message-ID: <576D65C0.8080108@foobar.org> Date: Fri, 24 Jun 2016 17:54:24 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Michael H Lambert References: <0F2F74E2-B3CB-4447-9C7C-028F47E6490F@psc.edu> In-Reply-To: <0F2F74E2-B3CB-4447-9C7C-028F47E6490F@psc.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-ix-bgp-route-server-11 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:54:30 -0000 Michael H Lambert wrote: > This may have been discussed before and I just couldn't find it in > the archives, and it may be too late in the process to ask the > question, but should RFC 7606 (Revised Error Handling for BGP) apply > to peering sessions with route server clients? It does run counter > to attribute transparency, but it can help insure that the "right" > session is reset and that known (or knowable) bad announcements are > properly propagated. My reading is that the draft-ietf-idr-ix-bgp-route-server is ok on this. The relevant sections in RFC7606 are 7.2 to 7.4, inclusive. 7.3 and 7.4 only make line-protocol statements on what should be considered malformed. Section 7.2 states: > [RFC4271] also says that an implementation optionally "MAY check > whether the leftmost ... AS in the AS_PATH attribute is equal to the > autonomous system number of the peer that sent the message". I.e. it makes no statement one way or another on what should be done where the leftmost as != peeras. draft-ietf-idr-ix-bgp-route-server doesn't contradict this. Nick From nobody Fri Jun 24 11:43:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42ABA12D532; Fri, 24 Jun 2016 11:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNwuUYOSCoJG; Fri, 24 Jun 2016 11:43:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFA012D508; Fri, 24 Jun 2016 11:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9efriXHCgN6bQ/8hJmstJc/ocSpbIGUK4P3rM1S541Y=; b=Wm5CAPwjOLz7PT9xzLCmF5mJPL9Kvhn6HORXhC3OFMqpMzhrfDizwxpBU6rjQmMrHZnorwf0XP4FvZHSMm6q/AwwZZVj9epYdvI1tmGxWqW1UGHKV7TLsCTb7KCDXyJM7xEiwP6izIPFr/qhZhnIPgQpAocOe5dBkY2AASzVsr8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from praio-sslvpn-nc.jnpr.net (66.129.241.11) by BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) with Microsoft SMTP Server (TLS) id 15.1.517.8; Fri, 24 Jun 2016 18:43:32 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Fri, 24 Jun 2016 14:43:26 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> References: To: "Bocci, Matthew (Nokia - GB)" , X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: SN1PR10CA0051.namprd10.prod.outlook.com (10.164.10.147) To BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) X-MS-Office365-Filtering-Correlation-Id: ded6a771-7e75-42b1-ff64-08d39c5f7216 X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 2:isjBf4sMQUWmbckeRcVhEZr/vXQv4uJz0c1VCMAOfT2a1INCdO0nvgF69AxoZju7czTeAu6/HWd5ArqEn+R++gchOXTPtifhDH9C67sLfgE5xyJSRWAs+ZR033CFVeGeReg3sr560/d7YjEXz17VnaoxJHB9bKV3K/uQp2lznY57PImBsCrGqZYC8gW1sFLO; 3:D3HnA68va71McRo6F6l2tQ4dmbtdsWZStJs16GX0Qp3rtc+bhPTswgSdrbGge9cIPtwRqtZGOAJGeMyL3bWC5hHOwgwSpY0t7WIs0Ygm791Y1KxsDgdLSYJUx6t0xjJc; 25:vrFzHFT4/8OIZu2pKhKuWm+k1VJZMzq+kDf+3ZYBvcKcFVL10/UKuTXYVuh4p4KChvZBi/nMdzBJ153OpMITSzfAJheNUHB/DwtVULMGn039KCNYFIJDlKMG0ct24JISLoOI4yR1hqw6Y0aXDL9G0XMhMgv1uoWtkK1+cNsMKiPtG7vdIJWtX7ghCOZnuwEAiyR+X3tp/0Jp7cyxLcN66jsaeHZscb3LBc66fSHhQMqcAs9afGVvOX1V0xjX5jY1ydhPTEMcxwKnWp3126iVPYyPkxUJ1EGe6OD7zflELNcxadxFVb6i/LyXB7R8dnZy3QT2QN6miaU30hSEflUQ+3SB6dj5weRpV+wy6v+jCI3VjLV2be6vwy/WTsvMdKS0P2LtEfYcxNTByq29EyCFyqmoh3DIsXioJrsHMw27+/A= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2500; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 20:tU8AX0OLzXNG0X6TpDxYjRoxHvr8yM7Z5AnnOPKginrqGN6qmrTVbRwxdtx2yQlFSdyA32W9RPupL0iq1wAkPijjAgHS6v18R+Xxy2d/dTOrduzP3sKNuwcu0W1k0Eml2Jb4pjoQWDJI9By3iSCEOajlzPRuXcTiLYCl1JyynjW+QUX+rTUL4F9wMuUI/EtR0mRKuy1X4PNhjkueR9xnlSPey6tRvcLLNKfXA+CEJajehZvDc5iEQb+QPNVcjcXaL18nNxXH09YOd8wjPM8XHYTGjVpphRzZAlC7/xqJGnDCHP4t7q0fCg+OOXgePdO92pXbM+dodX/sJsdqcCEWM5XmtHikNP0j/pTF2YHtk+9w+/EHUYZO4A8LfN+3EHKm56n0dO56DgrVuznCwydUMO4ZWO8k0TPyCW3TUOhNK6vJ04Kgxw6tSsti0DIOsp/MaIY2MgtkPr3W3z71KLeORcqpW3yu+xMF27IvVhzrq+PD7Ym8kGVS3tZMGZj0c+5j X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(138986009662008)(82608151540597); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN3PR05MB2500; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2500; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 4:8CY2Srk6ykeYc6SSEWjcXd40XdnioKDA1eUUrIh7j1Zx4WVK/3fvsRBwMTePF2aP8BmyjUIv7uSPnfnD5632XDTvvILK9IVazEoV5qMNZge3oFS/nL/zfudnP2mrTr8END6IoufcRC9N/rc/LVhX1/o/9VF2Y4AU9LVnjqsDRHLdJEkdAfuThgxsXL1WgWSgpRmc6alxcxz17Tf4v/DExxAEiepGj+G2LnEUOXOoHePb6FR3+P6V0jE3A2EwiK4xLJorfwf5zCq3jgr+oIK+f7czq1UQbh2hFFfANw2FhpC2olkwH4a9LI9McgazA4Fpbh8nRuo96YeZgEg3AksettjzNZGxn6DCiRQBSSTtWcadVARXAAKzav1Qq4rSofhqoODrreqSaaD8fcgmgO0P+v3ALEwxlAu5DaMUoK13xvMLMKkJywKSe4AQ16Ri/loeUR5cTWZ6tml+eH9MTBwtrxUQKDrFCM0hxm9HVKHgz62vYS4moeSHcfLXeSp8WaK0 X-Forefront-PRVS: 0983EAD6B2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(189002)(377454003)(51914003)(42186005)(5001770100001)(6116002)(3846002)(2906002)(66066001)(77096005)(4326007)(586003)(7846002)(2950100001)(82746002)(53416004)(47776003)(92566002)(561944003)(7736002)(97736004)(305945005)(50226002)(8746002)(36756003)(57306001)(23726003)(33656002)(50986999)(83716003)(106356001)(19580405001)(101416001)(50466002)(68736007)(189998001)(230783001)(46406003)(105586002)(19580395003)(81166006)(69596002)(86362001)(97756001)(81156014)(76176999)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2500; H:praio-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2500; 23:4JCSCDwRGLNYsUYNJg2y7Qq2C6nuZ5jp89UC2YHZI?= =?us-ascii?Q?OxYvp5kSdA41RxxOeq5GaC3W0WLhmRpP5KWEQNhxbeXB94KK2vi8/OStxPri?= =?us-ascii?Q?jI6x9A/m+s8pNltCJebNtvLaPxRwAR4qCnCHezqRgOq46cWWSXgj0EbzTuiz?= =?us-ascii?Q?LgCn2yHmbrN/rYe8VXlEqp1tvltGQFQ03nPvHQFUwqUsMFUUbDpKdqPetGfN?= =?us-ascii?Q?w+630Rk53jHr3vygQrihqBuVzXGp6mK1fSXCwclbcW8vOGovsLmPPfZ752Tr?= =?us-ascii?Q?CdnwpZLmFeu6z1OXsTc//PIFvW+bqyNla4KZrSMzk4Y99ugiyGOYYMFHrpL3?= =?us-ascii?Q?Nfu1luajSCemqNA9jiLBms7NyDffzB/s/Q5jAnE8pyOcS1RfhNus/z5xKtmF?= =?us-ascii?Q?ZeMwYTOHvyOy+Aq2OS5/E0dPGHDPSWD6h6wmquHzLXFzj9bq3wwUV/LOJRVX?= =?us-ascii?Q?24Z4URwrO+LyZ55HC3zb0Y3m6KHaQbSVlDzdMOiCwXMkoTWUJcB5j6Bf1CJd?= =?us-ascii?Q?VVQcErTSWP3CePlJQTqWf0SYcJ/y9dpfIXsRdNW8O7HvETX1zHfT0WoP6WfO?= =?us-ascii?Q?o00UB8jqprhDlXS2tcHnKsQTbvphGUqKY4PZ9MCTm+jLYf3dyMo4r+mu4C7D?= =?us-ascii?Q?OnCbmEZlHnuf/XvRr1EKnzB2ddtoujeNYzJ/PP/xYri4+63mjTNFMn+bEQFJ?= =?us-ascii?Q?PMv90N390V5AIVFEE7M9w41XojkBwYHQ3LNRRLjrz63wGap4XvQ1GRR+VpOQ?= =?us-ascii?Q?1hE/BPlusTXWMqo3tgMzcGRiY63Ht/1hG43nXQVIxF5cTy8R5RhMVG9RBrZs?= =?us-ascii?Q?5X/A1mHAwAKluZFEiOCLJG+9HVKEhAZdYcKgaQq/c7RvDCZ1pV97Ajp/1kEJ?= =?us-ascii?Q?GVVQjXlz3tf1B7p65+lyBcM8GnXLur5oo2aehYDeDJ+qPdsj0VIZNrL077l0?= =?us-ascii?Q?9uE5z1V4idEzhllXkCbRITFEIGoH9BjQva/r4Lj3l8Tu1GKk0GETUMR+1EH4?= =?us-ascii?Q?YaMxyRl/un8gGGBDKyfxue0o4oiodZOYQnnUsucy7ut5Vv5ctmHOLl/XYC8V?= =?us-ascii?Q?ItOu2ylDGMVFruGkStDpJJLVktD3vlR/v4nxpkzrZ6q7Ev0+xEJh8Qsh9n2H?= =?us-ascii?Q?XEN9o0ZUM8mCHhs0KX1pNNYFX7Myg//HpOeOLAWaONMcVtUXEEYrYO9Uqyfz?= =?us-ascii?Q?YNrnfpq+8j4wyFjKXDskvJ7teormQzRG5Jp0OGybR373W4UVknbaDQuOzCqz?= =?us-ascii?Q?PhNSLncSKzc6No9hXqBHvKJ5q0Lw3a8qwLCnkZ5rIgpLbbg8bTTu/hur8ywb?= =?us-ascii?B?Zz09?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 6:v99sqDzKAKGtixPbLkPmLBrQ8ag7J9qzxjcYV7yNGaf6m3web8bljhAtrltyaUBshgRDiTNcjCy1IO3fofqkP88iRbCmQq+SJdCDbqUZlg0rhXzDGgWxJTwkVK3vbh/vXa1UiyiKgjmVRvtp6ZqWmaGCCm5vFWtN+HN55xmGnvU/Mbw9UHrZK/GJml8gKwd/hX37WyPqOvQtF+zhejaVxgzAShzwa6b5+8ZnVSiBG1KMtR1Nz+yfdPuIHv1QQnYz/lDiDn40rYP0eN5idd3KWsrt7XFLouNoFXqaVIgTjaJsa44STwbDSd9Yqifu9QGcpVq4oy3PbPv1qlp6cx4xr7cyMwllLdPOIfw1SmYnY2w=; 5:FdxK4tRhti0kRT4WPO6aQFiaC0AYJmrKq4CWE1EGeSarGmJVBHmhIMbQfOQVBwFzx6YXbz5aasXBNpJvbUujuxEFHnGFZGBzwvEvYuZcznYvy76skJCeObN1OePOQ9fl6vS3KSmPKjjUPkKI44dtog==; 24:knqnH7X/syKd8iuly9bodiYTwArBr6tsL7fQ+a4Y5e7ZoXQamk2n5W7bNpJ/XgC4I0XUUVu1bYjsrQlJGlIKRGVLCDHxbUvVnu0NvQ0EYUM=; 7:1hYKIuvf3KudtKjq4Axj7xxHQgMyZZ39mmqbpvA3pcTey5KTyIthe2CAnyoBYB+LIFnVUB8gCBNZmP0X6mA8TcXofKs/Gw7ueusbYjZQRmPz49IrG5crwaeAyQsAevyUszgeeeWNVrKuR5nRoM6qRvL3pUxDMWHvQw94+4VLAlDqv2E5lDCDCr1JItoob2l1aVfAYQOE17r95ZLdvtizdip+tBDHZzXydi3lRAxmJQnbokVd9dXpX/zjd7waHtBc SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2016 18:43:32.8969 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2500 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-ext-opt-param@ietf.org" , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 18:43:37 -0000 Hi Matthew and all, Thanks for the review. Some comments below. > From: "Bocci, Matthew (Nokia - GB)" > Date: 6/21/2016 6:10 AM (GMT-05:00) > To: idr@ietf.org, Susan Hares , jgs@juniper.net, = rtg-dir@ietf.org, draft-ietf-idr-ext-opt-param@ietf.org > Subject: [Idr] Routing directorate QA review of = draft-ietf-idr-ext-opt-param-04 ... > Minor Issues: >=20 > =20 >=20 > 1) Section 2, Protocol Extensions. >=20 > You have labelled the existing Length and Type fields as 0xFF. I = assume the meaning of the second is still 'Type' since that is >=20 > what any implementation would reasonably interpret it as, and that is = the registry you are using a code point from. So it >=20 > might be better to say in the text above the figure at the top of page = 3 that the length and type fields in [RFC4271] >=20 > are set to 0xFF. Is your proposal to use the diagram verbatim from 4271, but say in the = prose that the type and length are 0xFF? I'm fine with whatever seems = clearer to folks. > Also, you don't explicitly define what a receiver should do with the = length field if the type is 0xFF. Does it ignore it, >=20 > or does it check that it is 0xFF and treat the OPEN message as = malformed if it is < 0xFF? This is a good question, and TBH I don't recall why we specified a value = for the legacy length field instead of simply saying it should be = ignored. Maybe Enke remembers? Right now I'm inclined to say it should be ignored = on receipt, but I'm open to discussion. I guess even if we make that = change we can still spec it be sent as 0xFF, for purposes of = debuggability, but this is not a big deal. > Since the document changes the procedures in RFC4271 for BGP Open = optional parameters where length > 255, in that the >=20 > original length field is no longer to be interpreted as the actual = length, then I think you should mark this draft as >=20 > 'Updates: 4271'. Good point, will fix. > 2) Section 5: Security Extensions >=20 > The security considerations section seems to be lacking detail and = amounts to one line: >=20 >=20 > "This extension to BGP does not change the underlying security = issues" >=20 >=20 > It might be worth being a little more explicit, or at least use = wording similar to RFC5492, and saying that it does not >=20 > add any new security issues that are not inherent in BGP [RFC4272].=20= Good point, will change. Thanks, --John From nobody Fri Jun 24 11:47:44 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9806D12D549 for ; Fri, 24 Jun 2016 11:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5X9Nv3FEP5Py for ; Fri, 24 Jun 2016 11:47:40 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506D912D537 for ; Fri, 24 Jun 2016 11:47:40 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5OIlbJR043643 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2016 19:47:37 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be cupcake.local Message-ID: <576D8048.1090706@foobar.org> Date: Fri, 24 Jun 2016 19:47:36 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Robert Raszuk References: <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> <20160620131112.GE2950@pfrc.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: idr wg Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 18:47:43 -0000 Robert Raszuk wrote: > ​To me the Route Server is a Route Reflector for EBGP sessions. It > really does not matter if you are messing with AS_PATH there or not. > What actually matters ​is that you do not set next hop to yourself there. yes, this is what makes a standard bgp speaker a route server. The core functionality is distributing prefixes on a shared broadcast domain, but without routing the actual traffic. Nick From nobody Fri Jun 24 12:41:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713D812D595 for ; Fri, 24 Jun 2016 12:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_jupTmZADWS for ; Fri, 24 Jun 2016 12:41:34 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5997412D59E for ; Fri, 24 Jun 2016 12:41:34 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5OJfU3g045128 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2016 20:41:31 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be cupcake.local Message-ID: <576D8CE9.8070305@foobar.org> Date: Fri, 24 Jun 2016 20:41:29 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Jeffrey Haas References: <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> <20160620131112.GE2950@pfrc.org> In-Reply-To: <20160620131112.GE2950@pfrc.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr wg , Mirja Kuehlewind Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:41:36 -0000 Jeffrey Haas wrote: > If the intent of the text in the current internet-draft is to leave wiggle > room for a device operating as a RS to also act as a standard BGP speaker > without RS functionality, I think that's unnecessary. the intent is to acknowledge that there are some bgp stacks which cannot handle leftmost as != peer as when acting as an rs client. Mostly these stacks are legacy, but there are still some bgp implementations which don't support this feature on the client side, even though the client side part is mandated further down the paragraph. If the SHOULD is changed to MUST, then the IXP operator will not be able to provide RS service to clients like this. This is not a helpful thing to do from a operational point of view. Nick From nobody Fri Jun 24 13:05:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BBD12D608 for ; Fri, 24 Jun 2016 13:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jGSDVn6pHM3 for ; Fri, 24 Jun 2016 13:05:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D05012D589 for ; Fri, 24 Jun 2016 13:05:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bGXLt-00080S-WD; Fri, 24 Jun 2016 20:05:22 +0000 Date: Fri, 24 Jun 2016 22:05:21 +0200 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <576D8CE9.8070305@foobar.org> References: <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> <20160620131112.GE2950@pfrc.org> <576D8CE9.8070305@foobar.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg , Mirja Kuehlewind Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 20:05:26 -0000 > the intent is to acknowledge that there are some bgp stacks which cannot > handle leftmost as != peer as when acting as an rs client. Mostly these > stacks are legacy, but there are still some bgp implementations which > don't support this feature on the client side, even though the client > side part is mandated further down the paragraph. > > If the SHOULD is changed to MUST, then the IXP operator will not be able > to provide RS service to clients like this. This is not a helpful thing > to do from a operational point of view. though i have little sympathy for folk who want to connect broken home appliances to exchanges, at least thie answers the AD's question. randy From nobody Fri Jun 24 14:16:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1093F12D603 for ; Fri, 24 Jun 2016 14:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga5E-xcz31pB for ; Fri, 24 Jun 2016 14:16:42 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774B9128B44 for ; Fri, 24 Jun 2016 14:16:42 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5OLGcxB047851 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2016 22:16:39 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be cupcake.local Message-ID: <576DA334.9090809@foobar.org> Date: Fri, 24 Jun 2016 22:16:36 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Mirja Kuehlewind (IETF)" References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <575FD94E.8030606@foobar.org> <575FF3B9.3080501@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr wg Subject: Re: [Idr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft-?= =?iso-8859-1?q?ietf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 21:16:45 -0000 Mirja Kuehlewind (IETF) wrote: > sorry for my late reply. Yes, that was not capturing my point. Please > provide some reasoning with the SHOULD is not a MUST. What are the > cases where you should not follow the SHOULD. Ok. I've changed the text to read: > 2.2.2.1. Route Server AS_PATH management > > As a route server does not participate in the process of forwarding > data between client routers, and because modification of the AS_PATH > attribute could affect route server client BGP Decision Process, the > route server SHOULD NOT prepend its own AS number to the AS_PATH > segment nor modify the AS_PATH segment in any other way. This differs > from the behaviour specified in section 5.1.2 of [RFC4271], which > requires that the BGP speaker prepends its own AS number as the last > element of the AS_PATH segment. This is a recommendation rather than > a requirement solely to facilitate legacy RS client implementations > which do not yet support the requirements specified in Section > 2.2.2.2. > > 2.2.2.2. Route Server client AS_PATH management > > In contrast to what is recommended in section 6.3 of [RFC4271], [...] This splits up 2.2.2 into two sub paragraphs and adds a sentence to the end of the first paragraph which refers to the second. Does this work for you, or would you prefer if -12 were posted before commenting? Nick From nobody Fri Jun 24 15:29:27 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17A112D69B; Fri, 24 Jun 2016 15:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_7BbOvDuRUB; Fri, 24 Jun 2016 15:29:20 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4AB112D142; Fri, 24 Jun 2016 15:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2524; q=dns/txt; s=iport; t=1466807359; x=1468016959; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ax0UzM/+MQmpzV/rJJA2oG9BNZOcU+DwCGztrz1DAYw=; b=PIvVS9FlI95hXteSv5OkOfs9HdevsNiIqFTiyiBUpXrvVuwn7YiE7+b9 dJrCqaXGwgozPOqG6GvdBrr080l0KW2VSAWpsjOOI5MG1cnfOTxJd+uT2 qgUuy2v5VTj50gfWBPGG5Oa+B0CU0lfrhY/i9HrK1c0dNqaWlWgJdLRrn 8=; X-IronPort-AV: E=Sophos;i="5.26,523,1459814400"; d="scan'208";a="288950790" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jun 2016 22:29:19 +0000 Received: from [10.41.57.187] ([10.41.57.187]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u5OMTIv6005948; Fri, 24 Jun 2016 22:29:18 GMT To: "John G. Scudder" References: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> From: Enke Chen Message-ID: Date: Fri, 24 Jun 2016 15:29:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "idr@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-idr-ext-opt-param@ietf.org" , "Bocci, Matthew \(Nokia - GB\)" , Susan Hares Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 22:29:22 -0000 Hi, John: Please see below. On 6/24/16 11:43 AM, John G. Scudder wrote: > Hi Matthew and all, > > Thanks for the review. Some comments below. > >> From: "Bocci, Matthew (Nokia - GB)" >> Date: 6/21/2016 6:10 AM (GMT-05:00) >> To: idr@ietf.org, Susan Hares , jgs@juniper.net, rtg-dir@ietf.org, draft-ietf-idr-ext-opt-param@ietf.org >> Subject: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 > ... > >> Minor Issues: >> >> >> >> 1) Section 2, Protocol Extensions. >> >> You have labelled the existing Length and Type fields as 0xFF. I assume the meaning of the second is still 'Type' since that is >> >> what any implementation would reasonably interpret it as, and that is the registry you are using a code point from. So it >> >> might be better to say in the text above the figure at the top of page 3 that the length and type fields in [RFC4271] >> >> are set to 0xFF. > > Is your proposal to use the diagram verbatim from 4271, but say in the prose that the type and length are 0xFF? I'm fine with whatever seems clearer to folks. > >> Also, you don't explicitly define what a receiver should do with the length field if the type is 0xFF. Does it ignore it, >> >> or does it check that it is 0xFF and treat the OPEN message as malformed if it is < 0xFF? > > This is a good question, and TBH I don't recall why we specified a value for the legacy length field instead of simply saying it should be ignored. > Maybe Enke remembers? Right now I'm inclined to say it should be ignored on receipt, but I'm open to discussion. I guess even if we make that change we can still spec it be sent as 0xFF, for purposes of debuggability, but this is not a big deal. > Here is what RFC 4271 says about the "Optional Parameters Length": This 1-octet unsigned integer indicates the total length of the Optional Parameters field in octets. If the value of this field is zero, no Optional Parameters are present. If the "Optional Parameters Length" field is 0, then the Optional Parameters will not be parsed and thus the new length field would not be reached. I am not sure, but that might be the reason that we have it as 0xFF. It needs to be at least 1 for the "Parm. Type" field to be parsed. Once the "Parm. type" is parsed, and if its value is 0xFF, then the two-octet length field follows. The procedure is more than just "ignoring" the field. Thanks. -- Enke From nobody Fri Jun 24 15:41:42 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A90412D5DB for ; Fri, 24 Jun 2016 15:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p20NNP3ZaPUp for ; Fri, 24 Jun 2016 15:41:39 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C3C12D1A2 for ; Fri, 24 Jun 2016 15:41:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.195.80; From: "Susan Hares" To: Date: Fri, 24 Jun 2016 18:41:11 -0400 Message-ID: <00b701d1ce69$81cfc420$856f4c60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B8_01D1CE47.FABF5CA0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdHOYSF3ZhCFZzU7S7W0PEKGuYKTYw== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Interim on 6/27/2016 is cancelled X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 22:41:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B8_01D1CE47.FABF5CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit HI all: The IDR interim on 6/27/2016 is cancelled. There were two topics for this interim: 1) Ordering rules for the BGP Flow Specification Actions 2) BGP Flow Specification version 2. Since, the WG Chairs did not get the presentations and documents in a timely fashion, the IDR interims is cancelled. However, the ordering rules are needed by authors of BGP Flow Specification v1 (RFC5575bis) actions. To provide aid for these authors, I have recorded a presentation based on work from Robert Raszuk and Sue Hares. The presentation and the recording is indicated in the proceedings for the 6/27/2016 interim. In addition, there is presentation for authors of BGP wishing to specify filters or actions for BGP Flow Specification version 2. This presentation comes from draft-hares-idr-flowspec-v2. Full details are below, and (hopefully) the presentations will be available at https://www.ietf.org/proceedings/interim/2016/06/27/idr/proceedings.html (soon). [The web page seems to be broken now]. See you at IETF 96. Susan Hares and John Scudder Interim Notes: The Interim topics were: Revisions to RFC5575bis and BGP Flow Specification v2. The interim is cancelled, but the presentations are online. These instructinos may be useful for authors finalizing drafts for IDR session at IETF 96. Topic: Revisions to RFC5575bis Filter ordering: if filter type is present, order is strict numerical ascending order. If the filter type is not present, it can be skipped. 3 rules for Filter actions: 1) All redirect actions are mutually exclusive. The presence of more than redirect one results in no redirect. 2) If multiple rate actions are present, these are applied in ascending order of the sub-type. (byte rate (0x06), and then packet rate (TBD)). 3) Some actions are unique, and may operate independently. (E.g. MPLS push/pop) Authors of Actions drafts should specify: 1) whether it is a redirect or rate action 2) whether the action is unique or if it interferes with other actions, 3) If the action interferes with other actions, the handling must be specified if both (action and interfering action) are associated with a Flow specification 4) If the interference between two actions causes an BGP error conditions, the method of handling the error conditions based on RFC7606. Recording: Created: 6/24/16 6:10 pm File size: 3.49MB Duration: 4 minutes Duration:3 minutes Description: Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=0d743aea6253a67c0289f59468a3aa6e Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=f52d352a10020a94e567fca74897e03a Topic 2: BGP Flow Specification 2 Presentation gives summary of BGP Flow Specification v2. Proposals for filters or actions that for BGP v2 will be accepted at IETF 96. Recording: Topic: IDR Working Group's Personal Room-20160624 2219-1 Create time: 6/24/16 6:26 pm File size: 5.01MB Duration: 5 minutes Description: Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=07b432ea5ece6ba07871a03781c2a899 Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=07e587c749aab51669f03fee7988e0b6 ------=_NextPart_000_00B8_01D1CE47.FABF5CA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI all: =

 

The IDR interim on 6/27/2016 is cancelled.   = There were two topics for this interim:

 

1)      = Ordering rules for the BGP Flow Specification = Actions

2)      = BGP Flow Specification version 2. =

 

 

Since, the = WG Chairs did not get the presentations and documents in a timely = fashion, the IDR interims is cancelled.

 

However, the = ordering rules are needed by authors of BGP Flow Specification v1 = (RFC5575bis) actions.  To provide aid for these authors, I have = recorded a presentation based on work from Robert Raszuk and Sue Hares. =  The presentation and the recording is indicated in the proceedings = for the 6/27/2016 interim.  In addition, there is presentation for = authors of BGP wishing to specify filters or actions for BGP Flow = Specification version 2.  This presentation comes from = draft-hares-idr-flowspec-v2.

 

Full details = are below, and (hopefully) the presentations will be available at https://www.ietf.org/proceedings/interim/2016/06/27/idr/proceedi= ngs.html (soon).  [The web page seems to be broken = now].

 

See you at IETF 96.

 

Susan Hares = and John Scudder

 

 

Interim = Notes:

 

The Interim topics were: Revisions to RFC5575bis and =

BGP Flow Specification v2. =

 

The interim is cancelled, but the presentations =

are online.  These instructinos = may be useful for

authors finalizing = drafts for IDR session at IETF 96.

 

 

Topic: = Revisions to RFC5575bis

 

   = Filter ordering: if filter type is present,

   order is strict numerical ascending = order.

   If the = filter type is not present, it can be

   skipped.

   

   3 rules for Filter actions:  =

    1) All = redirect actions are mutually exclusive.

         &= nbsp;      The presence of more than redirect = one results in no redirect.

         &= nbsp;     

    2) If multiple rate actions are = present,

         &= nbsp;       these are applied in ascending = order of the sub-type.

     (byte rate (0x06), and then = packet rate (TBD)).

 

    3) Some actions are unique, and may = operate independently.

         &= nbsp;     

         &= nbsp;      (E.g. MPLS push/pop)  =

 

         &= nbsp;      Authors of Actions drafts should = specify:

         &= nbsp;      1) whether it is a redirect or rate = action

         &= nbsp;      2) whether the action is unique or = if it interferes with other actions,

         &= nbsp;      3) If the action interferes with = other actions, 

         &= nbsp;      the handling must be specified if = both (action and interfering action)

         &= nbsp;      are associated with a Flow = specification

 

    4) If the interference between two = actions causes an BGP error conditions,

         &= nbsp;      the method of handling the error = conditions based on RFC7606.

         &= nbsp;     

 

Recording: =

Created: 6/24/16 6:10 pm File size: = 3.49MB

Duration: 4 = minutes

Duration:3 = minutes

Description:

Streaming recording link:

https://ietf.webex.com/ietf/ldr.php?RCID=3D0d743aea6253= a67c0289f59468a3aa6e

Download = recording link:

https://ietf.webex.com/ietf/lsr.php?RCID=3Df52d352a1002= 0a94e567fca74897e03a

 

Topic 2: BGP = Flow Specification 2

 

   = Presentation gives summary of BGP Flow Specification v2. =

   

   Proposals for filters or actions = that

   for BGP v2 = will be accepted at IETF 96.

  

Recording:

Topic: = IDR Working Group's Personal Room-20160624 2219-1

Create time: 6/24/16 6:26 pm  File size: = 5.01MB

Duration: 5 = minutes

Description:

Streaming recording link:

https://ietf.webex.com/ietf/ldr.php?RCID=3D07b432ea5ece= 6ba07871a03781c2a899

Download = recording link:

https://ietf.webex.com/ietf/lsr.php?RCID=3D07e587c749aa= b51669f03fee7988e0b6

------=_NextPart_000_00B8_01D1CE47.FABF5CA0-- From nobody Sat Jun 25 02:30:02 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C51212D190 for ; Sat, 25 Jun 2016 02:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWajQwvC4gWC for ; Sat, 25 Jun 2016 02:29:57 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC4812D13F for ; Sat, 25 Jun 2016 02:29:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.195.80; From: "Susan Hares" To: References: <00b701d1ce69$81cfc420$856f4c60$@ndzh.com> In-Reply-To: <00b701d1ce69$81cfc420$856f4c60$@ndzh.com> Date: Sat, 25 Jun 2016 05:29:26 -0400 Message-ID: <0da401d1cec4$116ea1f0$344be5d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0DA5_01D1CEA2.8A6120A0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKigU88vcKswupI19NgPuCX0nkKdZ5YhTkg X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Interim on 6/27/2016 is cancelled X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 09:30:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0DA5_01D1CEA2.8A6120A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Slides can be accessed at: https://www.ietf.org/proceedings/interim-2016-idr-06/slides/slides-interim-2 016-idr-06-2.pdf https://www.ietf.org/proceedings/interim-2016-idr-06/slides/slides-interim-2 016-idr-06-4.pdf Sue Hares From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, June 24, 2016 6:41 PM To: idr@ietf.org Subject: [Idr] Interim on 6/27/2016 is cancelled HI all: The IDR interim on 6/27/2016 is cancelled. There were two topics for this interim: 1) Ordering rules for the BGP Flow Specification Actions 2) BGP Flow Specification version 2. Since, the WG Chairs did not get the presentations and documents in a timely fashion, the IDR interims is cancelled. However, the ordering rules are needed by authors of BGP Flow Specification v1 (RFC5575bis) actions. To provide aid for these authors, I have recorded a presentation based on work from Robert Raszuk and Sue Hares. The presentation and the recording is indicated in the proceedings for the 6/27/2016 interim. In addition, there is presentation for authors of BGP wishing to specify filters or actions for BGP Flow Specification version 2. This presentation comes from draft-hares-idr-flowspec-v2. Full details are below, and (hopefully) the presentations will be available at https://www.ietf.org/proceedings/interim/2016/06/27/idr/proceedings.html (soon). [The web page seems to be broken now]. See you at IETF 96. Susan Hares and John Scudder Interim Notes: The Interim topics were: Revisions to RFC5575bis and BGP Flow Specification v2. The interim is cancelled, but the presentations are online. These instructinos may be useful for authors finalizing drafts for IDR session at IETF 96. Topic: Revisions to RFC5575bis Filter ordering: if filter type is present, order is strict numerical ascending order. If the filter type is not present, it can be skipped. 3 rules for Filter actions: 1) All redirect actions are mutually exclusive. The presence of more than redirect one results in no redirect. 2) If multiple rate actions are present, these are applied in ascending order of the sub-type. (byte rate (0x06), and then packet rate (TBD)). 3) Some actions are unique, and may operate independently. (E.g. MPLS push/pop) Authors of Actions drafts should specify: 1) whether it is a redirect or rate action 2) whether the action is unique or if it interferes with other actions, 3) If the action interferes with other actions, the handling must be specified if both (action and interfering action) are associated with a Flow specification 4) If the interference between two actions causes an BGP error conditions, the method of handling the error conditions based on RFC7606. Recording: Created: 6/24/16 6:10 pm File size: 3.49MB Duration: 4 minutes Duration:3 minutes Description: Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=0d743aea6253a67c0289f59468a3aa6e Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=f52d352a10020a94e567fca74897e03a Topic 2: BGP Flow Specification 2 Presentation gives summary of BGP Flow Specification v2. Proposals for filters or actions that for BGP v2 will be accepted at IETF 96. Recording: Topic: IDR Working Group's Personal Room-20160624 2219-1 Create time: 6/24/16 6:26 pm File size: 5.01MB Duration: 5 minutes Description: Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=07b432ea5ece6ba07871a03781c2a899 Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=07e587c749aab51669f03fee7988e0b6 ------=_NextPart_000_0DA5_01D1CEA2.8A6120A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Slides can be accessed at: =

 

https://www.ietf.org/proceedings/interim-201= 6-idr-06/slides/slides-interim-2016-idr-06-2.pdf

 

https://www.ietf.org/proceedings/interim-201= 6-idr-06/slides/slides-interim-2016-idr-06-4.pdf

 

Sue Hares =

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Friday, June 24, 2016 6:41 PM
To: = idr@ietf.org
Subject: [Idr] Interim on 6/27/2016 is = cancelled

 

HI all: =

 

The IDR interim on 6/27/2016 is cancelled.   = There were two topics for this interim:

 

1)      = Ordering rules for the BGP Flow Specification = Actions

2)      = BGP Flow Specification version 2. =

 

 

Since, the = WG Chairs did not get the presentations and documents in a timely = fashion, the IDR interims is cancelled.

 

However, the = ordering rules are needed by authors of BGP Flow Specification v1 = (RFC5575bis) actions.  To provide aid for these authors, I have = recorded a presentation based on work from Robert Raszuk and Sue Hares. =  The presentation and the recording is indicated in the proceedings = for the 6/27/2016 interim.  In addition, there is presentation for = authors of BGP wishing to specify filters or actions for BGP Flow = Specification version 2.  This presentation comes from = draft-hares-idr-flowspec-v2.

 

Full details = are below, and (hopefully) the presentations will be available at https://www.ietf.org/proceedings/interim/2016/06/27/idr/proceedi= ngs.html (soon).  [The web page seems to be broken = now].

 

See you at IETF 96.

 

Susan Hares = and John Scudder

 

 

Interim = Notes:

 

The Interim topics were: Revisions to RFC5575bis and =

BGP Flow Specification v2. =

 

The interim is cancelled, but the presentations =

are online.  These instructinos = may be useful for

authors finalizing = drafts for IDR session at IETF 96.

 

 

Topic: = Revisions to RFC5575bis

 

   = Filter ordering: if filter type is present,

   order is strict numerical ascending = order.

   If the = filter type is not present, it can be

   skipped.

   

   3 rules for Filter actions:  =

    1) All = redirect actions are mutually exclusive.

         &= nbsp;      The presence of more than redirect = one results in no redirect.

         &= nbsp;     

    2) If multiple rate actions are = present,

         &= nbsp;       these are applied in ascending = order of the sub-type.

     (byte rate (0x06), and then = packet rate (TBD)).

 

    3) Some actions are unique, and may = operate independently.

         &= nbsp;     

         &= nbsp;      (E.g. MPLS push/pop)  =

 

         &= nbsp;      Authors of Actions drafts should = specify:

         &= nbsp;      1) whether it is a redirect or rate = action

         &= nbsp;      2) whether the action is unique or = if it interferes with other actions,

         &= nbsp;      3) If the action interferes with = other actions, 

         &= nbsp;      the handling must be specified if = both (action and interfering action)

         &= nbsp;      are associated with a Flow = specification

 

    4) If the interference between two = actions causes an BGP error conditions,

         &= nbsp;      the method of handling the error = conditions based on RFC7606.

         &= nbsp;     

 

Recording: =

Created: 6/24/16 6:10 pm File size: = 3.49MB

Duration: 4 = minutes

Duration:3 = minutes

Description:

Streaming recording link:

https://ietf.webex.com/ietf/ldr.php?RCID=3D0d743aea6253a67c02= 89f59468a3aa6e

Download recording = link:

https://ietf.webex.com/ietf/lsr.php?RCID=3Df52d352a10020a94e5= 67fca74897e03a

 

Topic 2: BGP = Flow Specification 2

 

   = Presentation gives summary of BGP Flow Specification v2. =

   

   Proposals for filters or actions = that

   for BGP v2 = will be accepted at IETF 96.

  

Recording:

Topic: = IDR Working Group's Personal Room-20160624 2219-1

Create time: 6/24/16 6:26 pm  File size: = 5.01MB

Duration: 5 = minutes

Description:

Streaming recording link:

https://ietf.webex.com/ietf/ldr.php?RCID=3D07b432ea5ece6ba078= 71a03781c2a899

Download recording = link:

https://ietf.webex.com/ietf/lsr.php?RCID=3D07e587c749aab51669= f03fee7988e0b6

------=_NextPart_000_0DA5_01D1CEA2.8A6120A0-- From nobody Sat Jun 25 04:02:12 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1532812D62F for ; Sat, 25 Jun 2016 04:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYcRR38zegln for ; Sat, 25 Jun 2016 04:02:09 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A00E12D612 for ; Sat, 25 Jun 2016 04:02:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.195.80; From: "Susan Hares" To: References: <20160625100909.17188.81775.idtracker@ietfa.amsl.com> In-Reply-To: <20160625100909.17188.81775.idtracker@ietfa.amsl.com> Date: Sat, 25 Jun 2016 07:01:37 -0400 Message-ID: <11d101d1ced0$f20183c0$d6048b40$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQFbheIaS2XN0fsZUywovWE3CFyRhaDmleYg X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'John G. Scudder'" Subject: [Idr] FW: New Version Notification for draft-hares-idr-flowspec-v2-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 11:02:10 -0000 This is a short write-up on the Flow Specification version 2. I = welcome any feedback on this work.=20 Sue=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Saturday, June 25, 2016 6:09 AM To: Susan Hares Subject: New Version Notification for draft-hares-idr-flowspec-v2-00.txt A new version of I-D, draft-hares-idr-flowspec-v2-00.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-hares-idr-flowspec-v2 Revision: 00 Title: BGP Flow Specification Version 2 Document date: 2016-06-25 Group: Individual Submission Pages: 14 URL: = https://www.ietf.org/internet-drafts/draft-hares-idr-flowspec-v2-00.txt Status: = https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-v2/ Htmlized: = https://tools.ietf.org/html/draft-hares-idr-flowspec-v2-00 Abstract: BGP flow specification version 1 (RFC5575) describes the distribution of traffic filter policy (traffic filters and actions) which are distributed via BGP to BGP peers. Three applications utilize this traffic filter policy: (1) mitigation of Denial of Service (DoS), (2) enabling of traffic filtering in BGP/MPLS VPNS, and (3)centralized traffic control for networks with SDN or NFV controllers. Application of centralized traffic utilizing BGP Flow Specification traffic filters may need user-ordered filters rather than RFC5575's strict ordering of filters and defined ordering of actions. This document proposes a new BGP Flow specification version 2 that supports user-order of filters and actions plus allowing more actions = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Sat Jun 25 14:52:53 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D24012D151; Sat, 25 Jun 2016 14:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.965 X-Spam-Level: X-Spam-Status: No, score=-14.965 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mxF0kYvsAE2; Sat, 25 Jun 2016 14:52:45 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF1212D16C; Sat, 25 Jun 2016 14:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=127965; q=dns/txt; s=iport; t=1466891564; x=1468101164; h=from:to:cc:subject:date:message-id:mime-version; bh=i6NjaIPR1DMRTd1UywtUIWVdj8ldpRltO3a7BVBu8Fs=; b=SFUQwYrD2VW8Xoj7bU+0+egt4lNMq5NHXxxdntHmcxIlvc0VcWslts54 ftF6gmL6LrzKrVyT0TX0cs9bnZ3VG5ETK2i6bHX61jwcUVW7FG1JKC9KS Rtr88LloX2NhNKUOZD9p4DQ8CGDik2fcWOYySwsAne0NX9fpDeVpSLVZF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASBQBb/G5X/5hdJa1SAQmCcE5WfQa6J?= =?us-ascii?q?IF7JIV0gSQ5EwEBAQEBAQFlJ4RNAgQaAUwEBwcSAQgtCwE/JwQBDQMdiBUOA8c?= =?us-ascii?q?OAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWJcoEDhBgBZoUcBY17hT0VhTQBhgeCN?= =?us-ascii?q?ESFN4FphFSDLnuEPoZUiSoBHwE0ggUDHIFMPy8BiAsrGH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,528,1459814400"; d="scan'208,217";a="289909729" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jun 2016 21:52:42 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5PLqfAn022392 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 25 Jun 2016 21:52:41 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 25 Jun 2016 17:52:40 -0400 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1210.000; Sat, 25 Jun 2016 17:52:40 -0400 From: "Shitanshu Shah (svshah)" To: "Alvaro Retana (aretana)" , "draft-ietf-idr-sla-exchange@ietf.org" Thread-Topic: AD Review of draft-ietf-idr-sla-exchange-08 Thread-Index: AQHRzyvlvU+08NLC/kOdoAF0zVY3yg== Date: Sat, 25 Jun 2016 21:52:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.26.4] Content-Type: multipart/alternative; boundary="_000_D3940AC51A281svshahciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-sla-exchange-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 21:52:52 -0000 --_000_D3940AC51A281svshahciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Alvaro, Thank you for your review and detailed review comments.. Please find response inline ##svshah . If any review comment is missed out = with a response or have been marked as yet to be responded, will come back = with a response. Thanks Shitanshu Dear authors: I just finished reading this document. I have significant concerns with the content (see my detailed comments belo= w), and with the fact that the we're producing this document on SLAs in a r= outing WG. It is "ok" [*] to carry information in BGP that is not related = to routing, but in this draft we're really defining how to represent an SLA= . The only BGP-specific work is related to propagating a new transitive at= tribute =97 we don't need 30 pages for that!! Many of my comments are keyed off these statements in the Introduction: "Th= e Inter-domain exchange of QoS SLA exchange policy described in this docume= nt=85only requires that the provider wishes to send the QoS SLA policy via = BGP=85to a set of receivers=85The SLA negotiation and assurance is outside = the scope of this document." My interpretation is that BGP is then used a= s a simple transport for the SLA information and that it can't (and shouldn= 't!) concern itself with the interpretation, validation or enforcement of t= he information it is transporting. Given that, I want to first mention 3 overarching themes that I want to see= addressed (I also tried to indicate which theme the comments below relate = to): T1. The SLA Definition. As mentioned above, it concerns me that this WG ha= s taken on the task of defining the description of an SLA. At a minimum, t= his document should have been discussed in the TSV and OPS areas, for both = sanity checking and coordination. I found in the archive some exchanges wi= th tsvwg (from 2013, when the =9601 version was published) -- in the thread= , the tsvwg Chair mentions the need for coordination as they have related w= ork. However, the communication abruptly ends [1] -- note that the last re= commendation from tsvwg was against having multiple drop thresholds in DROP= _THRESHOLD (Section 3.3.2.8), but the current version still hast that =97 i= t does seem like the conversation was concluded=85 Please seek out review= from both tsvwg and opsawg (or at least the OPS-Dir). ##svshah, We had presented the draft to the TSVWG at the IETF meeting in th= e past as well had discussion with D. Black. It was concluded then that the= work in this draft is not related to some of the other work items that was= thought might be related. Current specification also is an outcome with re= view comments incorporated as a result of those discussions (for example - = use of TSPEC in one of the SLA Service Type). T2. Who does what? (aka which functionality belongs in BGP?) I then see the document as containing two distinct sets of specifications: = (1) how does BGP transport some information in a transitive attribute (incl= uding how a BGP speaker validates the formatting), and (2) how the user of = the SLA information (which is not the BGP speaker itself, but some other co= nsumer) should deal with it. I would really like to see a clear definition= of who (the BGP Speaker or something else) is executing the action =97 kee= ping into account that it is out of scope what exactly is done with the inf= ormation. I would like to propose a simple framework/terminology for the process, whi= ch I think is something like this: A. the SLA_Provider (which represents whoever/whatever comes up with the SL= A definition) gives the formatted information to BGP for it to transport (a= ssociated with a prefix, destined to a list of ASNs, etc.); B. BGP puts the formatted information in the QoS attribute and advertises i= t in an UPDATE; C. the BGP receiver verifies that the UPDATE is formatted correctly (includ= ing the QoS Attribute); D. a SLA_Consumer (which represents a local process that will make sense of= the content and maybe even do something with it) further verifies that the= content makes sense, keeps track of the SLA ID, etc.. Right now, the document doesn't clearly assign roles and it seems like ever= ything is done by the BGP speaker, where conceptually it isn't because BGP = is a routing protocol and not an SLA_Producer or SLA_Consumer. For example= (there are more cases below), Section 5.2. (SLA Attribute Handling at Rece= iver) says that "the receiving BGP peer SHOULD invalidate previous advertis= ed SLA parameters if one exists for the same SLA id and source AS." Follow= ing the conceptual model above, this action would be done by the SLA_Consum= er, who may care about the content itself. If you don't want to use the simple framework above and want to use other n= ames, that is perfectly fine. I just want the document to clearly reflect = what is done by BGP and what is done by someone else. ##svshah, The intention is indeed to have attribute specific content proces= sed by Attribute owner and content outside of attribute is processed by BGP= speaker. It is fair enough to define explicit terminology and explicit men= tion at places where it may otherwise come out vague. One change I would li= ke to propose is to call out QoS attribute producer and consumer roles inst= ead of SLA producer and consumer roles since that would be specific to SLA = SubType only. T3. Clarity and Consistency=85 I am very disappointed in the fact that the= SLA itself is underspecified, that there isn't consistency on the names us= ed (even within the definition of the fields!) and that some sections seem = to be left to the readers' interpretation (guessing!). Examples include si= mple things such as the units in which the length is indicated, and using c= onsistent names. Those may be easy to correct, but a Standards Track docum= ent should not be in this state at this point in the process. There are ma= ny more examples below. I'm returning the document to the WG for further processing. I expect that= proper coordination and review with TSV and OPS, including a new WGLC with= the appropriate WGs in cc (tsvwg, for example), takes place before returni= ng to the IESG. I recommend that other comments be addressed before embark= ing in reviews beyond idr. Thanks! Alvaro. [*] Given the fact that we already throw all kinds of stuff on top of BGP= =85 :-( [1] https://mailarchive.ietf.org/arch/msg/tsvwg/IjVdEF7KZyz0czm4YBXEr7KjmkU M1. [T1] [T2] Introduction: "The Inter-domain exchange of QoS SLA exchange = policy described in this document does not require any specific method for = the provider in establishing SLAs. It only requires that the provider wish= es to send the QoS SLA policy via BGP UPDATE [RFC4271] messages from the pr= ovider to a set of receivers (BGP peers) who will enact the policy. In rea= ction to, a receiving router may translate that to relevant QoS policy defi= nition on the device=85 The SLA negotiation and assurance is outside the s= cope of this document." ##svshah, =93The SLA negotiation and assurance is outside of the scope of t= his document=94 was highlighted in a paragraph after next. I=92ve incorpora= ted the statement here now as suggested and removed from the other place. M1.1. [T2] If I interpret this text correctly, the intent of this document = is to propagate the new attribute (with SLA information in it), but it take= s no position as to what the receivers do with the information. Is that co= rrect? ##svshah, We highlight use-case and intentions of receivers, why there is a= need to receive SLAs via in-band method. We do not standardize implementat= ion of any policy on that received SLAContent. M1.2 [T2] If so, then the "enact the policy" part above is out of place bec= ause there's no assumption as to what will happen with the information. ##svshah, removed. M2. [T3] Section 3.1. (SLA, QoS attribute sub-type, Definition) SubType = range is not defined correctly: s/0x0f/0xff What is the SubType length = expressed in, octets? ##svshah, addressed. Length is expressed in octets. M3. [T3] Section 3.2. (SLA SubType Value Field) M3.1 "Source AS=85Note that AS =3D 0, used in message outside of QoS attrib= ute, is illegal in normal BGP operations. AS =3D 0 inside the QoS attribut= e may be used simply as a flag=85" M3.1.1 [minor] Please put a reference to rfc7607. M3.1.2 Given that this document specifies a new valid use of AS 0, I think = it should be marked as Updating rfc7607. M3.1.3 What is the purpose of this field? ##svshah, the purpose of source/destination AS here is to cover the case wh= ere need is to advertise SLA to a specific AS beyond peer. AS =3D 0 is use= d as a flag. It does not seem right reason to create reverse dependency on = BGP protocol specification. We can add an explicit flag field, within SLA S= ubType, with a bit that can indicate the same reason. Section 4. (Originating SLA Notification) does say that the "QoS attribute = MUST only be added by the originator=85", but it seems easy to forge the va= lue here. ##svshah, QoS attribute MUST only be added by the originator, however "dest= ination AS list=94 needs to be updated by every recipient of an attribute. M3.2 For the "Destination AS list" field description, it should be clearly = specified the contents if the "Destination AS count" is 0. Also, please be= specific and clear (word are free!), for example: "List of ASNs for which = the SLA is relevant, each of which is a 32-bit number [rfcREFERENCE]. If t= he Destination AS count is set to 0, then this field SHOULD NOT (?) be incl= uded in this sub-TLV=85.=94 ##svshah, addressed M3.3 "SLA Event": the field in Figure 3 is simply called "Event". Please b= e consistent: either call both the same way or clarify which field is being= referenced. I know it may be obvious, but it doesn't make for a crisp spe= cification =97 other parts of the text simply use "event" as well. Please = be specific and clear as to what this field indicates. ##svshah, In the figure there is not enough space to fit =93SLA Event=94 wo= rds in the relevant size of bits. Keeping it to =93SLAEvnt=94 ok? Addressed= it in other places. M3.4 SLA Id M3.4.1 "A 16-bit field containing identifier which is unique in scope of so= urce AS" What happens if the Source AS is set to 0? M3.4.2 [minor] "The SLA ID applies aggregate for all the traffic=85" I'm = guessing you meant to talk about the "aggregate traffic"=85?? ##svshah, yes. I=92ve reworded to =93The SLA ID applies to aggregate traffi= c=85" M3.4.3 "The SLA identifier is not globally unique but it MUST be unique wit= hin the source AS (advertiser)." What happens if the Source AS field is se= t to 0? The text in the Source AS field description says that when the val= ue is 0 then "ignore Source=85". What does this do to the content of the S= LA ID. ##svshah, If Source AS in the QoS attribute is 0 then sender of BGP update = message is considered as source AS. Thus there is always a source in the co= ntext. M3.4.4 [minor] BTW, please be consistent: SLA ID, SLA id, SLA Id, SLA iden= tifier, etc M3.5 What is the "SLA Length" field expressed in? ##svshah, addressed M3.6 SLA-Content per SLA Event M3.6.1 The name seems to hint at the fact that the content is "per Event", = but it is not described anywhere how multiple events would be encoded, or i= f even possible (see my comment above about the Event field). ##svshah, current specification has only one defined SLA Event, that is =93= ADVERTISE". The specification allows to define more in the future if need b= e. And thus being specific on the SLAContent that goes with what type of SL= A Event. M3.6.2 Is the name of this field "SLA-Content per SLA Event" or "SLA-Conten= t"? Please be consistent. M3.6.3 "If the SLA-Content field does not exist=85then receiver MUST inheri= t the previously advertised SLA content for the same SLA id from the same S= ource AS." The next two paragraphs try to cover for the fact that the ord= er cannot be guaranteed (specially more than one AS hop away). But this al= l means that there is a significant possibility that a number of UPDATES wi= ll not have any SLA information at all. Then what is the point? When woul= d you want to take advantage of this feature? ##svshah, SLA-Content is optional in the sense they don=92t need to be repe= ated every time when Advertiser would like to advertise more prefixes to be= subjected to the same SLA. SLA ID as an identifier is enough to advertise = in such case. We already have highlighted case of non-existence prior adver= tised SLA-content just to cover error case (to address one of the review co= mments). M4 [T3] Section 3.3. (SLA-Content per Event Field) M4.1 [nit] s/=85and then optionally followed by for the opposite direction/= =85and then optionally followed by the specification for the opposite direc= tion ##svshah, addressed M4.2 [nit] The format of the field starts with the "dir" field =97 is the f= ollowing text really necessary: "This list of Traffic Classes MUST be speci= fied for one direction first=85" It seems obvious to me. ##svshah, I think it is important to highlight to discourage alternating se= t of classes (like incoming/outgoing/incoming/outgoing/.. and so forth). I = think the text is necessary for the same reason. M4.3 "dir=85indicates Direction of the SLA." I'm guessing direction from t= he senders point of view, is that correct? Please be specific. ##svshah, it is highlighted in the definition of =93incoming=94 and =93outg= oing" M4.4 "Traffic Class (Classifier Group) count=85value of zero (0x00)=85inval= idates previous advertised SLA=85" In this case, I'm assuming that all the= other fields are not needed, is that correct? If so, then they are option= al and should be described that way. M4.5 "Class Descr Len=85length of the Traffic Class Description field" Le= ngth in what units? ##svshah, addressed M4.6 [minor] "Traffic Class Description" A reference for UTF-8 (rfc3629 I = believe) would be nice. ##svshah, addressed M4.7 "Elements (Classifier) Count=85value zero (0x00) means=85traffic class= is to classify rest of the traffic not captured otherwise by other traffic= classes=85RECOMMENDED that Traffic Class that has 0 elements is present la= st=85If an advertised message has it positioned somewhere else, then the re= ceiver MUST re-order it=85" This text (as is) implies that the 0x00 class= ifier SHOULD be present last =97 is that what you meant, for it to always b= e present? If so, why not use MUST and eliminate the reordering logic? Or= was the intent that if present then it should go last? ##svshah, the text intends to imply a class with no elements (not classifie= r 0x00). Agree with your suggestion, we can use MUST and eliminate reorderi= ng logic. M4.8 Classifier Element TLVs: M4.8.1 The description talks about "Classifier Element TLVs", but Figure 4 = calls them "Traffic Class Elements (TLVs)". Please be consistent. M4.8.2 "Size of Value field=85length of the value field." Length in octet= s, bytes, bits, ??? ##svshah, addressed M4.8.3 [T2] "Value=85It is an error if the IPFix field does not contain the= appropriate format" This statement gets into interpretation of the conten= ts of the attribute. If the purpose of this document is to just transport = information, then why would it be a function of BGP to figure out if the co= ntents are correct? Please be clear about whether the BGP Speaker or SLA_C= onsumer should perform a function. M4.8.4 "If a receiver receives a BGP UPDATE message with QoS/SLA attribute = for an NLRI that it does not support then the receiver MUST NOT install tha= t advertised SLA and continue to forward this attribute as an optional tran= sitive attribute." What does "an NLRI that it does not support" mean? Are= you talking about an NLRI from a specific unsupported AFI/SAFI, or ?? ##svshah, yes, it was already qualified in the statement before, and so AFI= /SAFI was not repeated. Re-worded appropriately. M4.9 Traffic Class Service TLVs: M4.9.1 The units for the length are (again!) not specified. I realize that= it may be in bits (given the next couple of paragraphs), but the reader sh= ouldn't have to guess. M4.9.2 As long as you're thinking about the length, please check all the le= ngth descriptions =97 I think most of them are missing the units, but this = is getting tedious=85 ##svshah, It is specified explicitly. The size of the length field is speci= fied as 8-bits and what size of the value field should and expressed in wha= t is described for each service-type. Currently, list of service-types and = related size of fields is repeated twice at two different places. I=92ve mo= dified content to keep it only at one place, that way all relevant details = at one place. M4.9.3 Please note that the length of the value fields is not described con= sistently. For example, it says that TRAFFIC_CLASS_TSPEC is 96 bits, but 3= .3.2.3 talks about octets for MINRATE_IN_PROFILE_MARKING. ##svshah, addressed M4.9.4 "Value=85It is an error if this field does not contain the appropria= te format (see BGP error handling section=85." Not only is this error app= ropriate for the SLA_Consumer, but the "appropriate format" is not clearly = identified in the description of all the TLVs. M5 [T1] Section 3.3.1. (Supported IPFIX values for Classifier Elements) M5.1 [minor] The correct link to the IPFIX Registry is https://www.ietf.org= /assignments/ipfix/ipfix.xml#ipfix-information-elements M5.2 "Only the IPFIX attributes listed in Table 1 are supported by BGP SLA = exchange." Why? If this document is just about carrying a new attribute t= hat is opaque to BGP itself and that may or may not result in an action at = the receiver (see above), then why not support any IPFIX element? Maybe no= t all of the elements make sense, but some surely seem to =97 ipClassOfServ= ice, for example. ##svshah, we already have dot1q priority covered as well diffserv and mpls-= exp . Diffserv already has a support for CS0..CS7 and thus need of ToS is r= edundant and not needed. ipClassOfService thus is not required given those = 3 fields covered. M5.3 "Any new attribute to be supported by SLA QOS MUST be added by a Stand= ards Action." To be added where? The IPFIX registry has a different regis= tration procedure (Expert Review) -- are you referring to adding elements t= here? Or adding elements (already in the IPFIX registry) to Table 1? Or ?= ? ##svshah, yes in Table 1. It is mentioned in the IANA Consideration section= . M6 [T1] [T3] Section 3.3.2.1. (Traffic Class TSPEC TLV) The value of this T= LV "consists of the (r), (b), (p) parameters as described in Invocation Inf= ormation section of [RFC2212]=85". However, the definition in the document= is not the same as the one in rfc2212. For example, this document defined= r as "measured in octets of Layer 2 (L2) datagrams per second", while rfc2= 212 says that it is "measured in bytes of IP datagrams per second". If the= intent is to (as stated in the document) use the definitions from rfc2212,= then don't redefine the terms. ##svshah, The suggestion from tsvwg during review was to use RFC2212 TSPEC = for the purpose of rate specification. However, specification of those para= meters need to be in L2 datagram size for the purpose of this specification= unlike IP datagram size in RFC2212. What is a recommendation? M7 [T1] [T2] [T3] Section 3.3.2.2. (Traffic Class L2 Overhead): M7.1 [T3] Section 3.3.2.2. (Traffic Class L2 Overhead) How is the L2 overh= ead defined? ##svshah, added clearer definition of L2 overhead M7.2 [T1] [T2] "When the receiver chooses to react to an advertised SLA and= if the L2 Overhead service type is present in advertised SLA, the receiver= MUST use the explicit advertised L2 overhead rather than the local L2 over= head." In the context of this document, where the use of the SLA is out of= scope, what does "react to an SLA" mean? IOW, we can't mandate what the= receiver does, or how it does it if outside the scope. ##svshah, The intention of this statement is to define semantics of the fie= ld and what it means to the receiver from semantics point of view. The purp= ose of this statement is to mandate on a receiver on how to interpret it. N= othing beyond that. M7.3 [T1] "If SLA is required to consider only IP packet size, the sender M= AY advertise this service with a value of 0." Again, the reason is out of = scope. The ability to advertise a value of 0 is not. ##svshah, reworded to define only semantics of the field. Though just re-it= erate, use-case and intention why we need to advertise SLA is clearly highl= ighted. What is not in the scope of this specification is standardizing any= policy and how to implement any policy on received SLA. M8. [T1] Section 3.3.2.7. (Precedence between MINRATE and MAXRATE) Back to= the data being opaque..why is this section included in the document? ##svshah, This is important from the perspective of defining clear semantic= s of advertised fields. So that it does not remain vague even from the view= point of advertiser. M9. [T3] Section 3.3.2.9. (Traffic Class for Relative Priority) "Length = =3D 4 bits" Unlike all the other length issues I've pointed at, this time = you seem to be indicating the length of the Value field. Does this mean th= at the Length field in they TLV should be set to 4 (as in "the length of th= e Value field in bits"), or that the Length field should not even be presen= t because it is always 4 bits, or something else?? ##svshah, yes the length field in the TLV to be set to 4. Since length of t= he value, for each service type, is clearly highlighted in earlier section = it is not repeated here again. I=92ve collapsed content from both the place= s to one now to make it clearer for the reading, as well addressed any cons= istency issues. M10 Section 4.1.2. (SLA Advertisement for Destination AS Multiple Hops Away= ) "If a new prefix is added in an AS for which SLA parameters have already = been advertised before for other existing prefixes, and if traffic to this = new prefix is subject to the same SLA advertised earlier, then the BGP UPDA= TE for this new prefix may include QoS attribute containing just an SLA id= =85" M10.1 Is this behavior also valid for directly connected peers? ##svshah, Semantically yes it is. M10.2 The description above assumes that the receiver has the SLA descripti= on from a previous UPDATE. See my comments above about Section 3.2. ##svshah, the description highlights to advertise whole SLA content if it i= s first time advertised to a set of recipients, or else advertising just SL= A ID is sufficient for the subsequent additional prefixes for the same reci= pients. M11. [T2] Section 5.1. (BGP Node Capable of Processing QoS Attribute) M11.1 Back to the opaqueness of the attribute from the BGP point of view an= d how the use of the information is out of scope. What does "processing" m= ean in this context? I think you will need to separate the processing done= by the BGP Speaker from what the SLA_Consumer should do. ##svshah, I would have thought that processing of any content of an attrib= ute (either QoS or any other attribute), is always attribute owner=92s resp= onsibility. I can see your point though that places with grey area needs ex= plicit clarification. Let me re-work content to separate the processing don= e by BGP Speaker from that to be of QoS attribute. M11.2 "If UPDATE has a QoS Attribute with a list of destination ASes, it MA= Y trim the list and adjust the count of the destination AS to exclude ones = that are not required in further announcement of BGP UPDATE messages." Jus= t to make sure I'm looking at this from the right place: this text applies = to a BGP speaker that received the QoS attribute from someone else and is n= ow getting ready to propagate it, right? If so, isn't changing the list of= destination ASes basically an attack on the intent of the origin? ##svshah, would that not be true for any attributes supported today? It is = clarified though in the Security consideration section. M11.3 "BGP peer MUST drop SLA related sub-type from the QoS attribute, if t= here are no more ASes from the QoS Attribute's destination list in the forw= arding path. The rest of the QoS attribute contents MAY be Forwarded=85=94 M11.3.1 What is the "forwarding path"? I'm guessing that means something l= ike: if the AS is not connected to any other AS on the list (except the one= it just received the UPDATE from)=85 What is it and how can the ingress BG= P speaker in the AS figure it out? ##svshah, yet to respond M11.3.2 [minor] Please be consistent with the naming. I'm assuming that "S= LA related sub-type" is really the SLA sub-type value 0x01=85 Even though = they are not defined yet, other sub-types may also refer to SLAs. ##svshah, correct M11.3.3 The "MAY" above is normative in a "forward" manner: affects potenti= al future SubTypes. If new SubTypes are defined later, let them define the= behavior. s/MAY/may ##svshah, addressed M11.3.4 [minor] Note that this whole paragraph is repetitive, please simpli= fy it. ##svshah, I think you may be referring to beginning of the paragraph referr= ing to dropping of SLA subtype from the QoS attribute and remaining of the = paragraph referring to dropping entire QoS attribute. Both of them are sepa= rate functions and thus need to specify both. Or did you mean to point some= thing else? M12. [T1] [T2] [T3] Section 5.2. (SLA Attribute Handling at Receiver) M12.1 "Reception of and processing of advertised QoS SLA content are option= al for the receiver." What do you mean that "reception" is optional? What= is "processing"? Given that the use of the SLA is outside the scope, I ca= n only guess that "processing" means at least parsing the contents (not act= ually doing anything with them). If so, what do you mean by saying that "p= rocessing" is optional? In general, if an attribute is sent inside an UPD= ATE it then has to be "received" (unless all the NLRI contents are filtered= by policy) and "processed". This part sounds like it belongs with the SLA= _Consumer. ##svshah, ok M12.2 "the receiving BGP peer SHOULD invalidate previous advertised SLA par= ameters if one exists for the same SLA id and source AS." I think you real= ly want the SLA_Consumer (not the BGP peer). ##svshah, ok What does "invalidate" mean in this context? Maybe replace or an indicat= ion what the new version, etc. ##svshah, =93invalidate=94 here means remove earlier advertised SLA content= and context M12.3 "If the new advertised SLA has a non-zero traffic count=85" "traffic= count" is not defined anywhere in the document=85 I guess you mean the "T= raffic Class count" -- please be clear and specific. ##svshah, yeah its typo. The very next sentence is referred with Traffic Cl= ass count M12.4 "=85then the new advertised SLA SHOULD be installed" Installed? Th= is sounds like you're specifying what to do with the SLA specification=85ou= tside the scope! Even for the SLA_Consumer=85 M12.5 "When BGP UPDATE messages are triggered only as a result of SLA polic= y change=85the receiver MAY implement a policy to filter such messages base= d on the prefix and attribute." I appreciate the intent, but what about ch= anges in other attributes? ##svshah, This is purely administrative. What this suggest is that if admin= istratively known that SLAs advertised from specific AS (or group of AS) a= re only as a result of SLA policy change and thus BGP UPDATE messages, cont= aining QOS attribute with SLA SubType, only means such. In this case BGP UP= DATE messages are not expected to carry any other useful information or any= other attributes besides QoS attribute with SLA subType. In this case a po= licy can filter for relevant prefixes and QoS attribute to drop such messag= es. IOW, the receiver doesn't know that the change was only due to an SLA pol= icy change (which from the BGP point of view may be better called something= like "an update in the QoS attribute"). Please clarify that if the filter= is put in place, all the other attributes need to be checked as well. BTW= , I think that the "MAY" should be "may", but that is minor. M12.6 "=85the receiver MAY implement advertised SLA for the whole link=85" = This is an indication of what to do with the SLA=85out of scope! M12.7 "=85QoS attribute with the SLA=85" To be complete, I think you mean = "with the SLA SubType field=94. ##svshah, will address M12.8 "=85then receiver may establish advertised SLA for that specific pref= ix list under the relevant link." Even thought not in a normative way, thi= s text also talks about the use of the SLA=85out of scope! M12.9 "It is completely up to the receiver to decide for which prefixes it = should accept advertised SLA and for which ones it will not accept." Which= receiver? I'm guessing the SLA_Consumer, because the BGP speaker has no c= hoice but to accept any attribute=85 Are you implying here that the BGP sp= eaker should be able to selectively filter QoS Attributes? ##svshah, will rephrase to make it clearer and with BGP speaker vs QoS attr= ibute processing M13. Section 6. (Error Handling) M13.1 [T2] What is an "error condition"? I counted 4 places where an error= was explicitly identified =97 surely there are more cases that would resul= t in an "error condition". I'm assuming that a malformed attribute (as in = the length not matching) is an obvious one (no need to explicitly call that= out, but maybe a reference to the general attribute processing in rfc4271 = would be good)=85 ##svshah, I understand reference to rfc7606 would imply reference to rfc427= 1? but what about if the Source AS is set to 0 and the Destination AS count is= not 0, is that an error? ##svshah, that is not an error as per current specification that suggests t= hat when source AS is 0, ignore destination AS count and list. M13.2 [T2] OTOH, errors on general attribute format checking (do the length= s/counts match, etc.) is where attribute-discard applies for the BGP Speake= r=85other errors (including some of the ones explicitly identified in the t= ext) may be more in the domain of the SLA_Consumer. Note that even though = the SLA_Consumer may decide to not use the SLA (which is equivalent to attr= ibute discard), I think some of the checking (formatting of the values, for= example) doesn't belong to the BGP Speaker. ##svshah, sure, that was the thought process that in general for any attrib= ute specific processing and error handling belongs to attribute owner. It m= ay just so happen that most of the attributes are inherently part of BGP sp= ecification and thus may not be need for explicit about such separation. I= =92ll address making it appropriately clear in the specification. M13.3 [nit] s/attribute-discard/attribute discard ##svshah, addressed M14. Section 7. (Traffic Class Mapping) What is done with the SLA is out o= f scope! The mapping, or not, of policies is also out of scope =97 special= ly the normative language included in the section. Recommendation: delete = this section completely. ##svshah, that may be fine. This may serve as a guidance though for implem= entations that may choose to implement a policy on received SLA. While we r= emove this section, shall we keep couple of sentences some-where on such? M15. Section 11. (Security Considerations) M15.1 "The QOS attribute defined in this document SHOULD be used by the man= aged networks for enforcing Quality of Service policies=85" The use of SLA= information is out of scope! ##svshah, removed =93enforcing Quality of Service policies=94. M15.2 "=85so there should not be any risks for identity thefts." What does= that mean? Identity theft? Are you talking about the possibility of hija= cking? (I'm just guessing because the next sentence talks about Origin Val= idation.) ##svshah, some-one advertising SLA pretending to be specific source AS, and= yeah thus Origin Validation. M15.3 "To strengthen the security for the QoS attribute, RPKI based origin = validation [RFC7115] MAY be used." How does Origin Validation strengthen t= he security of the QoS attribute? Origin Validation can help the receiver = verify that the origin AS is in fact authorized to advertise an NLRI, ##svshah, yes, that is what it intends to achieve. but not that the valid prefix origin did in fact also originate the QoS att= ribute. Section 4. (Originating SLA Notification) does say that the "QoS = attribute=85MUST NOT be added during BGP propagation", but there doesn't se= em to be a way to detect non-compliance making it an important security con= sideration. ##svshah, yet to look at it and respond accordingly.. M15.4 "=85BGP Path Validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]) proce= dures could be used over BGP QoS attribute and its associated prefix in pro= ducing the digital signature that can be carried within the signature SLA f= or the messages." What is the "signature SLA"? This text is proposing to = change BGPSec =97 as is, this proposal presents no assurances over the *cur= rent* risk of a MITM (until maybe someday the proposal is specified and imp= lemented). I would rather you clearly identify why there is a risk of MITM= =97 and then say that there is no solution (which is the same as for other= transitive attributes). ##svshah, ok M15.5 Speaking of MITM, what about privacy? Even if the MITM doesn't chang= e the QoS attribute it can still glean a lot of useful information from jus= t forwarding the UPDATES. Please include some text about privacy. Please = take a look at RFC6973. ##svshah, ok M16. [T3] Section 10. (IANA Considerations) M16.1 There is no guidance about the QoS Attr flags. I know they are not u= sed in this document, but because it is the document that defines them it w= ould be good to have a registration criteria. ##svshah, since there is no usage of any bits today and we have this in ant= icipation of possible future usage but since there is no awareness of any p= ossible future usage, we thought it may not be something useful to track it= as IANA registry yet. Do you think shall we still have it? M16.2 [minor] I know the space is small, but the SubTypes and SLA Event Typ= es have a registration procedure of Standards Action. I wonder if having a= value (maybe just one) for Private Use could be beneficial to allow people= to put their own stuff in there=85 ##svshah, it is a great suggestion. that indeed can be very useful. address= ed. M16.3 [minor] This sentence seems out of place since it provides no guidanc= e to IANA: "QoS SLA Traffic Class Element Types will be referring to existi= ng IPFIX IANA types as listed in Table 1.=94 ##svshah, should I keep it here though for completeness to the reader? Minor: m1. [T1] The Introduction talks about the fact that other "protocols and da= ta models are being created to standardize setting routing configuration pa= rameters within networks. YANG data models=85the I2RS protocol", but that = "some providers desire to exchange QoS parameters in-band utilizing BGP pee= ring relationships." Two related questions: m1.1 Is there specific YANG/i2rs work in process that matches what is defin= ed here? How are the models similar/different? Note that this is not a qu= estion about comparing the use of YANG models, the i2rs protocol and the me= chanism using BGP -- I just want to know if there are other similar effort= s in progress and how they are in sync or not. The underlying question is = really about whether an operator will be able to use a NETCONF/i2rs to conf= igure the SLA information received in a BGP session (as specified in this d= ocument). I know that anything is possible, but is that the direction that= is being taken today? ##svshah, QoS Yang Data Model is quite early in works which is submitted as= individual draft as of now in the netmod wg. Though currently they seem to= be aligned, it is quite early to say (I=92ve been involved in the QoS Yang= Data Model review). Though, the statement here regarding yang/i2rs work wa= s added specifically as a result of review comment from the wg on this draf= t. m1.2 Are there implementations? It would be nice to add a section ala rfc6= 982 and point to the idr wiki from there. ##svshah, I am not aware of any implementation of Yang models. m2. [T3] The new attribute is called by several different names in the docu= ment: "QoS Attribute", "QoS/SLA Attribute", "QoS BGP attribute", and simply= "attribute" in a couple of cases. Please be consistent!!! ##svshah, addressed m3. Section 3.3.2.3. (Traffic Class for MINRATE_IN_PROFILE_MARKING) I'm n= ot sure how to interpret this: "Marking code-point type =3D 8 bits (1 octe= t) IPFIX Element Identifier=85The marking code-point type of 0x00 is a drop= identifier; the length in this case is zero." IPFIX has Element ID 0 as = reserved. I'm guessing that you mean that if the code-point is 0x00, to be= tter yet, if the length is 0, then drop. ??? ##svshah, it should read =93marking code-point value in this case has no me= aning and thus the value in this filed should be ignore=94. m3.1 Same comment for 3.3.2.4, 3.3.2.5 and 3.3.2.6 ##svshah, addressed m4. For all the sub-sections in 3.3.2, please put in a short explanation of= what each TLV represents. ##svshah, ok m5. Section 8. (Deployment Considerations) I think this section should rea= lly be called "Use Cases" and moved earlier in the document, maybe even as = part of the Introduction. It would be very nice if the case for propagatin= g the QoS Attribute through multiple AS hops was also illustrated. ##svshah, yet to be addressed. m6. References m6.1 RFC3270 should be Informative m6.2 If RFC7115 is referenced as Normative, then so should I-D.ietf-sidr-bg= psec-protocol because you're offering them as solutions to security issues.= Please take a look at my comments on the Security Considerations Section = above. ##svshah, addressed m6.3 For the illustration in the document, I don't think the reference to R= FC7674 is needed. ##svshah, it has been referred in the Introduction. That is why added in th= e reference. Nits: n1. s/=85and then optionally followed by for the opposite direction/=85and = then optionally followed by the specification for the opposite direction n2. Please expand on first use: TSpec ##svshah, addressed n3. In 3.3.2.3, please be explicit that the Value contains the Marking code= -point type and value. n4. In 4.1, "next hop to CE (that is the next hop address from CE to PE)"= =85shouldn't that be "next hop to PE=94? ##svshah, removed =93next hop to CE=94 and used wording from the parenthese= s. --_000_D3940AC51A281svshahciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3533CFF7800FAD40AD9A79736CAEFBA1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Dear Alvaro,

Thank you for your review and detailed review comments..

Please find response inline ##svshah . If any review comment is missed out = with a response or have been marked as yet to be responded, will come back = with a response.

Thanks
Shitanshu



Dear authors:

I just finished reading this document.

I have significant concerns with the content (see my detailed comments belo= w), and with the fact that the we're producing this document on SLAs in a r= outing WG.  It is "ok" [*] to carry information in BGP that = is not related to routing, but in this draft we're really defining how to represent an SLA.  The only BGP-specific work = is related to propagating a new transitive attribute =97 we don't need 30 p= ages for that!!

Many of my comments are keyed off these statements in the Introduction: &qu= ot;The Inter-domain exchange of QoS SLA exchange policy described in this d= ocument=85only requires that the provider wishes to send the QoS SLA policy= via BGP=85to a set of receivers=85The SLA negotiation and assurance is outside the scope of this document."   My interpretation is = that BGP is then used as a simple transport for the SLA information and tha= t it can't (and shouldn't!) concern itself with the interpretation, validation or enforcement of the information it is transporting.

Given that, I want to first mention = 3 overarching themes that I want to see addressed (I also tried t= o indicate which theme the comments below relate to):

T1. The SLA Definition.  As mentione= d above, it concerns me that this WG has taken on the task of defining the = description of an SLA.  At a minimum, this document should have been discussed in the TSV and OPS areas, for both sanity checking and coordination.  = ;I found in the archive some exchanges with tsvwg (from 2013, when the = ;=9601 version was published) -- in the thread, the tsvwg Chair mentions th= e need for coordination as they have related work.  However, the communication abruptly ends [1] -- note that the = last recommendation from tsvwg was against having multiple drop thresh= olds in DROP_THRESHOLD (Section 3.3.2.8), but the current version stil= l hast that =97 it does seem like the conversation was concluded=85   Please se= ek out review from both tsvwg and opsawg (or at least the OPS-Dir).  <= /font>

##svshah, We had presented the draft= to the TSVWG at the IETF meeting in the past as well had discussion with D= . Black. It was concluded then that the work in this draft is not related t= o some of the other work items that was thought might be related. Current specification also is an outcome wit= h review comments incorporated as a result of those discussions (for example -  use= of TSPEC in one of the SLA Service Type).


T2. Who does what?  (aka which funct= ionality belongs in BGP?)  &n= bsp;

I then see the document as containing two distinct sets of specifications: = (1) how does BGP transport some information in a transitive attribute (incl= uding how a BGP speaker validates the formatting), and (2) how the user of = the SLA information (which is not the BGP speaker itself, but some other consumer) should deal with it. &nbs= p;I would really like to see a clear definition of who (the BGP Speaker or = something else) is executing the action =97 keeping into account that it is= out of scope what exactly is done with the information.

I would like to propose a simple framework/terminology for the process, whi= ch I think is something like this:  
A. the SLA_Provider (which represents whoever/whatever comes up with the SL= A definition) gives the formatted information to BGP for it to transport (a= ssociated with a prefix, destined to a list of ASNs, etc.); 
B. BGP puts the formatted information in the QoS attribute and advertises i= t in an UPDATE; 
C. the BGP receiver verifies that the UPDATE is formatted correctly (includ= ing the QoS Attribute);
D. a SLA_Consumer (which represents a local process that will make sense of= the content and maybe even do something with it) further verifies that the= content makes sense, keeps track of the SLA ID, etc..

Right now, the document doesn't clearly assign roles and it seems like= everything is done by the BGP speaker, where conceptually it isn't because= BGP is a routing protocol and not an SLA_Producer or SLA_Consumer.  F= or example (there are more cases below), Section 5.2. (SLA Attribute Handling at Receiver) says that "the rece= iving BGP peer SHOULD invalidate previous advertised SLA parameters if one = exists for the same SLA id and source AS."  Following the concept= ual model above, this action would be done by the SLA_Consumer, who may care about the content itself.

If you don't want to use the simple framework above and want to use ot= her names, that is perfectly fine.  I just want the document to clearl= y reflect what is done by BGP and what is done by someone else.  

##svshah, The intention is indeed to have attribute specific content p= rocessed by Attribute owner and content outside of attribute is processed b= y BGP speaker. It is fair enough to define explicit terminology and explici= t mention at places where it may otherwise come out vague. One change I would like to propose is to call ou= t QoS attribute producer and consumer roles instead of SLA producer and con= sumer roles since that would be specific to SLA SubType only.


T3. Clarity and Consistency=85  I am= very disappointed in the fact that the SLA itself is underspecif= ied, that there isn't consistency on the names used (even within the defini= tion of the fields!) and that some sections seem to be left to the readers' interpretation (guessing!).  Examples include= simple things such as the units in which the length is indicated, and=  using consistent names.  Those may be easy to correct, but a Sta= ndards Track document should not be in this state at this point in the process.  There are many more examples below.



I'm returning the document to the WG for further processing.  I expect= that proper coordination and review with TSV and OPS, including a new WGLC= with the appropriate WGs in cc (tsvwg, for example), takes place before re= turning to the IESG.  I recommend that other comments be addressed before embarking in reviews beyond idr.

Thanks!

Alvaro.

[*] Given the fact that we already throw all kinds of stuff on top of BGP= =85 :-( 


M1. [T1] [T2] Introduction: "The Inter-domain exchange of QoS SLA exchange policy described in = ;this document does not require any specific method for the provider i= n establishing SLAs.  It only requires that the provider wishes to send the QoS SLA policy via BGP UPDATE [RFC4271] messages f= rom the provider to a set of receivers (BGP peers) who will enact the = policy.  In reaction to, a receiving router may translate that to rele= vant QoS policy definition on the device=85  The SLA negotiation and assurance is out= side the scope of this document."
##svshah, =93The SLA negotiation and assurance is outside of the = scope of this document=94 was highlighted in a paragraph after next. I=92ve= incorporated the statement here now as suggested and removed from the othe= r place.


M1.1. [T2] If I interpret this text = correctly, the intent of this document is to propagate the new attribute (with SLA information in i= t), but it takes no position as to what the receivers do with the information.  Is that correct?
##svshah, We highlight use-case and intentions of receivers, why there is a= need to receive SLAs via in-band method. We do not standardize implementat= ion of any policy on that received SLAContent.

M1.2 [T2] If so, then the "enact the= policy" part above is out of place because there's no assumption as t= o what will happen with the information.
##svshah, removed.


M2. [T3] Section 3.1. (SLA, QoS attribute sub-type, Definition)   &nbs= p;SubType range is not defined correctly: s/0x0f/0xff    What is = the  SubType length expressed in, octets?
##svshah, addressed. Length is expressed in octets.


M3. [T3] Section 3.2. (SLA SubType Value Field) 

M3.1 "Source AS=85Note that AS =3D 0, used in message outside of = QoS attribute, is illegal in normal BGP operations.  AS =3D 0 inside t= he QoS attribute may be used simply as a flag=85"
M3.1.1 [minor] Please put a reference to rfc7607.
M3.1.2 Given that this document specifies a new valid use of AS 0, I t= hink it should be marked as Updating rfc7607.
M3.1.3 What is the purpose of this f= ield?  
##svshah, the purpose of source/destination AS here is to cover the ca= se where need is to advertise SLA to a specific AS beyond peer. AS =3D= 0  is used as a flag. It does not seem right reason to create reverse= dependency on BGP protocol specification. We can add an explicit flag field, within SLA SubType, with a bit that can in= dicate the same reason.


Section 4. (Originating SLA Notification) does say that the "= ;QoS attribute MUST only be added by the originator=85", but it= seems easy to forge the value here.
##svshah, QoS attribute MUST only be added by the originator, however = "destination AS list=94 needs to be updated by every recipient of an a= ttribute.


M3.2 For the "Destination AS list" field description, it sho= uld be clearly specified the contents if the "Destination AS count&quo= t; is 0.  Also, please be specific and clear (word are free!), for exa= mple: "List of ASNs for which the SLA is relevant, each of which is a 32-bit number [rfcREFERENCE].  If the Destination AS count= is set to 0, then this field SHOULD NOT (?) be included in this sub-TLV=85= .=94
##svshah, addressed


M3.3 "SLA Event": the field in Figure 3 is simply called &qu= ot;Event".  Please be consistent: either call both the same way o= r clarify which field is being referenced.  I know it may be obvious, = but it doesn't make for a crisp specification =97 other parts of the text simply use "event" as well.  Please be specific an= d clear as to what this field indicates.
##svshah, In the figure there is not enough space to fit =93SLA Event=94 wo= rds in the relevant size of bits. Keeping it to =93SLAEvnt=94 ok? Addressed= it in other places.


M3.4 SLA Id
M3.4.1 "A 16-bit field containi= ng identifier which is unique in scope of source AS"  = ;What happens if the Source AS is set to 0?
M3.4.2 [minor] "The SLA ID appl= ies aggregate for all the traffic=85"   I'm guessing you mea= nt to talk about the "aggregate traffic"=85??
##svshah, yes. I=92ve reworded to&nb= sp;=93The SLA ID applies to aggregate traffic=85"

M3.4.3 "The SLA identifier is not globally unique but it MUST be unique within the source = ;AS (advertiser)."  What happens if the Source AS field is set to 0?  The text in t= he Source AS field description says that when the value is 0 then "ignore Source=85".  What do= es this do to the content of the SLA ID.
##svshah, If Source AS in the QoS at= tribute is 0 then sender of BGP update message is considered as source AS.&= nbsp;Thus there is always a source= in the context.

M3.4.4 [minor]  BTW, please be = consistent: SLA ID, SLA id, SLA Id, SLA identifier, etc
M3.5 What is the "SLA Length" field expressed in?
##svshah, addressed


M3.6 SLA-Content per SLA Event
M3.6.1 The name seems to hint at the= fact that the content is "per Event", but it is not describ= ed anywhere how multiple events would be encoded, or if even possible = (see my comment above about the Event field).
##svshah, current specification has = only one defined SLA Event, that is =93ADVERTISE". The specificat= ion allows to define more in the future if need be. And thus being spe= cific on the SLAContent that goes with what type of SLA Event.

M3.6.2 Is the name of this field &qu= ot;SLA-Content per SLA Event" or "SLA-Content"?  Please= be consistent.
M3.6.3 "If the SLA-Conte= nt field does not exist=85then receiver MUST inherit the previously advertised SLA content for the same SLA id from the same Source AS."   The next two paragraphs try to cover for the = fact that the order cannot be guaranteed (specially more than one AS hop aw= ay).  But this all means that there is a significant possibility that = a number of UPDATES will not have any SLA information at all.  Then what is the point?  When would you want to take ad= vantage of this feature?
##svshah, SLA-Content is optional in= the sense they don=92t need to be repeated every time when Advertiser woul= d like to advertise more prefixes to be subjected to the same SLA. SLA ID a= s an identifier is enough to = advertise in such case. We already have highlighted case of non-existence prior adve= rtised SLA-content just to cover error case (to address one of the review c= omments).



M4 [T3] Section 3.3. (SLA-Content per Event Field)

M4.1 [nit] s/=85and then optionally followed by for the opposite = direction/=85and then optionally followed by the specification for the oppo= site direction
##svshah, addressed

M4.2 [nit] The format of the field s= tarts with the "dir" field =97 is the following text really neces= sary: "This list of Traffic Classes MUST be specified for = one direction first=85"  It seems obvious to me.
##svshah, I think it is important to highlight to discourage alternati= ng set of classes (like incoming/outgoing/incoming/outgoing/.. and so forth= ). I think the text is necessary for the same reason.


M4.3 "dir=85indicates Direction of the SLA."  I'm guess= ing direction from the senders point of view, is that correct?  Please= be specific.
##svshah, it is highlighted in the d= efinition of =93incoming=94 and =93outgoing"

M4.4 "Traffic Class (Cla= ssifier Group) count=85value of zero (0x0= 0)=85invalidates previous advertised SLA=85"  In this case, I'm assuming that all the other fields are not needed, is that correct?  If so, then they are o= ptional and should be described that way.
M4.5 "Class Descr Len=85length = of the Traffic Class Description field"   Length in w= hat units?
##svshah, addressed

M4.6 [minor] "Traffic Class Description"  A reference for UTF-8 (rfc3629 I believe) would b= e nice.
##svshah, addressed


M4.7 "Elements (Classifi= er) Count=85value zero (0x00) means=85tra= ffic class is to classify rest of the traffic not captured othe= rwise by other traffic classes=85REC= OMMENDED that Traffic Class that has 0 elements is present last=85If an= advertised message has it positioned somewhere else, then the = receiver MUST re-order it=85"   This text (as is) implies that the 0x00 classifier SHOULD be presen= t last =97 is that what you meant, for it to always be present? &= nbsp;If so, why not use MUST and eliminate the reordering logic?  Or w= as the intent that if p= resent then it should go last?
##svshah, the text intends to imply a cla= ss with no elements (not classifier 0x00). Agree with your suggestion,= we can use MUST and eliminate reordering logic.


M4.8 Classifier Element TLVs:=
M4.8.1 The description talks about &= quot;Classifier Element TLVs"= , but Figure 4 calls them "Tr= affic Class Elements (TLVs)".  Please be consistent.
M4.8.2 "Size of Value field=85length of the value field." &n= bsp; Length in octets, bytes, bits, ???
##svshah, addressed

M4.8.3 [T2] "Value=85It is an error if the IPFix field does not c= ontain the appropriate format"  This statement gets into interpre= tation of the contents of the attribute.  If the purpose of this docum= ent is to just transport information, then why would it be a function of BGP to figure out if the contents are correct?  Plea= se be clear about whether the BGP Speaker or SLA_Consumer should perform a = function.

M4.8.4 "If a receiver receives a BGP UPDATE message with QoS= /SLA attribute for an NLRI that it does not support then the receiver = MUST NOT install that advertised SLA and continue to forward this attr= ibute as an optional transitive attribute."  What does "an NLRI that it does not= support" mean?  Are you talking about an NLRI from a specif= ic unsupported AFI/SAFI, or ??  
##svshah, yes, it was already qualified i= n the statement before, and so AFI/SAFI was not repeated. Re-worded ap= propriately.


M4.9 Traffic Class Service TLVs: 
M4.9.1 The units for the length are (agai= n!) not specified.  I realize that it may be in bits (given the next c= ouple of paragraphs), but the reader shouldn't have to guess.
M4.9.2 As long as you're thinking ab= out the length, please check all the length descriptions =97 I th= ink most of them are missing the units, but this is getting tedious<= font face=3D"Calibri,sans-serif">=85
##svshah, It is specified explicitly= . The size of the length field is specified as 8-bits and what size of= the value field should and expressed in what is described for each service= -type. Currently, list of service-types and related size of fields is repeated twice at two different places. I=92= ve modified content to keep it only at one place, that way all relevant det= ails at one place.


M4.9.3 Please note that the length of the value fields is not described con= sistently.  For example, it says that TRAFFIC_CLASS_TSPEC is 96 b= its, but 3.3.2.3 talks about octets for MINRATE_IN_PROFILE_MARKING. &n= bsp;
##svshah, addressed

M4.9.4 "Value=85It is an error if this field does not contain the appropriate format (see BGP error handling section=85."   Not only is this error appropriate for the SLA_Consumer, but the "appropriate format" is not clearl= y identified in the description of all the TLVs.


M5 [T1] Section 3.3.1. (Supported IPFIX values for Classifier Elements)

M5.1 [minor] The correct link to the IPFIX Registry is ht= tps://www.ietf.org/assignments/ipfix/ipfix.xml#ipfix-information-elements

M5.2 "Only the IPFIX attribut= es listed in Table 1 are supported by BGP SLA exchange."  Why?  If this document is just about c= arrying a new attribute that is opaque to BGP itself and that may or may not result in an action at the receiver (see above), then why n= ot support any IPFIX element?  Maybe not all of the elements make sens= e, but some surely seem to =97 ipClassOfService, for example.
##svshah, we already have dot1q prio= rity covered as well diffserv and mpls-exp . Diffserv alread= y has a support for CS0..CS7 and thus need of ToS is redundant and not need= ed. ipClassOfService thus is not required given those 3 fields covered.


M5.3 "Any new attribute to be= supported by SLA QOS MUST be added = by a Standards Action."  To be added where?  The IPFIX regis= try has a different registration procedure (Expert Review) -- are you referring to adding elements there?  Or adding elements = (already in the IPFIX registry) to= Table 1?  Or ??
##svshah, yes in Table 1. It is ment= ioned in the IANA Consideration section.


M6 [T1] [T3] Section 3.3.2.1. (Traffic Class TSPEC TLV) The value of t= his TLV "consists of the (r), (b), (p) parameters as descr= ibed in Invocation Information section of [RFC2212]=85".  However, the definition in the document is not the same as the one i= n rfc2212.  For example, this document defined r as "measured in = octets of Layer 2 (L2) datagrams per second", while rfc2212 says = that it is "measured in bytes of IP datagrams per second".  If the intent is to (as stated in the document) use the definitions = from rfc2212, then don't redefine the terms.
##svshah, The suggestion from tsvwg durin= g review was to use RFC2212 TSPEC for the purpose of rate specificatio= n. However, specification of those parameters need to be in L2 datagram siz= e for the purpose of this specification unlike IP datagram size in RFC2212. What is a recommendation?



M7 [T1] [T2] [T3] Section 3.3.2= .2. (Traffic Class L2 Overhead): 

M7.1 [T3] Section 3.3.2.2. (Traffic = Class L2 Overhead)  How is the L2 overhead defined?
##svshah, added clearer definition o= f L2 overhead

M7.2 [T1] [T2] "When the= receiver chooses to react to an advertised SLA and if the L2 Overhead= service type is present in advertised SLA, the receiver MUST use the = explicit advertised L2 overhead rather than the local L2 overhead."  In the context of this docu= ment, where the use of the SLA is out of  scope, what does "react= to an SLA" mean?   IOW, we can't mandate what the receiver does,= or how it does it if outside the scope.
##svshah, The intention of this statement is to define semantics of th= e field and what it means to the receiver from semantics point of view. The= purpose of this statement is to mandate on a receiver on how to interpret = it. Nothing beyond that.


M7.3 [T1] "If SLA is required to consider only IP packet size, th= e sender MAY advertise this service with a value of 0."  Again, t= he reason is out of scope.  The ability to advertise a value of 0 is n= ot.
##svshah, reworded to define only semantics of the field. Though just re-it= erate, use-case and intention why we need to advertise SLA is clearly highl= ighted. What is not in the scope of this specification is standardizing any= policy and how to implement any policy on received SLA.


M8. [T1] Section 3.3.2.7. (Precedence between MINRATE and MAXRATE) &nb= sp;Back to the data being opaque..why is this section included in the docum= ent?
##svshah, This is important from the perspective of defining clear semantic= s of advertised fields. So that it does not remain vague even from the view= point of advertiser.


M9. [T3] Section 3.3.2.9. (Traffic Class for Relative Priority)  "= ;Length =3D 4 bits"  Unlike all the other length issues I've= pointed at, this time you seem to be indicating the length of the Val= ue field.  Does this mean that the Length field in they TLV shoul= d be set to 4 (as in "the length of the Value field in bits"), or = that the Length field should not even be present because it is always 4 bit= s, or something else??
##svshah, yes the length field in the TLV to be set to 4. Since length of t= he value, for each service type, is clearly highlighted in earlier section = it is not repeated here again. I=92ve collapsed content from both the place= s to one now to make it clearer for the reading, as well addressed any consistency issues.


M10 Section 4.1.2. (SLA Advertisement for Destination AS Multip= le Hops Away) "If a new prefix is added in an AS for which SLA = parameters have already been advertised before for other existing prefixes, and if traffic to this new prefix is subject= to the same SLA advertised earlier, then the BGP UPDATE for this new = prefix may include QoS attribute con= taining just an SLA id=85"

M10.1 Is this behavior also valid for directly connected peers?
##svshah, Semantically yes it is. 

M10.2 The description above assumes that the receiver has the SLA desc= ription from a previous UPDATE.  See my comments above about Section 3= .2. 
##svshah, the description highlights to advertise whole SLA content if it i= s first time advertised to a set of recipients, or else advertising just SL= A ID is sufficient for the subsequent additional prefixes for the same reci= pients.



M11. [T2] Section 5.1. (BGP Node Capable of Processing QoS Attribute)=   

M11.1 Back to the opaqueness of the attri= bute from the BGP point of view and how the use of the information is out o= f scope.  What does "processing" mean in this context?  = ;I think you will need to separate the processing done by the BGP Speaker from what the SLA_Consumer should do.
##svshah,  I would have thought that processing of any content o= f an attribute (either QoS or any other attribute), is always attribute owner=92s responsibility. I can see your point though that places with grey area needs explicit clarification= . Let me re-work content to separate the processing done by BGP Speaker fro= m that to be of QoS attribute.



M11.2 "If UPDATE has a QoS Attribute with a list of destination ASe= s, it MAY trim the list and adjust the count of the destination AS to exclude ones that are not required in further announcement of= BGP UPDATE messages."  Just to make sure I'm looking at thi= s from the right place: this text applies to a BGP speaker that received the QoS attribute from someone else and is now getting ready= to propagate it, right?  If so, isn't changing the list of destination ASes basically an atta= ck on the intent of the origin?
##svshah, would that not be true for any = attributes supported today? It is clarified though in the Security consider= ation section.


M11.3 "BGP peer = MUST drop SLA related sub-type from the QoS attribute, if there are no= more ASes from the QoS Attribute's destination list in the forwarding= path.  The rest of the QoS attribute contents MAY be Forwarded=85=94
M11.3.1 What is the "forwarding path= "?  I'm guessing that means something like: if the AS is not conn= ected to any other AS on the list (except the one it just received the= UPDATE from)=85 What is it and how can the ingress BGP speaker in the AS figure it out?
##svshah, yet to respond


M11.3.2 [minor] Please be consistent with= the naming.  I'm assuming that "SLA related sub-type" is really the SLA sub-type value 0x01=85  Even though they are not defined yet, other sub-types may also refer to SLAs.
##svshah, correct

M11.3.3 The "MAY" above is norm= ative in a "forward" manner: affects potential future SubTypes. &= nbsp;If new SubTypes are defined l= ater, let them define the behavior.  s/MAY/may
##svshah, addressed

M11.3.4 [minor] Note that this whole para= graph is repetitive, please simplify it.
##svshah, I think you may be referring to= beginning of the paragraph referring to dropping of SLA subtype from the Q= oS attribute and remaining of the paragraph referring to dropping entire Qo= S attribute. Both of them are separate functions and thus need to specify both. Or did you mean to point somethin= g else?



M12. [T1] [T2] [T3] Section <= font face=3D"Calibri,sans-serif">5.2. (SLA Attribute Handling at Receiver) =  

M12.1 "Reception of and processing of advertised QoS SLA content are&n= bsp;optional for the receiver.&quo= t;  What do you mean that "reception" is optional?  Wha= t is "processing"?  Given that the use of the SLA is outside = the scope, I can only guess that "processing" means at least= parsing the contents (not actually doing anything with them).  If so,= what do you mean by saying that "processing" is optional? &= nbsp; In general, if an attribute is sent inside an UPDATE it then has to be "received&= quot; (unless all the NLRI contents are filtered by policy) and "proce= ssed".  This part sounds like it belongs with the SLA_Consumer.
##svshah, ok

M12.2 "the receiving BGP peer= SHOULD invalidate previous advertised SLA parameters if one exists fo= r the same SLA id and source AS." &n= bsp;I think you really want the SLA_Consumer (not the BGP peer).
##svshah, ok

  What does "invalidate&qu= ot; mean in this context?  Maybe replace or an indication what the new= version, etc.  
##svshah, =93invalidate=94 here mean= s remove earlier advertised SLA content and context


M12.3 "If the new advertised SLA has= a non-zero traffic count=85"  "traffic count" is not d= efined anywhere in the document=85  I guess you mean the "Traffic= Class count" -- please be clear and specific.
##svshah, yeah its typo. The very ne= xt sentence is referred with Traffic Class count

M12.4 "=85then the new a= dvertised SLA SHOULD be installed"   Installed?  This sounds= like you're specifying what to do with the SLA specification=85outside the scope!   Even for the SLA_Consumer=85

M12.5 "When BGP UPDATE messages are triggered only as a result of SLA = policy change=85the receiver MAY implement a policy to filter such messages= based on the prefix and attribute."  I appreciate the intent, bu= t what about changes in other attributes?
##svshah, This is purely administrative. What this suggest is that if admin= istratively known that SLAs advertised from specific AS (or group of AS) &n= bsp;are only as a result of SLA policy change and thus BGP UPDATE messages,= containing QOS attribute with SLA SubType, only means such. In this case BGP UPDATE messages are not expected to carr= y any other useful information or any other attributes besides QoS attribut= e with SLA subType. In this case a policy can filter for relevant prefixes = and QoS attribute to drop such messages.


  IOW, the receiver doesn't know that the change was only due to = an SLA policy change (which from the BGP point of view may be better called= something like "an update in the QoS attribute").  Please c= larify that if the filter is put in place, all the other attributes need to be checked as well.  BTW, I think that the "M= AY" should be "may", but that is minor.

M12.6 "=85the receiver MAY implement= advertised SLA for the whole link=85"  This is an indication of = what to do with the SLA=85out of scope!

M12.7 "=85QoS attribute with th= e SLA=85"  To be complete, I think you mean "with the SLA Su= bType field=94.
##svshah, will address

M12.8 "=85then receiver may establis= h advertised SLA for that specific prefix list under the relevant link.&quo= t;  Even thought not in a normative way, this text also talks about th= e use of the SLA=85out of scope!

M12.9 "It is completely up to the re= ceiver to decide for which prefixes it should accept advertised SLA and for= which ones it will not accept."  Which receiver?  I'm guess= ing the SLA_Consumer, because the BGP speaker has no choice but to accept any attribute=85  Are you implying here that the BGP sp= eaker should be able to selectively filter QoS Attributes?
##svshah, will rephrase to make it cleare= r and with BGP speaker vs QoS attribute processing



M13. Section 6. (Error Handling)  

M13.1 [T2] What is an "error condition"?  I counted 4 places= where an error was explicitly identified =97 surely there are more cases t= hat would result in an "error condition".  I'm assuming that= a malformed attribute (as in the length not matching) is an obvious one (no need to explicitly call that out, but maybe a reference to the gen= eral attribute processing in rfc4271 would be good)=85
##svshah, I understand reference to rfc7606 would imply reference to rfc427= 1?


but what about if the Source AS is set to 0 and the Destination AS count is= not 0, is that an error?
##svshah, that is not an error as per current specification that suggests t= hat when source AS is 0, ignore destination AS count and list.


M13.2 [T2] OTOH, errors on general attribute format checking (do the length= s/counts match, etc.) is where attribute-discard applies for the BGP Speake= r=85other errors (including some of the ones explicitly identified in the t= ext) may be more in the domain of the SLA_Consumer.  Note that even though the SLA_Consumer may decide = to not use the SLA (which is equivalent to attribute discard), I think= some of the checking (formatting of the values, for example) doesn't belon= g to the BGP Speaker.
##svshah, sure, that was the thought process that in general for any attrib= ute specific processing and error handling belongs to attribute owner. It m= ay just so happen that most of the attributes are inherently part of BGP sp= ecification and thus may not be need for explicit about such separation. I=92ll address making it appropri= ately clear in the specification.

M13.3 [nit] s/attribute-discard/attribute discard
##svshah, addressed



M14. Section 7. (Traffic = Class Mapping)  What is done with the SLA is out of scope!  The m= apping, or not, of policies is also out of scope =97 specially th= e normative language included in the section.  Recommendation: delete this section completely.
##svshah,  that may be fine. Th= is may serve as a guidance though for implementations that may choose to im= plement a policy on received SLA. While we remove this section, shall = we keep couple of sentences some-where on such?


M15. Section 11. (Securi= ty Considerations)

M15.1 "T= he QOS attribute defined in this document SHOULD be used by the managed networks for enforcing Quality of Service policies=85"  The use = of SLA information is out of scope!
##svshah, removed =93enforcing Quali= ty of Service policies=94.

M15.2 "= =85so there should not be any risks for identity thefts."  What does that mean?  Identity theft?  = Are you talking about the possibility of hijacking?  (I'm just gu= essing because the next sentence talks about Origin Validation.)
##svshah, some-one advertising SLA pretending to be specific source AS= , and yeah thus Origin Validation.


M15.3 "T= o strengthen the security for the QoS attribute, RPKI based origin validation [RFC7115] MAY be = used."  How does Origin = Validation strengthen the security of the QoS attribute?  Origin Valid= ation can help the receiver verify that the origin AS is in fact authorized to advertise an NLRI, 
##svshah, yes, that is what it intends to achieve.

but not that the valid prefix origin did in fact also originate t= he QoS attribute.  Section 4. (Originating SLA Notification) does say that  the "QoS attribute=85MUST NOT&nb= sp;be added during BGP propagation", but there doesn't seem to = be a way to detect non-compliance making it an important security considera= tion.
##svshah, yet to look at it and respond accordingly..

M15.4 "=85BGP Path Valid= ation (e.g., [I-D.ietf-sidr-bgpsec-protocol]) procedures could be used over BGP QoS attribute and its associated prefix in producing the digital signatur= e that can be carried within = the signature SLA for the messages."  What is the "signature SLA"?  This text is proposing to change BGPS= ec =97 as is, this proposal presents no assurances over the *curr= ent* risk of a MITM (until maybe someday the proposal is specified and impl= emented).  I would rather you clearly identify why there is a risk of MITM =97 and then say that there is no solution (which= is the same as for other transitive attributes).
##svshah, ok

M15.5 Speaking of MITM, what about privacy?  Even if the MITM doe= sn't change the QoS attribute it can still glean a lot of useful informatio= n from just forwarding the UPDATES.  Please include some text about priv= acy.  Please take a look at RFC6973.
##svshah, ok



M16. [T3] Section 10. (IAN= A Considerations)

M16.1 There is no guidance about the = ;QoS Attr flags.  I know they= are not used in this document, but because it is the document that defines= them it would be good to have a registration criteria.
##svshah,= since there is no usage of any bits today and we have this in anticipation= of possible future usage but since there is no awareness of an= y possible future usage, we thought it may not be something useful to track it as IANA registry yet. Do you think sha= ll we still have it?


M16.2 [minor] I know the space is sm= all, but the SubTypes and SLA Event Types have a registration procedure of = Standards Action.  I wonder if having a value (maybe just one) fo= r Private Use could be beneficial to allow people to put their own stuff in there= =85
##svshah, it is a great suggestion. that indeed can be very useful. address= ed.

M16.3 [minor] This sentence seems out of place since it provides no guidanc= e to IANA: "QoS SLA Traffic Class Element Types will be referring to e= xisting IPFIX IANA types as listed in Table 1.=94
##svshah, should I keep it here though for completeness to the reader?




Minor:

m1. [T1] The Introduction talks about the fact that other "protocols a= nd data models are being created to standardize setting routing configurati= on parameters within networks.  YANG data models=85the I2RS protocol&q= uot;, but that "some providers desire to exchange QoS parameters in-band utilizing BGP peering relationships."  Tw= o related questions:

m1.1 Is there specific YANG/i2rs work in process that matches what is defin= ed here?  How are the models similar/different?  Note that this i= s not a question about comparing the use of YANG models, the i2rs protocol = and the mechanism using BGP  -- I just want to know if there are other similar efforts in progress and how they are in= sync or not.  The underlying question is really about whether an oper= ator will be able to use a NETCONF/i2rs to configure the SLA information re= ceived in a BGP session (as specified in this document).  I know that anything is possible, but is that the= direction that is being taken today?
##svshah, QoS Yang Data Model is quite early in works which is submitted as= individual draft as of now in the netmod wg. Though currently they seem to= be aligned, it is quite early to say (I=92ve been involved in the QoS Yang= Data Model review). Though, the statement here regarding yang/i2rs work was added specifically as a result of review= comment from the wg on this draft.

m1.2 Are there implementations?  It would be nice to add a section ala= rfc6982 and point to the idr wiki from there.
##svshah, I am not aware of any implementation of Yang models.


m2. [T3] The new attribute is called by several different names in the docu= ment: "QoS Attribute", "QoS/SLA Attribute", "QoS B= GP attribute", and simply "attribute" in a couple of cases. =  Please be consistent!!!
##svshah, addressed


m3.  Section 3.3.2.3. (Traffic = Class for MINRATE_IN_PROFILE_MARKING)  I'm not sure how to interpret t= his:  "Marking code-point type =3D 8 bits (1 octet) IPFIX = Element Identifier=85The marking code-point type of 0x00 is a drop identifier; the length in this case is zero."   IPFIX has = Element ID 0 as reserved.  I'm guessing that you mean that if the code= -point is 0x00, to better yet, if the length is 0, then drop.   ???
##svshah, it should read =93marking = code-point value in this case has no meaning and thus the value in thi= s filed should be ignore=94.

m3.1 Same comment for 3.3.2.4, 3.3.2.5 an= d 3.3.2.6
##svshah, addressed


m4. For all the sub-sections in 3.3.2, pl= ease put in a short explanation of what each TLV represents.
##svshah, ok


m5. Section 8. (Deployment Considerations)  I think this section should really be called "Use = Cases" and moved earlier in the document, maybe even as part of the Introduction.  It would be very nice if the case for p= ropagating the QoS Attribute through multiple AS hops was also illustr= ated.
##svshah, yet to be addre= ssed.


m6. References

m6.1 RFC3270 should be Informative=
m6.2 If RFC7115 is referenced as Normative, then so should <= font face=3D"Calibri,sans-serif">I-D.ietf-sidr-bgpsec-protocol because you'= re offering them as solutions to security issues.  Please take a look at my comments on the Security Considerations Sec= tion above.
##svshah, addressed

m6.3 For the illustration in the document= , I don't think the reference to RFC7674 is needed.
##sv= shah, it has been referred in the Introduction. That is why added in the reference.




Nits:

n1. s/=85and then optionally = followed by for the oppos= ite direction/=85and then optional= ly followed by the specification for the opposite direction
n2. Please expand on first use: TSpe= c
##svshah, addressed

n3. In 3.3.2.3, please be= explicit that the Value contains the Marking code-point type and value.

n4. In 4.1, "next hop to CE (that is the next hop address from CE to = PE)"=85shouldn't that be "next hop to PE=94? 
##svshah, removed =93next hop to CE=94 and used wording from the parenthese= s.


--_000_D3940AC51A281svshahciscocom_-- From nobody Sun Jun 26 16:39:12 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE0112D0D1; Sun, 26 Jun 2016 16:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLF2gpJxJ5H8; Sun, 26 Jun 2016 16:39:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A4B12D1A5; Sun, 26 Jun 2016 16:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3659; q=dns/txt; s=iport; t=1466984348; x=1468193948; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t6LCCN2701xtcnftfx0AzSy/TvvhYHLFlim9k65hJQw=; b=J8R6VaOHJJZKJcaS+RcMS8oVLmnkptagK/CLguKTBpzbE7q8uZFrtjer 45Q3qEcXpHSck5d9sTaIBiCy1irPKv2TB0CRwZCSdb9rawM7fuxyfIhr9 U6lzUgnz8CEuDGinvGxlD3ciE4oNG8XG1BpM8FjIo4thL9KI+CCSWJJpz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQCwZnBX/5ldJa1bgz5WfQa6KIF7F?= =?us-ascii?q?wuFdgKBJjgUAQEBAQEBAWUnhEwBAQEEAQEBNzQLDAQCAQgRAwEBAQEeCQcnCxQ?= =?us-ascii?q?JCAIEAQ0FCIgoDscrAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKIRNihsFmQEBj?= =?us-ascii?q?i+BcIRUiGePfgEeNoNwbohZfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,534,1459814400"; d="scan'208";a="117469328" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2016 23:39:07 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5QNd6GT015599 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 26 Jun 2016 23:39:07 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 26 Jun 2016 18:39:06 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Sun, 26 Jun 2016 18:39:06 -0500 From: "Jakob Heitz (jheitz)" To: "Enke Chen (enkechen)" , "John G. Scudder" Thread-Topic: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 Thread-Index: AQHRzmgGBv3fZ5fA9ES7A4n0pFWtDZ/8Z5yQ Date: Sun, 26 Jun 2016 23:39:06 +0000 Message-ID: <56a07f338f5d4a1f8dfd539040b1002e@XCH-ALN-014.cisco.com> References: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.91.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Bocci, Matthew \(Nokia - GB\)" , "idr@ietf.org" , Susan Hares , "draft-ietf-idr-ext-opt-param@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2016 23:39:11 -0000 How about: "An optional parameter with parameter type of 0xFF MUST NOT appear in the list of optional parameters other than in first place and if it does appear= , then the optional parameters length MUST be 0xFF." There is really no reason to entertain other combinations and I don't want to have to write code to handle them. Thanks, jakob. > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen (enkechen) > Sent: Friday, June 24, 2016 3:29 PM > To: John G. Scudder > Cc: idr@ietf.org; rtg-dir@ietf.org; draft-ietf-idr-ext-opt-param@ietf.org= ; Bocci, Matthew (Nokia - GB) > ; Susan Hares > Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-op= t-param-04 >=20 > Hi, John: >=20 > Please see below. >=20 > On 6/24/16 11:43 AM, John G. Scudder wrote: > > Hi Matthew and all, > > > > Thanks for the review. Some comments below. > > > >> From: "Bocci, Matthew (Nokia - GB)" > >> Date: 6/21/2016 6:10 AM (GMT-05:00) > >> To: idr@ietf.org, Susan Hares , jgs@juniper.net, rtg-= dir@ietf.org, draft-ietf-idr-ext-opt- > param@ietf.org > >> Subject: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt= -param-04 > > ... > > > >> Minor Issues: > >> > >> > >> > >> 1) Section 2, Protocol Extensions. > >> > >> You have labelled the existing Length and Type fields as 0xFF. I assum= e the meaning of the second is still 'Type' > since that is > >> > >> what any implementation would reasonably interpret it as, and that is = the registry you are using a code point > from. So it > >> > >> might be better to say in the text above the figure at the top of page= 3 that the length and type fields in > [RFC4271] > >> > >> are set to 0xFF. > > > > Is your proposal to use the diagram verbatim from 4271, but say in the = prose that the type and length are 0xFF? > I'm fine with whatever seems clearer to folks. > > > >> Also, you don't explicitly define what a receiver should do with the l= ength field if the type is 0xFF. Does it > ignore it, > >> > >> or does it check that it is 0xFF and treat the OPEN message as malform= ed if it is < 0xFF? > > > > This is a good question, and TBH I don't recall why we specified a valu= e for the legacy length field instead of > simply saying it should be ignored. > > Maybe Enke remembers? Right now I'm inclined to say it should be ignore= d on receipt, but I'm open to discussion. I > guess even if we make that change we can still spec it be sent as 0xFF, f= or purposes of debuggability, but this is > not a big deal. > > >=20 > Here is what RFC 4271 says about the "Optional Parameters Length": >=20 > This 1-octet unsigned integer indicates the total length of the > Optional Parameters field in octets. If the value of this > field is zero, no Optional Parameters are present. >=20 > If the "Optional Parameters Length" field is 0, then the Optional Paramet= ers > will not be parsed and thus the new length field would not be reached. >=20 > I am not sure, but that might be the reason that we have it as 0xFF. >=20 > It needs to be at least 1 for the "Parm. Type" field to be parsed. Once = the > "Parm. type" is parsed, and if its value is 0xFF, then the two-octet leng= th > field follows. The procedure is more than just "ignoring" the field. >=20 > Thanks. -- Enke >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jun 27 08:51:29 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7060212B017; Mon, 27 Jun 2016 08:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwStnFFuH4Mh; Mon, 27 Jun 2016 08:51:26 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A01B12D76D; Mon, 27 Jun 2016 08:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/wWOEVWjDVTyQEe00D7xHCEtvir9k9lXnP1q3fmTpgc=; b=aqTMjymrJ8/6tTgtT5MmwT3yTlz9RM3nRmDW0ImrJKj9ACbaVOqRGSBhxPJ5n/SxlWBh63YEa7YiEmIXDld35IUIHpUWQnXpX4FtbIboXEMXLgpb9lGAAKc/Y1dQF8dk3f0Q47db+05sEIfUrrcb5P4mwHCAxXHfBCaXH5M05fQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from plangevin-sslvpn-nc.jnpr.net (66.129.241.13) by BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) with Microsoft SMTP Server (TLS) id 15.1.517.8; Mon, 27 Jun 2016 15:49:57 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> Date: Mon, 27 Jun 2016 11:49:51 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <4D4E66C2-602E-4DFD-A7DD-8FC47DD0F816@juniper.net> References: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> To: "Bocci, Matthew (Nokia - GB)" , X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BLUPR0601CA0014.namprd06.prod.outlook.com (10.163.210.24) To BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) X-MS-Office365-Filtering-Correlation-Id: 33014251-21c0-405e-0569-08d39ea2b10e X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 2:pU38A+mu9FvO/Y3moXWN6VmiI0OiJLx2wLatnXtfBn+6r7HXIcioBGKVvZKB4lUxTsRcgx17rpmWdHLAYasLKvsiaGL+Zcpk7LH80JghNx3lTG44ngRsLZkJV1ceLdxgJUauKCop75Tul3vBjN1ndh+ntszxxDf6WSEf39w4mfTbpjZ95dfiQ+VDf3J3iIP1; 3:Q+nl+Plj9fBfaF91L53Sjz+Kt0v5F2BuxSZCnuSOBOq9KkaqF6T8D+DiJOY7K/hxJLBW1gfbYkisAYZnfSUiMfBwRIpzTGLiRcYhFWpNPh24+UE/6VmCBsNENpsbdxHU; 25:AgbHYPWzhR4f5gIcBKIspKNWfYG8dJmDI50H5bjw2Kidn+Xpf0Uc+ZK6eDrbYbncqFgotu0etChy7JZUd8pnVIzqcMIUwXXfM1FRZDIObuFH158kD3cipV/E2N6rq8RnlnXDz5d8kS+lQNXWTDXEiMVZQU2QLBXiMVr1Usc11fkWVfgcSmr2Nahx/M69Bl1Kx0pcriwvu1AgI1EHx2VNwzzuEI/OI02uqtRH9jmYz+ALci5RTj1vbYBFMgZ7aXGrlYkvTY/98F4ltq53hnZFRF+WTtRW0WxQt9US/U+3e7QM6GIT6KKHSLlQshqKd5SzOaIIZRniP4vaoHnPqLZ7nL0vgp+Cse/81Ac243VMTbkPvfuFN4etrw6WIVNFsMXZDYEt9s1DOmSjTmwSV/JVIu5Rm0lMgojW3D7Ed3DPxL0= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2500; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 20:0RidFES3o4bf1WyyqD4o2nh/heaYttGvzYHLXvoGvHnMHZtax1LTQDYvPL7wQSKNWIm+SosIp+Gl2c8Ft1Q595r655Z0RayBdvQvZvWpIqYTQwNOjCx151Tffam3q+zurOsse3fFXg9U1TRERPi3EIeAVzS+Nq1xFLSKgK1oVjAKmxw8aLgayPeShUztrgbwiC18ggsGen03gmU/30uu6QWfdvrTYuMmT3DLT7XzdpNlK78mafanKpdwDsZ8J6AhzpLOKqCKu/9Ekb4QhyTpG32GvyMwiQsNgXp81C33NibdM9TP5RpjTlhdEyCIipZvqztVAT3TmK++SImkO4jmPIFHNuFYYsnNCcVRKYfN2ulh7Tr0StwLcQ0/CR5HFoe9gPeRbX45DMfuAzLPURGoIVAUYPWa5isGQX/UacBxy40cHI+JxpFfPNjVX5WpiXM41L9TTaKGB4pK6/GrA8n5/ffywzdF6yDmE/hfMT/gizPeqPZRJIv84TpTl6w95IHn; 4:l37N+gj2CMsA4U34CRpRcX9eLeoqzjaoBE11k27bSJaItQ4vylNq6rBxxQ9P0eYK7RT57DafBOHs3CXmdkYNXb7nsrcAX686o83050o+9ID7kbnBtfwSlmB+zlM89r5sIb5SbjnDG7ObG2icrLFN7gXTUzFja/dYeOnJKOSUzbCAQDNXDuc4qr7ZBqi0jsmALOw57VKsc3E6PIxar8al9o/qxH2pBxF5BEGS47AyZuSUrbraP7wmwIHUqBoWxZ0Q8Tf4glZcalGGKyfuSfr+SSiZql1y1SHBY0t8p0U6bnJ63URglAa23vNYEydrp383Vnmm9NUN6xejx7vMOGVcuEfCzsMjRzy48Sd9Z1Rn80VH8eUiZSnMPCIVq0n7lkWNcrdKyLSspP6s5ZcAAMpm7x6mOM+mJU9dhhAAtjTioEn2lUF7oSP9l/7xezPNqKWV X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR05MB2500; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2500; X-Forefront-PRVS: 09860C2161 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(377454003)(189002)(24454002)(199003)(36756003)(76176999)(47776003)(50986999)(57306001)(33656002)(46406003)(50466002)(101416001)(7846002)(7736002)(2950100001)(68736007)(2906002)(50226002)(230783001)(86362001)(561944003)(81166006)(81156014)(305945005)(4326007)(6116002)(23726003)(8746002)(92566002)(77096005)(42186005)(19580405001)(19580395003)(82746002)(69596002)(53416004)(83716003)(3846002)(97736004)(106356001)(189998001)(105586002)(5001770100001)(586003)(66066001)(97756001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2500; H:plangevin-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2500; 23:fxOLUiunr+I8El89reaUL0NSc20sSt4rVQoFEgjRo?= =?us-ascii?Q?baCg00MPkJc5IKutKPBeEn1vqn6IdzQw9Y40crp7cJSQlPaiU50on6Ayt6UQ?= =?us-ascii?Q?hMgkTmTnb4FMckSTajqFpUZM6BqAv83du5UZEnyXmTD1Hmhep/adYSyR3H6l?= =?us-ascii?Q?TNdt9L1cT4kfQkShQs+pOabv+jLU2ujcK5/RcK3v6kDUuWRegjTib3PX/SYs?= =?us-ascii?Q?jtbmfYgkwi/Yf8jf6aZBK1W1JBZn4yz8LPTNsqRjAVjU15YIg2VLUoMrwu/q?= =?us-ascii?Q?FlRqgI4L13/UeVN9IqLRnTMkyeWm7iiKPXOPO9EbYzQgHwzbh5w5A5k0llxy?= =?us-ascii?Q?quEl3UK6QiHts4nPStXaEOhhQC1gQCiDfXJTiMOLDrRvVGCoFZaZlxheWhd1?= =?us-ascii?Q?tfVMsYPLIh/4H019V8SBz8fMhKIfdftSXCNbBvXwU3ueNsCNPdsNm6IHhhs/?= =?us-ascii?Q?cipZHxDMYnGD8vLLZiUOZ5Jfpe+YygaCfmySQal4LP4MTkGdYYuttD6rQQzu?= =?us-ascii?Q?OGWD7a+E2utA2OsFVGAfeuqJgIZVZqeaXFKr+1n23PwgIZiSKAQvHd+O9YkB?= =?us-ascii?Q?uVUndRVV7SgOzsBaFZJSUcBCpMFaiU16XcE/uK3nrQvLyHHvYH+jUqxiBcuQ?= =?us-ascii?Q?ymine8c9qCiFfAniJnCpVJgZZ3llVir9j93bqds/ZJFZqvfCAHFqLT+psPy2?= =?us-ascii?Q?FdRtkL9ecFZU+rBF+H8dmmRL3TIVNuVBLWpqLJR8R8rzmRtghhvEzBc0TWHp?= =?us-ascii?Q?i7QcLC1929vT8LOmRgPwRIcattDL5Co/oHqO843Sskkw4jx949l7SnVOo5dR?= =?us-ascii?Q?nXFaMlgAn84muMJ6IKBndnjx9iTl2c15MJQfs2GGQz5J2d2CaVb7VM0sMDHM?= =?us-ascii?Q?wAb9FWonwHDtuIDJbSPpJXYkJP9z0YVKQkdoaQkCw48VXYNZbPe2d7EC3PU9?= =?us-ascii?Q?9nO5lZOECUo6k1HDqd51VWoHhALgpMQzKKTMVjGyMXpWpIzepVHXGndMjI/Q?= =?us-ascii?Q?Tp/F4eyx67zihE+iyS9IPYsst5hhgphG/p9zYyCnueNqpIC3chSH0rHGP2IU?= =?us-ascii?Q?0Ms9fn7T+w/32VmCMFNPOPU7ZV9USPNMS5I7vvGXfbY/i206IjmCBD+TigdW?= =?us-ascii?Q?/FpkPjs5aUxgHQEy0olIntVTLZi3vcfCHTEaV7I5UV46VcC2O1F27zGW0ZRz?= =?us-ascii?Q?5v3zdGtEWdFK3uvkzlvkTDMFlMe53vojFdmrqWFwzidS8eSMoBcG/bynGsrp?= =?us-ascii?Q?AnZxtPjbRsWIZcdvj7oqtrPjIzZim1irCTJ1QKwQG1NKFIhk+VAhnyqGpwfa?= =?us-ascii?B?dz09?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 6:pD5KHexkJ8zYWhjVTfrza+tnj4+Q8yEzfl/jgraBC/CXsUbQtpEUT/EkPuihX+dr30R7fZgOPmPkn0ZLv1mtE/GNmdFJhVVawZrpnd5k+J6VSxWpzgXbFfNb3pistQrWizN3ySdh+Mu49Ck70XQUjLI+cNpd5zQl6cTj53fP9yCGYkZ8MGMhcHtwEQGbTfnzyiZ/SAkc4Pelck+5I25ufeXDex032RL10n5vVLg0IWXEctRsvuRI7dnumsfuLyCz3C/WYMBl0kvGN+F+kBJ6DAi5c3scxk6ogOvecXdhMLfbo8AfugO7pRl2cmDLXgJgTHQ7Ow7CC8Qhom2DTgECZG141gpAA3mmFt+djpe1eMY=; 5:7MCG/MlxiACMhaF3r2IhX5PmvoamjrSu+gRmmfBpGWwt3dyOoCL4KfaCLBx4pADW2IO824xSy1icfQrE6PMDexOcS2w813IM2Babt3fIPRKhtybHFw0W/gPqL6Vj4gywSlcs1gaq7+5OjothwwNCNA==; 24:H6NN37zjyt2iIDCaJYgGpeyx4vt+WxTyIJ8xizIfGrEEeJMSWkKXbmNrLm5KIkvmDuBWx2g7xI/TLQfgYY1dG0PGWu1sXvfWYyDfOiVemyg=; 7:kD2S8oe/bDwsQgjqICKVrKXmgM19pBoWIfHrcrGwTwXPpIy1pAeCMJmjlWxA+NDJ/hdLvCnII6BAgPbBnCXGk6qo+UQAAl1u/lrLts69XY6JKNkdjPDo798dWQ0yPba9N1OxyL5j1irEeCmN8OA/J26LLEZjhgHw0ScFArFRCzLGRndVjwb4aVK2hGaZmzA/4mIHFW1M9AIhkbabyQ0PY62A7G6VszEflBVkxUxrjJ5GvWrNCGYzwrhR66O0Klqx SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2016 15:49:57.5353 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2500 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-ext-opt-param@ietf.org" , Susan Hares , "rtg-dir@ietf.org" Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 15:51:28 -0000 On Jun 24, 2016, at 2:43 PM, John G. Scudder wrote: >=20 >> 1) Section 2, Protocol Extensions. >>=20 >> You have labelled the existing Length and Type fields as 0xFF. I = assume the meaning of the second is still 'Type' since that is >>=20 >> what any implementation would reasonably interpret it as, and that is = the registry you are using a code point from. So it >>=20 >> might be better to say in the text above the figure at the top of = page 3 that the length and type fields in [RFC4271] >>=20 >> are set to 0xFF. >=20 > Is your proposal to use the diagram verbatim from 4271, but say in the = prose that the type and length are 0xFF? I'm fine with whatever seems = clearer to folks. Upon reviewing the draft, I prefer to leave the diagram as is. The = context is that the diagram is preceded by "the OPEN message format is = modified to be the following", and then the diagram is given: ...blah blah... | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0xFF | Extended Opt. Parm. Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ By contrast, here's the diagram from RFC 4271: ...blah blah... | BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Parm Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If we want to keep the RFC 4271 diagram verbatim, I think quite a bit of = rewrite would ensue and it probably wouldn't result in a more readable = document, especially from the perspective of a person implementing the = new spec. And of course, someone implementing stock 4271 doesn't need to = refer to the draft. In looking back at your note, I think the disconnect = is here: >> You have labelled the existing Length and Type fields as 0xFF. I = assume the meaning of the second is still 'Type' since that is >>=20 >> what any implementation would reasonably interpret it as, and that is = the registry you are using a code point from.=20 Upon consideration, I'd say no. In the context of the draft (as you = point out, the proposed update to 4271), the two fields constitute a = 16-bit field which, when set to all ones, indicates the next sixteen = bits are to be used as a length field, and the sixteen bits after that = to be used as a type field. In a legacy implementation, it's just as you = say -- those sixteen bits are length and type. My suggestion is instead of modifying the diagram, we could revise the = prefatory text as follows. OLD: Accordingly, when the length of Optional Parameters in the BGP OPEN message is greater than 255, the OPEN message format is modified to=20 be the following: NEW: Accordingly, when the length of Optional Parameters in the BGP OPEN message is greater than 255, the OPEN message format is modified as follows, repurposing the Optional Parameters Length field as well as the first Parameter Type field to indicate the use of the extended=20 format: Seem reasonable? The question is addressed to the entire WG, not just = Matthew. In particular, it would be interesting to hear from = implementors as to whether the spec is clear and unambiguous as to when = and how to use the extended format. Thanks, --John= From nobody Mon Jun 27 09:25:39 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292DB12D7C9; Mon, 27 Jun 2016 09:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwoS1AMov82q; Mon, 27 Jun 2016 09:25:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9684412D7B5; Mon, 27 Jun 2016 09:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5UdmgCjZkjKeEQm/44xVAcWp2SV60XuZ5zDGn5PplKw=; b=eP6cvcdzxxtqV4Dwl7PXaC5c6iD7UdoroQTfboyPKjxfmiK0f8H3d0CsYTwV7Z/U5hFUU1WC7vrGupHW8BkSQ33G1LWw4/9jfZMUDYe4n+6EqojNqtbE/iOw5SUP8SNfhkdJ08nGJ2tN8lgaCiiXyMpZx1891EndNzo5ywIPf2o= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from plangevin-sslvpn-nc.jnpr.net (66.129.241.13) by SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) with Microsoft SMTP Server (TLS) id 15.1.517.8; Mon, 27 Jun 2016 16:25:14 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: <56a07f338f5d4a1f8dfd539040b1002e@XCH-ALN-014.cisco.com> Date: Mon, 27 Jun 2016 12:25:07 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2FBB796F-76B7-4F5F-B183-62A1FCA30313@juniper.net> References: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> <56a07f338f5d4a1f8dfd539040b1002e@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: SN1PR10CA0083.namprd10.prod.outlook.com (10.164.10.179) To SN2PR05MB2509.namprd05.prod.outlook.com (10.166.213.18) X-MS-Office365-Filtering-Correlation-Id: d4c621ff-54ea-439a-7ad6-08d39ea79ec9 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 2:9HPRMah2iprpknoS0I1DxaEOasZfF+1YlweNiMim6YG/n/9W6uYNJPN0y4M5nzqG6SJhTN5fzoA726yaAo3sb1p/pJVnhjgo55ME6Wjks6p0TMlnCIPqph7Tzfn+pP9PGbGODWSOT1czXfPaMfw+I7mnhNPZ+tINMfRn4/iwpfkwsvxuADaSOIGKRHX4JOT9; 3:hg/P0joqUBOEQg8ltqi3pak6H2rSpvQEDEYKNknXkEoTDX6yn5wt+2JLYMoTV7M8t4T94REF7qlLAgBpAD/jnOkMtZzb3UlqLOPDh3wthbIZFq+pRfuy1XJVgg8v1CKz; 25:CPKUniZD1m7QdYKJjKa5HSEYoeYHLvrENzOcR9Ia62ATqdqGfZj89ZA+9rFl8epct+JeBIFxS1djS8Z8hV74vQNL2T89E4s4xFJl4Esvwm18uQBfxHF+4XQ3P5WRkp/rvCBgTKSGC2UCukA5DFlrL5lIEY8ug3p5q1nw6b/GdwOmOe0P0ZXnGvjBZuJYoUIJZQXr6OdcjsGFVd+PFnRFlOnoACbDFQw4ZCGS5drqllBST/JQcD7wSPNZik+hyqVCLiMP7jiWBQAddOAzks49aVz5OiEB5EYeXFENaoJYErVC+uK9uSJyEVrYVQZD6QVjPKlmZYjOsPCmBzcRoajybpzofCeEvC7ZymB3YBJDHcLiUtSTKjTUdaitG40Cw+m7tb9nC0fVIntZRknUHuVDbsXIUiYAqvmO4IZUaJQEQn8= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR05MB2509; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 20:PLdoB3I3gn6Xf2TM8IFHSnPoR8PRlmwJ5vfaqy9zVB9gtnmTmIb7TWe429I5U0cOGYBcxZbuhG9Y5RTCfUtvid/z/tqx6NMeHRpJBhue/jOS/b/lhtwt/FZVkSWvbXv6EsYqYsHT4ce++wL13mjkcgkDGRQNcBez6GUO6/MTMu3kD7noxVB4vR7eOoMj/BLLN/uQy/tT2i3qOsR30eXCFQK1EDAgCIQ16zxqep1W2BWCXXNaVD8c96bdb7/jqDty6A6dWU9V8k/0WR76/GtP5SVjfXJzsuPCrRUeDbNIUUI76IR/rl1mG/6pSvjHW2Yx/CVkp2QYSvr6qf/fJnlLtidsUrYpDoNj89ViadyvN+KNoqsNVNayJT23STRHz7Q3DuP1lTjCR2oEDbIasfziv0lVkybeRftEjUxHK0JUFQ5IEWyQGqfQcGOjAdhHbxZ+yh9j50dOdPleaugKmM+1QPL1/8SmbzdqABNyfi1WIQjCBUWomV6jNr2xKgwqIVtd; 4:LbHP5TMX4DAnSiSpS71m6sSgPDJ5c9MhJ4dyEGjK7pvlplgUk+4z/97GIKOJ4dw/04OKful9AndEuivTCvQ4te845NhM9IakGaqL/egStMGojTdvDwwRjB+SssCh9xzj50LcFTlRpj7snVauPqu6/PO7MCu0lvuLUN9FOHmqabhyW9ffcpqEL9FXKu7bl1FUyqmXhLrAWLobSmN5FBoMU3u9Q+RTItmrbjappidb3koIByxqSr0lDh8BiFFjYcSexub0sUCgxf9r+CEz9ThDtg6x6D4mVe8aiAhZKyH7Oebhqg1Ao0vA5i+pDUYmzJKGl0XMJyrI5JUg7Pq8RHFXqSGrxSohvYHnORhwkXI7HBvfcLtZidRu1zg+/tpeWBU6fQQ0Pvx1YFcC47dlHPl7a+nfBUUO4A50FHVRCvIhevGTQmCqOyMsUWakHHdfXhEV X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:SN2PR05MB2509; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2509; X-Forefront-PRVS: 09860C2161 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(377454003)(199003)(189002)(24454002)(36756003)(19580395003)(97756001)(19580405001)(8676002)(57306001)(8746002)(47776003)(106356001)(110136002)(97736004)(53416004)(105586002)(7736002)(7846002)(83716003)(77096005)(42186005)(76176999)(81166006)(81156014)(33656002)(305945005)(189998001)(4326007)(101416001)(2906002)(69596002)(82746002)(6116002)(50986999)(23726003)(3846002)(92566002)(86362001)(230783001)(586003)(46406003)(50466002)(50226002)(2950100001)(68736007)(66066001)(93886004)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2509; H:plangevin-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2509; 23:mLq0GBEMESoL70cdcJmvqSLP0c99OWTawY3D/v6SA?= =?us-ascii?Q?4dGhPtgjm032r5DhWfupGtZWh8CEZD3cvs/R9cAYaPiIgOjz25HxbmMd5J9u?= =?us-ascii?Q?74NlvsfLciIxwl1LL5FbmnoEw/vBDHTV281DhGsXIHBOkHHwleMcHbsTw+Ia?= =?us-ascii?Q?ZWvVdBnAIM41JgMLomjnGhQYeieb2CkAnOF9pvNK8+lP+j25kNepGCAN+AAv?= =?us-ascii?Q?uYcntBOXjNcLyoT3lym0ygp0O2BZ5NDdkkhl7GTN0lt6hqNwhabVhOHmT/70?= =?us-ascii?Q?BxsnG0t+I4rsDaQLi0H68V2pVGmUZ792zH5asZBGULcm8/AnW3QbkYUralyH?= =?us-ascii?Q?pmPVqN7IceoMtUhyZKvKgp6EsY2c9jlUbspsbr1Wx1ETx9GrYtCnPnKMpsuK?= =?us-ascii?Q?SfYIxoubD+bNaAgZsCl23Q5n2/sstIJeSNFDSnxFjYNUb6XTP7W8/aXwJek8?= =?us-ascii?Q?FlLojdmCIxc/S00vtN0dJ1YnfdrCiA/gEvECevTshSyRJ3XzBP9bLBrNUs0r?= =?us-ascii?Q?MQSyl5Cp23/sRwgbudKHkEXcaF3+/z7XsinqzNqHGEyttxSXLAGhTVc8nA5s?= =?us-ascii?Q?2BVq2o0h8NealL9ENytuLY5f8eS7qQ7AhC8VTOZ05mBDs7E1wDk0pllP5qKz?= =?us-ascii?Q?GK0Y3NgMzXpc8j9MePToLnkxTU3lE4e9Y36QIjiRwfecltuRWtO66V5IsUBh?= =?us-ascii?Q?SBTEmu97QEU8pIAY2oA4s6N94Cd9zh+X/zDwUXzOmK7EmAvvXNplOPEMgQkJ?= =?us-ascii?Q?eOikCS6PwvWKYxyFHK3e3OGm83LygjKZFf3IlNNaftC/dbHMDhbpl7NKLFj/?= =?us-ascii?Q?eJZ2fzegZtj8v1N2dxBALaUYB0ZiuSqBhaKyfUIISi8h5XJu0po4KaDlN0Qq?= =?us-ascii?Q?G4+gJCPmF7SJUVyaiHWGrOVyjFNfqK59VaNFp94Vq3XxhXSpXYRHgexa4Q2/?= =?us-ascii?Q?KQjNjazZh7svdrTbSIzuy5Ptjj8LJ29Dd4JTXdy0OiiA9GslGyAqbay6A9Qg?= =?us-ascii?Q?ncKdADx8YFGjtZ+Rg+IHYHcsAOXqxGRvEFW6QgsMgHzPDvRwIwP7//SE3aVZ?= =?us-ascii?Q?AZjW7D53NAbJYj6m0e9s82MvK7d/YZNyD0nmdWBOOHVTWj6LWjmOJfLP94/u?= =?us-ascii?Q?Bz8s5hwJMgfrAxhiU2BQzTLaL13bKTPctfZbASWVw5S24j8y7dcRPbATmSXT?= =?us-ascii?Q?AZpsoh/ZDzgY5MVsz72aYXcP0go9ETwWKZmCdnD/LaLwN77hKd9KS7y9HpDY?= =?us-ascii?Q?9B6namFoHVY9nkJepqDm9l32/ZpuOqqKkqB8ddgULcaNbIbE8VG4HXDL7gYL?= =?us-ascii?B?Zz09?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2509; 6:lTAbdCxmxgwf2A2dt7auSnNmgzd6cLLrWEDfPS0CJnHDNzDdR/TM/yk13Tb2tIrlo0127BbkZJgU3CZ4yZWiyvKIcDiw8muEEvTUnVvBoyWiMumY6jnAXXfU1QQyTDYqLJj6/R/1hqnzfFeyXMfLFySXMGOKU3StjvyvTg1fl/rI5x1LQDBvU63IN9pmuvrSe0GVT1I/UcACaaZpSeyrFm/Xl4zTAfQVNRrLyLEFrCd7d8sz5uLEkIFj4hQEmbbkesetdudyCBRBvgdWhOt5v5BdTBrr01ZLHSE5iEWWkaJjWz1r7y4FiFNucd7+HLFSfHbwrTSB+GArCrmTtugFGR/onLs7zbQCRKOk1vBTSbE=; 5:a+DlC9YlI2Qjma/GVfrsD9/vbal9pmxfCZlwac6rDpbfdSsXlpLPimXV2zEsAb4hG3AAJrdvGTWhKvdR+p8kTsXhjL6tujXUgLXgN6mEf2JMZzuL1BhhuV4+DoCbP1FlHgrmB1R69gsLKqGQkDzhVw==; 24:rD9itE1sH1Ut1mciPw2rXsxHCSDCjYKp8sKH1ZNZ8xyJTonp4ulA9ei7a5ryzOMja3+KobyNMdKnXjeS6JSdhfmx15Szj4O4KkwhCNqODog=; 7:4DG6lp3icbdPrpxSOqecNQFn+BZjmBi5yqwWmGJrHCDWw3yXi29GigD57OwDMM1AplYtXv0xighfPWO9qPcBS6L5VPbK5N8A8q2tIwI+eSDqhTqeMTL7WCkYNOhTfWuHdf7tLj/edB72vA6tX5FNGtb3vwL1i3dIDr5TsWtAhpNT0smtT064ZtzlzQWpPjABhdnH0wU6sTCmGaFsmZvQx5l+tbtfUpYu8IG1uxC7hG8mezQTTd/uA0rw8DCMgTba SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2016 16:25:14.1665 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2509 Archived-At: Cc: "idr@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-idr-ext-opt-param@ietf.org" , "Bocci, Matthew \(Nokia - GB\)" , Susan Hares Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 16:25:35 -0000 On Jun 26, 2016, at 7:39 PM, Jakob Heitz (jheitz) = wrote: >=20 > "An optional parameter with parameter type of 0xFF MUST NOT appear in = the > list of optional parameters other than in first place and if it does = appear, > then the optional parameters length MUST be 0xFF." And it's a fatal error if it's not? (Remember this is before the session becomes established, so the = principle of service survival above all that would applied in the = error-handling spec doesn't apply.) > There is really no reason to entertain other combinations and I don't > want to have to write code to handle them. Is there some reason insisting that the non-extended length field be 255 = is better than ignoring it once you've determined by inspection of the = non-extended parameter type that the extended encoding is in use? The = logic would be, if the (one byte, non-extended) parameter type =3D 255, = then use the extended encoding, and ignore the one byte non-extended = length field. If we made this change, the spec would say, MUST send non-extended = length as 255, MUST ignore on receipt if the following eight bits (the = non-extended type field) are 255. Thanks, --John= From nobody Mon Jun 27 10:26:37 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEADA12D88C; Mon, 27 Jun 2016 10:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhAFQZBPyBEt; Mon, 27 Jun 2016 10:26:31 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF2012D88D; Mon, 27 Jun 2016 10:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2182; q=dns/txt; s=iport; t=1467048388; x=1468257988; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hyz9vSDURK+KNtIOx1AVBWh+GPWXjse+AjNtytowsmE=; b=TSeO2obrpA3ALJgYFyvBMrLo9aGciZVpA8Yx0wFvI4LvNb2eOAm/E5du UFdR+lu1dk/couQXHA4Bko/7wzX6gZxxH423CdPa12x7K92DpGUsFdgA5 30WCqrFme6aEsOZzwft2jhyWcGAS3hxov7cuuixTwtVsGZ/CY/3RZeQ82 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQDJYHFX/5pdJa1bgz6BUwa6J4F7h?= =?us-ascii?q?hgCgTQ4FAEBAQEBAQFlJ4RMAQEBAwE6PwwEAgEIEQQBAQEeCQcyFAkIAgQOBQi?= =?us-ascii?q?IIAjDAQEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKIRNihsFmQEBji+PK49+AR42g?= =?us-ascii?q?3BuiHh/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,537,1459814400"; d="scan'208";a="289810849" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 17:26:27 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5RHQRY0031294 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 17:26:27 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 12:26:26 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 27 Jun 2016 12:26:26 -0500 From: "Jakob Heitz (jheitz)" To: "John G. Scudder" Thread-Topic: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 Thread-Index: AQHRzmgGBv3fZ5fA9ES7A4n0pFWtDZ/8Z5yQgAFwVID//7bekA== Date: Mon, 27 Jun 2016 17:26:26 +0000 Message-ID: References: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> <56a07f338f5d4a1f8dfd539040b1002e@XCH-ALN-014.cisco.com> <2FBB796F-76B7-4F5F-B183-62A1FCA30313@juniper.net> In-Reply-To: <2FBB796F-76B7-4F5F-B183-62A1FCA30313@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.91.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-idr-ext-opt-param@ietf.org" , "Bocci, Matthew \(Nokia - GB\)" , Susan Hares Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 17:26:35 -0000 > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Monday, June 27, 2016 9:25 AM > To: Jakob Heitz (jheitz) > Cc: Enke Chen (enkechen) ; idr@ietf.org; rtg-dir@ietf= .org; draft-ietf-idr-ext-opt-param@ietf.org; > Bocci, Matthew (Nokia - GB) ; Susan Hares > Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-op= t-param-04 >=20 > On Jun 26, 2016, at 7:39 PM, Jakob Heitz (jheitz) wrot= e: > > > > "An optional parameter with parameter type of 0xFF MUST NOT appear in t= he > > list of optional parameters other than in first place and if it does ap= pear, > > then the optional parameters length MUST be 0xFF." >=20 > And it's a fatal error if it's not? Absolutely. As you say, the session is not up yet. >=20 > (Remember this is before the session becomes established, so the principl= e of service survival above all that would > applied in the error-handling spec doesn't apply.) >=20 > > There is really no reason to entertain other combinations and I don't > > want to have to write code to handle them. >=20 > Is there some reason insisting that the non-extended length field be 255 = is better than ignoring it once you've > determined by inspection of the non-extended parameter type that the exte= nded encoding is in use? The logic would be, > if the (one byte, non-extended) parameter type =3D 255, then use the exte= nded encoding, and ignore the one byte non- > extended length field. >=20 > If we made this change, the spec would say, MUST send non-extended length= as 255, MUST ignore on receipt if the > following eight bits (the non-extended type field) are 255. To Enke's point, can we make the non-extended length at least 1? Legacy speakers... In addition: An otional parameter of type 255 MUST NOT appear in the list of optional parameters other than in first place. Should we set a maximum length of 4k? There will always be smaller boxes wishing to speak BGP that will never sup= port extended messages. >=20 > Thanks, >=20 > --John From nobody Mon Jun 27 10:27:15 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23ED012D893; Mon, 27 Jun 2016 10:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxn_jQ24qRIN; Mon, 27 Jun 2016 10:27:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E2812D898; Mon, 27 Jun 2016 10:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2984; q=dns/txt; s=iport; t=1467048419; x=1468258019; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=lFmlUqlFR0sSbYtkQk+djp/61T5gjYg0VED5vSAV6TU=; b=RezsShDDls4dpB3kACYYf7eyjXDxl+q9THk9sdK0t468isHOYloKfSC8 +QTwpRnwFrbBIKadlMXAl78Nyw1w9rrwpt0r4doJ2ylic8/RLBHfQKT/e s5yqoDgcGrXdUEX+7eTKbbQniVlRrYtBwlPUYKDEHSNseXKdUsdzwyBOn o=; X-IronPort-AV: E=Sophos;i="5.26,537,1459814400"; d="scan'208";a="122373048" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 17:26:58 +0000 Received: from [10.24.116.194] ([10.24.116.194]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5RHQvk0028226; Mon, 27 Jun 2016 17:26:57 GMT To: "John G. Scudder" References: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> From: Enke Chen Message-ID: <3068e8e2-32e1-5899-cd62-6f7412b04192@cisco.com> Date: Mon, 27 Jun 2016 10:26:57 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "idr@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-idr-ext-opt-param@ietf.org" , "Bocci, Matthew \(Nokia - GB\)" , Susan Hares Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 17:27:10 -0000 Hi, John: I now remember the reason for having 0xFF there. It was something that we discussed years ago. It was something like: since the actual length is larger than 255 and there is only one octet, we just go with the largest possible value 255. (The value does not matter once the real length field is reached.) Thanks. -- Enke On 6/24/16 3:29 PM, Enke Chen wrote: > Hi, John: > > Please see below. > > On 6/24/16 11:43 AM, John G. Scudder wrote: >> Hi Matthew and all, >> >> Thanks for the review. Some comments below. >> >>> From: "Bocci, Matthew (Nokia - GB)" >>> Date: 6/21/2016 6:10 AM (GMT-05:00) >>> To: idr@ietf.org, Susan Hares , jgs@juniper.net, rtg-dir@ietf.org, draft-ietf-idr-ext-opt-param@ietf.org >>> Subject: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 >> ... >> >>> Minor Issues: >>> >>> >>> >>> 1) Section 2, Protocol Extensions. >>> >>> You have labelled the existing Length and Type fields as 0xFF. I assume the meaning of the second is still 'Type' since that is >>> >>> what any implementation would reasonably interpret it as, and that is the registry you are using a code point from. So it >>> >>> might be better to say in the text above the figure at the top of page 3 that the length and type fields in [RFC4271] >>> >>> are set to 0xFF. >> >> Is your proposal to use the diagram verbatim from 4271, but say in the prose that the type and length are 0xFF? I'm fine with whatever seems clearer to folks. >> >>> Also, you don't explicitly define what a receiver should do with the length field if the type is 0xFF. Does it ignore it, >>> >>> or does it check that it is 0xFF and treat the OPEN message as malformed if it is < 0xFF? >> >> This is a good question, and TBH I don't recall why we specified a value for the legacy length field instead of simply saying it should be ignored. >> Maybe Enke remembers? Right now I'm inclined to say it should be ignored on receipt, but I'm open to discussion. I guess even if we make that change we can still spec it be sent as 0xFF, for purposes of debuggability, but this is not a big deal. >> > > Here is what RFC 4271 says about the "Optional Parameters Length": > > This 1-octet unsigned integer indicates the total length of the > Optional Parameters field in octets. If the value of this > field is zero, no Optional Parameters are present. > > If the "Optional Parameters Length" field is 0, then the Optional Parameters > will not be parsed and thus the new length field would not be reached. > > I am not sure, but that might be the reason that we have it as 0xFF. > > It needs to be at least 1 for the "Parm. Type" field to be parsed. Once the > "Parm. type" is parsed, and if its value is 0xFF, then the two-octet length > field follows. The procedure is more than just "ignoring" the field. > > Thanks. -- Enke > From nobody Mon Jun 27 11:53:18 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DE312D77F; Mon, 27 Jun 2016 11:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvgQMECmOdGd; Mon, 27 Jun 2016 11:53:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0868912D78A; Mon, 27 Jun 2016 11:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FcESR+/kKqhIbi0WXdMtQuXXSanNHxXHO4qFenThp4o=; b=aFnxIAa2yRoQXhEXGeQZ1uf/FlJI+x2ByjrBhG2wtt3P1vXVU6jBaM4IZOcMWoA6AGrnFGMDjPIO1GUO8lsbuPvfOELh4nIw6ypDWEVlzOokrdPU0xTWHnQyMt0fGU/1YMtFLqFuWUd23eDRVDX0f0YMIKztZUl84xSo3EeYCJs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from plangevin-sslvpn-nc.jnpr.net (66.129.241.13) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (TLS) id 15.1.523.12; Mon, 27 Jun 2016 18:52:50 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Mon, 27 Jun 2016 14:52:43 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <19F86A8D-2414-42BB-B289-ED84AB945DEE@juniper.net> References: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> <56a07f338f5d4a1f8dfd539040b1002e@XCH-ALN-014.cisco.com> <2FBB796F-76B7-4F5F-B183-62A1FCA30313@juniper.net> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: CY1PR19CA0037.namprd19.prod.outlook.com (10.162.38.175) To CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) X-MS-Office365-Filtering-Correlation-Id: dbd4fec2-10e4-47cc-6f67-08d39ebc3de8 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 2:/QVpoUSJXbHQ2GlTH0LIFK1XF8iqasCG0FltOwY0fuDs2+0TiPfzkHpCho0NrWyXbJsCt45I6wCcdlMBzAZ+dtIwBOUbpI/hqV0cyFzUlnIWSRNyTlwHBmlcATTo5NqXWQUP5LYhWRbkUv3C4gXacpMT5LcsBbrDthU54DSA7d6sZ5iyKBCDHCE/TQ2qJXUr; 3:+85twFRaB44rSYLQmAWKxaLzHgnx8iN1yzkMAi3l8Bmil67t36sNzVl79ZGhxQcOfnmM1cwvcbJ3+SKHKLiPyWdVHxnGrAQgOiwNoUCW+NNj1hQ1MLrf7WQE5bJrBsCW; 25:66XqwR4MhQz/qZufvftKdRhU1g34QXRyp7hzB2LhwtT0eBQYtpjKujmaH/TcypeTuVfYWOQefyocZXNUNts6E9tpjZJcTIS0+SrJ2eUN6qXEkqx6FrpEEA2+brbZJOAYXvNc9SAqvHIwiO2mCyQeRUmqiyMQmLgzV/egsb6KHlEPfKjKneVhPGk9clfZiIZEjTroX4MEkIeXxXsubzpNjZWbuQGnZUOH/y/qCTzhtFtpHjrXcwzV0AtsvsteCsR/uamSWC1JBCps/8TDvUpskl1bAGLkHcZTQ81+TJNBSwQgQ2Y2vI4h/3Yl7ZfHgnubipSpE6W5fyVpoLeqpu06OZExf9oOHzHfWzCQryVm1gIZxynlBp6jc0IhWfTFyMlUz/eqq0QWL/76/KbiLz0WkbiuPh996n2j4QpczVHLwrg= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 20:e8XaFDcjttH6xW6UUhBU+ry2AnUtFPbIvM1ccr5ynLQ2Hno1R4oJI6dn6CgAGbbcHrlThT1F8ZHtXJFFJbCxqKn9khpbwyc1/ztOal4tpCxE7FLmUqxEhOWG8EZbQzwrS3HXsHaVt9M2ShTPxGNHIOKopNNtexZffG2ylEcVbDbYfhzEO4k24jy0A7DxEVIOmlzclwQpP9EiFEThdD59PFRQEbQu5+2n4PbN+1zWK+xj6/3EnxD+4douQTaiE1ZuZCTg5xZ+xDrALNqkZOIg6Hq96AgK0oXztk7tjWdXHyXAjCeHokB5k+KS/2/Fly2C3S5bra94jsvmvxtUmQe/6tnRbHA4QkJ+rc/cw/BUmID3s/4Os85Yj9MUS/0l3jTZW41PssWi7Y0AJKklGx1m2qJFaaWh8PVOCZLED48yhrytjudyKQtd6xJQ2PFcA/TmNGaGpwxjgmbmDxDWu5FD82P4OtZ3/XXRGZNH8LKctuZ/cfjDbxdpA7isu13PiRys X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(82608151540597)(95692535739014)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2502; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 4:jvuvTHmo38FLBi3yfyj7KOzrgDDpjMP9RCuOv34yLGvpzgtv+3ddXdSEeT3bn5pqeDbedX4crg7yeJpMGAjb33GodUiWz8MUZptFv/YeVv0IUlLIVN0EFTAd79m8zw1i7u6EyM/4gEDtOAMlrhN/eZXoNeyAmyxRWhZz/lT/nu7L73QltW3wol0iW2awmLDJOGQhzalZd4k4NaE7/ziRZmrooxHUsyPwDNz9EhYG96/cqHs/zTxl+3C6000SJLphPMKXxNxomf0c8vPiQwQmM+l9atOcB7fWuo0+F2BNE1M4czwp+wKg7Q0EPDf+Qf4tvV2SW6myjjxIoHGmSc727+64U4g0UA0f4H0cxWXmFllkEBi8bwKcBOCJgPz9ER8nTJkQ8h77PfWFFV/l/8xylKX+RKp3fEfGv/OWKT6apfse1q9mGufVa88ugnZQXfJL7IPRSmPekIjMpKl0LjClawpC/di8XBifLHREsWmdrB7EA5zmGMj1LjfK78vTs7W5 X-Forefront-PRVS: 09860C2161 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(377454003)(52314003)(199003)(13464003)(24454002)(189002)(50986999)(50226002)(7736002)(6116002)(66066001)(93886004)(68736007)(110136002)(19580405001)(53416004)(105586002)(81166006)(57306001)(101416001)(86362001)(47776003)(69596002)(19580395003)(7846002)(97736004)(76176999)(305945005)(8746002)(82746002)(2950100001)(81156014)(46406003)(33656002)(83716003)(189998001)(2906002)(23726003)(77096005)(8676002)(92566002)(36756003)(42186005)(586003)(97756001)(106356001)(230783001)(50466002)(4326007)(3846002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:plangevin-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 23:ljYHrOUyqxlrKy0BrbI0I4czgQ6nv6/8heeVxMLYm?= =?us-ascii?Q?5WpbI/abWgppuI0w/9z/HiZMkgI7/Slmuno+SEO+BZRRb+RhFJlIwjjcBz7Y?= =?us-ascii?Q?hMgRZA16IuOOFeSul01y1uAiV3PU1HhLlkWR6Nm/8U+vQySezPqJacPT3mE2?= =?us-ascii?Q?mKvqCh89ki1EjYzNi1SsM8SujXZusUlL8+dTiEJcOMQyCNBqDvDNZgR+KiAj?= =?us-ascii?Q?mk/q5OoW8NZT5ewqoaHcI3Ei4+qpGXnOPGWAWKMhcwkwUejHhfceMdE+AV7f?= =?us-ascii?Q?Ps6ODtjIGOsZ0pfh/xr/x6NZ8IoCBJpFvuhENZgKkRzr4AFSDO6YdtvhW7iu?= =?us-ascii?Q?rASSD1bua4KDvIx08EJyMaqmGYle/IOnSiY6ucg/txYeOYmBSRjOc5mE8UwZ?= =?us-ascii?Q?Fv2iU+nZ472G5a3iHcxaDTpRYGd3KzRxzloWSc0nOLMKhLb7bGP2dD6WBCuk?= =?us-ascii?Q?qPpRRSDTB6obfwFhT/Y9ulPL2fzAt4RaQnGhbDwSOHy9WptVBQYulu27zlkk?= =?us-ascii?Q?em/B68Vi0Jqt7vgZusKI7losNtfdyoL2MRFyRQSpfv0vwEneGl/fBTYTa5oJ?= =?us-ascii?Q?CCMdZKxj/VsfESE9mjcROS7IovtiqVB5nVIkQL3ThPVeWnLZ+So6LF6zVE8Q?= =?us-ascii?Q?NiuCY33KowkKmFCyBBMRjDs+wnKGz8lfNPVCVFLv+VU1A+lyYIG/4AgsXM7G?= =?us-ascii?Q?Sc5GnFlluVB0jWqGVMDYHsWJJoJtIAPdN5v74MqNflZUsspwt22lp0milMhC?= =?us-ascii?Q?vVYrUbALYjvGCUDfhZZvLL1w9KYS6na9qiptg0F9DGoyvo9eJD1EdjpL3wfp?= =?us-ascii?Q?bsAE14ubuy4F0UFe1oLtRahdFOz6CMZD/hkxYqIn7xEmNuPMLexplQucZzF0?= =?us-ascii?Q?t/wK3o6nb6xUesabtug75NSPOvVNIUeGHWstmwpym2AMvILbBILdpQ5dtWU3?= =?us-ascii?Q?ABXVk/WbFbT08CjNZPJ4eEMxxAwjohLCK9ePUs04dXS02/Mt36VtDu7bqe1x?= =?us-ascii?Q?wY1dHhcAZmfIbVOCqVoHnnj4cgeSzCo7DgSY3nXyYvpBr3MZleuDC3hcLIpk?= =?us-ascii?Q?t6GUlePkvXCBGSd0tA93r0AXWX6ci/+0/i+kzmVrRFXyQn49z8c8jpgBSlfg?= =?us-ascii?Q?rXW6cIzrRLC7Xk2Mbil/3eIOtFJ1Al/KcjiwgM2/5Lhik7eWeR/py1vmsOH5?= =?us-ascii?Q?p+aTF1eOSnjICt4GMOts0eKWDUN0gcHJuFYS1zHGv649neOhg3PvwxmslV03?= =?us-ascii?Q?lZqGT5dJn61Yjy1hOFEGvXANjkwJZJFaVk+h0FayYHmCjw13jjv8zGux+nrL?= =?us-ascii?Q?GQGjYzblJ8jHnCF0ytwSQMngZQf5zFZ7e/fi4u2d+wd?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 6:oSd8DpmalERyZcIJMD4hWGMa+d5SBBTykqWzKir7cyMTZ0yo9HleGbCLRoO0knTChh+SDil+YGGvRUgiz4t4b4RfXNm196EEK10BV4CtRQcV8Vm31zGDHWcb8Ck9TK+/8I1p20Iugx/UhJ8M5tFSQRBxx7G5LvvNJEDUN8oySZiqNdrqYYTamHLxAx7rnwc5wjdypKRIU6Ck8Gcofzp2FPvoT3NfuTl68P1f0yNo8YGlL+IheOHWkf4cSeltSLRGQB70fBRHWEAR4J+hZG8A5hXSfF0swC8Fkn3LpUD+LIkOOqq6+1y2+8l0SjBzy+q5RJBziDq8BU3ejBehLsBK0MIJuSHIBU9J6TeKrp2MKL8=; 5:8i4ViUV3EfKT3CqPBOpaz/woenzyLVkJIiXPT83pqc+CheEOLkqR/QudDQph2R4smCDjvYeqcy+//PHkp3TkZ42/Gl6RBgguyZ9Nrm7yC/7X6Lp3xoidgKJwwOdzfIabY33C7izKAuYnDuMTtXT7bA==; 24:rOh197Kkd6v7+Qe42dgq6U0Lo18i/8N8OB6jA5IAqX5td/7DYf+yuZnqUw0dqyJ+VLskYQPDUyd3BiyDe5qzmnjcntqI+vLj7A7PGhMngq0=; 7:fLU6E3mr4e2aJOvZQh/lwGaCtlwOxSfSCIpAcGu5vV+UPLrtRbsarHHHPxGLRej+QhCQ5uVF76LORsi7M93OGM559YNsa+dMRbYnGE21UJV2k0nzxgMb0TNy8omfg7/FUH4+Yt/FjXuX/FOegsMdwHUIv0YXFtirbIDEJDv21dx8WoypU9u5FDcZ/ogUfI5n0dsJ7DarJvmZGyrs5I4ERbUtH1Gb3JXg6jzDxpgzZpEBLoww7PTDcy+eJ6bMB5Z0Jx6PkvyGD4HP3zIufgGnxw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2016 18:52:50.6504 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502 Archived-At: Cc: "idr@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-idr-ext-opt-param@ietf.org" , "Bocci, Matthew \(Nokia - GB\)" , Susan Hares Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 18:53:13 -0000 On Jun 27, 2016, at 1:26 PM, Jakob Heitz (jheitz) = wrote: >> -----Original Message----- >> From: John G. Scudder [mailto:jgs@juniper.net] >> Sent: Monday, June 27, 2016 9:25 AM >> To: Jakob Heitz (jheitz) >> Cc: Enke Chen (enkechen) ; idr@ietf.org; = rtg-dir@ietf.org; draft-ietf-idr-ext-opt-param@ietf.org; >> Bocci, Matthew (Nokia - GB) ; Susan Hares = >> Subject: Re: [Idr] Routing directorate QA review of = draft-ietf-idr-ext-opt-param-04 >>=20 >> On Jun 26, 2016, at 7:39 PM, Jakob Heitz (jheitz) = wrote: >>>=20 >>> "An optional parameter with parameter type of 0xFF MUST NOT appear = in the >>> list of optional parameters other than in first place and if it does = appear, >>> then the optional parameters length MUST be 0xFF." >>=20 >> And it's a fatal error if it's not? >=20 > Absolutely. As you say, the session is not up yet. I don't really mind doing this. I also don't mind not doing it, since = it's basically a superfluous check -- the Optional Parameter Type is = sufficient to fully determine that the message uses the extended format. = My slight preference is for not doing it, since it's a few more lines of = code (for the check), for a condition that is exceedingly unlikely to = occur, and doesn't matter if it does occur. So why spend the code? >> (Remember this is before the session becomes established, so the = principle of service survival above all that would >> applied in the error-handling spec doesn't apply.) >>=20 >>> There is really no reason to entertain other combinations and I = don't >>> want to have to write code to handle them. >>=20 >> Is there some reason insisting that the non-extended length field be = 255 is better than ignoring it once you've >> determined by inspection of the non-extended parameter type that the = extended encoding is in use? The logic would be, >> if the (one byte, non-extended) parameter type =3D 255, then use the = extended encoding, and ignore the one byte non- >> extended length field. >>=20 >> If we made this change, the spec would say, MUST send non-extended = length as 255, MUST ignore on receipt if the >> following eight bits (the non-extended type field) are 255. >=20 > To Enke's point, can we make the non-extended length at least 1? > Legacy speakers... Yes, you will see my suggestion was to make the length 255 on Tx (as you = and Enke point out, it has to be >=3D 1, so might as well choose 255 as = any other value, and it jumps out nicely in a packet dump). Up for = discussion was whether to enforce the value on Rx, or ignore. You've = spoken in favor of enforcing it, although I'm not sure what the reason = for your preference is.=20 > In addition: An otional parameter of type 255 MUST NOT appear in the > list of optional parameters other than in first place. Good point, thanks. I'll work something like that in. > Should we set a maximum length of 4k? > There will always be smaller boxes wishing to speak BGP that will = never support extended messages. I'm inclined to leave this alone -- if you can fit in <=3D 4k you will. = If you can't fit in <=3D 4k, a peering with such a box isn't going to = work regardless. So either it'll be fine anyway, or it won't work nohow. --John= From nobody Mon Jun 27 12:24:14 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DEA12D5D1; Mon, 27 Jun 2016 12:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0Wce8anJq8B; Mon, 27 Jun 2016 12:24:10 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D926127071; Mon, 27 Jun 2016 12:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4028; q=dns/txt; s=iport; t=1467055450; x=1468265050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BepDFirHeOsko7nc3qsbpf+YgmpGgXoHdEV1R0ndRpY=; b=G6xFaty5ezAoq985CMmDdkMHFXW4uOc8xcVgAuoSp3c0Lg9rnhAuabaP hV8yt60qrnurOmFIk5aI050LC7sGAdpVcKk3W2/c3K4qCe+AAB7kPV1fu 2p+oCzToL8WyZrzwM7+9A6QyRqUVa9IjcKqUfIo0m3E6antwooTBrPc7l 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQDTfHFX/4cNJK1bgz6BUwa6J4F7h?= =?us-ascii?q?hgCgTQ4FAEBAQEBAQFlJ4RMAQEBBDo/DAQCAQgRBAEBAR4JBzIUCQgCBA4FCIg?= =?us-ascii?q?owzkBAQEBAQEBAQEBAQEBAQEBAQEBAQEchiiETYobBZkBAY4vjyuPfgEeNoNwb?= =?us-ascii?q?oh4fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,537,1459814400"; d="scan'208";a="290013874" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jun 2016 19:24:09 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5RJO9Qm010698 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 19:24:09 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 14:24:08 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 27 Jun 2016 14:24:08 -0500 From: "Jakob Heitz (jheitz)" To: "John G. Scudder" Thread-Topic: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 Thread-Index: AQHRzmgGBv3fZ5fA9ES7A4n0pFWtDZ/8Z5yQgAFwVID//7bekIAAcl+A//+017A= Date: Mon, 27 Jun 2016 19:24:08 +0000 Message-ID: References: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> <56a07f338f5d4a1f8dfd539040b1002e@XCH-ALN-014.cisco.com> <2FBB796F-76B7-4F5F-B183-62A1FCA30313@juniper.net> <19F86A8D-2414-42BB-B289-ED84AB945DEE@juniper.net> In-Reply-To: <19F86A8D-2414-42BB-B289-ED84AB945DEE@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.91.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-idr-ext-opt-param@ietf.org" , "Bocci, Matthew \(Nokia - GB\)" , Susan Hares Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 19:24:13 -0000 Fine. Works for me. Thanks, Jakob. > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Monday, June 27, 2016 11:53 AM > To: Jakob Heitz (jheitz) > Cc: Enke Chen (enkechen) ; idr@ietf.org; rtg-dir@ietf= .org; draft-ietf-idr-ext-opt-param@ietf.org; > Bocci, Matthew (Nokia - GB) ; Susan Hares > Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-op= t-param-04 >=20 > On Jun 27, 2016, at 1:26 PM, Jakob Heitz (jheitz) wrot= e: > >> -----Original Message----- > >> From: John G. Scudder [mailto:jgs@juniper.net] > >> Sent: Monday, June 27, 2016 9:25 AM > >> To: Jakob Heitz (jheitz) > >> Cc: Enke Chen (enkechen) ; idr@ietf.org; rtg-dir@i= etf.org; draft-ietf-idr-ext-opt- > param@ietf.org; > >> Bocci, Matthew (Nokia - GB) ; Susan Hares > >> Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext= -opt-param-04 > >> > >> On Jun 26, 2016, at 7:39 PM, Jakob Heitz (jheitz) w= rote: > >>> > >>> "An optional parameter with parameter type of 0xFF MUST NOT appear in= the > >>> list of optional parameters other than in first place and if it does = appear, > >>> then the optional parameters length MUST be 0xFF." > >> > >> And it's a fatal error if it's not? > > > > Absolutely. As you say, the session is not up yet. >=20 > I don't really mind doing this. I also don't mind not doing it, since it'= s basically a superfluous check -- the > Optional Parameter Type is sufficient to fully determine that the message= uses the extended format. My slight > preference is for not doing it, since it's a few more lines of code (for = the check), for a condition that is > exceedingly unlikely to occur, and doesn't matter if it does occur. So wh= y spend the code? >=20 > >> (Remember this is before the session becomes established, so the princ= iple of service survival above all that > would > >> applied in the error-handling spec doesn't apply.) > >> > >>> There is really no reason to entertain other combinations and I don't > >>> want to have to write code to handle them. > >> > >> Is there some reason insisting that the non-extended length field be 2= 55 is better than ignoring it once you've > >> determined by inspection of the non-extended parameter type that the e= xtended encoding is in use? The logic would > be, > >> if the (one byte, non-extended) parameter type =3D 255, then use the e= xtended encoding, and ignore the one byte > non- > >> extended length field. > >> > >> If we made this change, the spec would say, MUST send non-extended len= gth as 255, MUST ignore on receipt if the > >> following eight bits (the non-extended type field) are 255. > > > > To Enke's point, can we make the non-extended length at least 1? > > Legacy speakers... >=20 > Yes, you will see my suggestion was to make the length 255 on Tx (as you = and Enke point out, it has to be >=3D 1, so > might as well choose 255 as any other value, and it jumps out nicely in a= packet dump). Up for discussion was > whether to enforce the value on Rx, or ignore. You've spoken in favor of = enforcing it, although I'm not sure what > the reason for your preference is. >=20 > > In addition: An otional parameter of type 255 MUST NOT appear in the > > list of optional parameters other than in first place. >=20 > Good point, thanks. I'll work something like that in. >=20 > > Should we set a maximum length of 4k? > > There will always be smaller boxes wishing to speak BGP that will never= support extended messages. >=20 > I'm inclined to leave this alone -- if you can fit in <=3D 4k you will. I= f you can't fit in <=3D 4k, a peering with such > a box isn't going to work regardless. So either it'll be fine anyway, or = it won't work nohow. >=20 > --John From nobody Tue Jun 28 19:10:55 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F2112D9DC; Tue, 28 Jun 2016 19:10:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160629021049.22557.86109.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2016 19:10:49 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ext-opt-param-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:10:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Extended Optional Parameters Length for BGP OPEN Message Authors : Enke Chen John Scudder Filename : draft-ietf-idr-ext-opt-param-05.txt Pages : 6 Date : 2016-06-28 Abstract: The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP Capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concern about this limitation. In this document we update RFC 4271 by extending the BGP OPEN length field in a backward-compatible manner. The Parameter Length field of individual Optional Parameters is similarly extended. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-ext-opt-param-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ext-opt-param-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 28 19:19:10 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F8112D8A1; Tue, 28 Jun 2016 19:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teXAE5vwvvIo; Tue, 28 Jun 2016 19:19:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6178412B049; Tue, 28 Jun 2016 19:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PTCpci7pV3H4VV1quCM8ZJIgGRukv1GOoGM28c270CA=; b=aWgCE2vA9jZf0CadbFsFoDGbNbpoG0qflokmK3hGUNqvpuA+lsNLIyrOaGQ/aYvYx7frk1E0dQEylU5oFlatMUdeonGzBAzLkAps7cLXDF7mCNvUmLIIUaZtS1lJ5S5keZhBoSHBeznrVeWPxMLvFn+01JyDIUutdgmLoc78mG8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from plangevin-sslvpn-nc.jnpr.net (66.129.241.13) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (TLS) id 15.1.523.12; Wed, 29 Jun 2016 02:19:02 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Tue, 28 Jun 2016 22:18:53 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> <56a07f338f5d4a1f8dfd539040b1002e@XCH-ALN-014.cisco.com> <2FBB796F-76B7-4F5F-B183-62A1FCA30313@juniper.net> <19F86A8D-2414-42BB-B289-ED84AB945DEE@juniper.net> To: "idr@ietf.org" X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: YTXPR01CA0082.CANPRD01.PROD.OUTLOOK.COM (10.165.216.50) To CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) X-MS-Office365-Filtering-Correlation-Id: 02e635e5-9038-4d0f-226f-08d39fc3bd3a X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 2:hHVqvzG0qX00/vt5NumRuaZ4q44r4cJX5PLirqsVPKPXGCT/AWbnAloCABuMVo84ycYOL3wGsRdiPPYD5NbcQmmutdh1sk59NA7lt0251tZjFmTPSevds3cUq8OpZJtI6HLB5L1i5Roh4QPpLlMGwFiK4r5rdJs7Q4bpJEDyZCyTc/p+mJoSVUmuzoeM1fmW; 3:Qi2r7UNhn0daNH90Flz2pV6h1D2bH1b+qt1L3U5Q7ylk7Pby/puWRLVQ8F09eAx8wrUdttAU3EcgJmTxcEWRdZaezra9vsJKXnsQjXfiIsKmEOPH2q/1wglh17jc73oV; 25:MxOuKVTIBVliCtwdLuWCi5+kuBCRugislEpkLtJmZBLKvt5xTiDzrTSbIUOfUDQl1jDq4Y7aLmcD3cVywJlwYKT16e5qj7iMBa6NDjNdvASp441anNjHMxxED8rsKZTCR6nnCXV09we1/j6QsDlQ7+r6KbNDVVKTYTJn/C++9ChbwvGk1qJ1+6arUV1ifSAp0/3JqBUUZUKajcaX7rqqzOui3XCUUabs12yh9aJzhLjeqfKENyljWNiEnsbJo/HQZMxsjaJE4pEu0Zp54LYr8pNdYQMK3Tjkz/K4//nUhdu4mTG3Z+TYKTIBblIKYCZVQf+btNcyXaaz6LxE2IQdi8Y74EFqV5emUoJ807pDRtFOJerKvL7c9pdqm3dC4aOgL3ZT6vOrkca7WjS7LCDqSAtdzlxG5dTab/BtiNAnpbc= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 20:PaygAvbWXMh9YWTEWkrH/uS8pBKhl/u2UussblGY4pkyvVDqk/yBjMmQmhZyXVFUOc8E4+L+fyWIus/JJOY+XAN2OnCRXDkvNHsHsPOwyzg0kOqs4M4UgIxLxmLm8moIGd+6cDN36FhJMS2BxZivvOTRLST0PFrpqXBxnst4qUzsdNYtuSA/l0ZRaly5iUfbxHwzqlsGTl8QgGjlw5hVz5eMZ6i6ksSR7v3HdAsKyjRSApJ4OL9f6YZ8L0GGOq6rKDRy9qYJJex3B+Jj/AeykT0TInI7M9wPcmxYEQvDyktBGszaXHsGCYo+xVY6IJGUDZ3+JCA1HERSWxH0Ee3pdQ9dCtG9Afdc1BvYQ/CziwZM2s61DNIXDdzQQlPc8uQwuY8rg8mO6DDaxKMNh2DYwFCybnaudjwRcW3XKsNE6grsPMPbgNaSi+vcTkxb/nommDvAjTN0lqa7H2gw6jWHbtz+vqF1+zlrvcCMd4iMGtljOp1riVF/Cy95asxO5dwS X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(82608151540597)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 4:StVHSlwVPbBv8xoqKhXprHELrasOVfNvBChQ5Gc4vdqBVTWdOJropDasTALQozS6utm7Ir2Nqu3b4y3XxdWDgay1gBkIa4pFdumGjyrK1+S/2gCbQTCaac0v2VStcKUOR+KoI7vnkwUcHGfKu0p1CclFlX+Tn7RESZzzGzRR1IvRaAXTJBjY+Bkn6aTgLT5qanybEh5eSpUr97uvjuu7RUmP+jNXcDYwJdsvVFN6UbcbQKN423VXEC6r6FQL6MOVLpU0ot4Zc6RRk7GoyOELyN3TqmV3iO+3PsFtFvXl+3p4i20zevSpE2n3VV/O6d4tM/FIKtzL2d4HHIxrq77C+LI5d81Idnv8g388jSu/w/W99Q44P1Y5acqWqQLkptBIVmcFkX4IE4kaDmisPFbupAAvFCTiWZhnX4bUF8ge6cjVxMDZ0z9qvVBmsPdLvthXZz3RQYIdc1xA81USsm4K7nyXq0HtC1TzSLyLJjgCTIQDGQ1ZXRA+jcBUlKCzX04L X-Forefront-PRVS: 09888BC01D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(52314003)(199003)(189002)(377454003)(13464003)(24454002)(230783001)(33656002)(36756003)(50226002)(6116002)(3846002)(68736007)(23726003)(82746002)(8746002)(101416001)(76176999)(50986999)(19580395003)(19580405001)(97756001)(57306001)(47776003)(2501003)(305945005)(7736002)(66066001)(7846002)(92566002)(189998001)(77096005)(105586002)(83716003)(46406003)(86362001)(2950100001)(81156014)(8676002)(81166006)(1730700003)(69596002)(2351001)(106356001)(97736004)(586003)(5640700001)(4326007)(2906002)(110136002)(53416004)(50466002)(93886004)(42186005)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:plangevin-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2507; 23:FIhVCqY9Bg6DHOjPU6XHcMnugBvrLu8Pp0JR7qhcT?= =?us-ascii?Q?RyHNC+dyg7VUuK2CeSue14baznA7qQq0Jgpka36u9Q/TwmzQpubRjgtFUMrj?= =?us-ascii?Q?hv7kzx87K0D6sYvPdbcUWiVE405H7nIvvEvrBSJdsvo2nt9w9Mn9lmhnRMml?= =?us-ascii?Q?Ps0LSCyOIfsbd+gSqRF7I6aTLTp6l3OupK7D7vGzRzcRZpnHiJwwr9ny/ZnO?= =?us-ascii?Q?kxbUUUkx8PMc+7txL38g9lr2iSGiYJGGvYxaKK0yXSuikKOhhqNdzOVAZu73?= =?us-ascii?Q?JlHQvavvJE4dCuxlWMMMViLR+DsSmiJvN+2sGN/QpMbRBU/1GRdDfXAE7Kod?= =?us-ascii?Q?BR3JT5LD0F/cTLsJBglWl6rYub1/TfkBogzN4lPZBtlxx18Y9WsP7X/y0Hy7?= =?us-ascii?Q?ylrn+oVuEa2a9WD3tRkxWi7pMYAPCAIT35DplHOsHI47++4g93lkOBx4G8Eu?= =?us-ascii?Q?OETMbAKJOTURqd9t52nPUAB7Xe2ss+MzmHhNQIydcFgxhHUdEbVtp78fXqlN?= =?us-ascii?Q?kOMCtn2QINVo9IqRhJ3H4FEcBWqwYRNZZmNqrfZGyKOG8dHLu1VL0W+Adbw2?= =?us-ascii?Q?v7mYjmwhX0CI0ZF26oJjq+GOJjMzftdMHmnwd25PJMghFu2Hx3TwFmks0G4E?= =?us-ascii?Q?rWi2HLVP2cujbF0QPxbBMYthGgRjgt2m3IynAXIr1gmD4aD1jhSAvZJEBR6P?= =?us-ascii?Q?WyOltK9HFxvm9JuRev6He2WdEDRK1APsIsoKHhZ6iH0t32bny2FeWsXdpKdY?= =?us-ascii?Q?sqyWAYMlVJavwirb2NcZI9MSny4zRW6yirLyqte+INSdJItmDCdy6DdiaTrx?= =?us-ascii?Q?ktRVPkjc7SPqef6Ajobfm4/rLjFEk/K+mfsBeeVKUMeON8XFZBoKUBIj8dzE?= =?us-ascii?Q?UREJxng4CHH1eCyQG7tOrzzvAV7Sp3+LQGIh2BG/+yltG9YwV4lAbrIbE5cp?= =?us-ascii?Q?ASmM7vghWkyfFFy08ozTKdL+fvN6c2a6bzzTyyEpai9ZDwo7C7upgZGdETOq?= =?us-ascii?Q?yy1eM8H4+T2HBFgPy3SUPTUaTTUNcJsvmvzmc5nrCPVk29K9ZFDzk0jbQhsj?= =?us-ascii?Q?oMMYzTHdn2tK8xwSVGEpV4g4SAJigVFQYbC0JFd3ZhRI4h6QDk0A5xQQ/uu6?= =?us-ascii?Q?j/TbXCdK9HI3FS69o2d2G3aSmZh3dJiRuT6anPgCSwTla8c8aom8qYMJGfcV?= =?us-ascii?Q?e2a0UZ8XHdIUePrg0bWcnu9Y6rhjpB+N0jub+bKTen4zlmKwkeaeKdRbjbdc?= =?us-ascii?Q?ElKhX5MRBXGnOz1GNC5D7315zedyE4mOJd6pZ835HufgwqdGYeD+NoAJcFVl?= =?us-ascii?Q?FxeTSdNYsgSOMFaICT2p4VuhcK4u0FKFeTHXIaiVLVFN/k110hn7llGhR6wb?= =?us-ascii?Q?Pz+FkNerB2lFUvg5BBn4Veof0wz3UaV/4aPfT/7yPH2pWSoMfsnYDXT3FwPf?= =?us-ascii?Q?zKu4w+3lQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2507; 6:wzeaj30DEypQite2LAEMg17H1iGqdFsPZNhf1yBJEZMVcqw6X5ZxCh9JEKpvfLnshRxaD5zFSJigKpffkJuRB3lXoyMUGbBY/fpLZHkbhDdB+1II2z/l8LwjDz8gayTqQbfMHWWv7n6s31/Pa1X6PCcZVvoJTmDYg7vBr70/H7zACbM8tGX5lUcU1zFSUn7YZzKSk+VWf5/hGqq8Q09Ar38scdp3zPJOzVn1WlhKTdRqiItcp7DaQZ6RFRwA5A/+fjwTdYygUoajStSZszg83bF/y4wFW3yL2lAUesdeE1Nlgt/ePxvOP3b41f0nJZpzbYm3GfsLiBK3We953dyPC5i6m/OAxnxCBcmBkc6OF0Q=; 5:QKptUjNP180LT4ZJGHjsB/AGXugVBJzQ8WiYXCREVK2seGzBUUrrnm0pbV3nYilZYvj+7A1MaujupAcsSogzCaZ2ETTSrlBEsGSxE2cPgeYWa1JQHj5L+hWkcTx9nawd06X2aGfjFLK9F5qx6v3jew==; 24:Um2O6wdxkfCgIcisR5lxZk/s6X1w6wAKC8MGoqs4F4IxycowMILvBXReZbi4yxKNAgh24Cth/2213+NExeu9IR4mv9z9bCIi+0gpNbHMkN8=; 7:pN8gkXabHykGbp2dWS4KyKFsVqDHgzk3OHF4c2bHiDFP2BRpOYlwO2o7SthN2ynrBEdCO+bHqRF/2d0Lt9Mjxw/MyXOtia7zUMf54Qp8wMOxrRcvK9vj4bwTEaFopYISOawU5v92BVcynsi0frDECD0rwx+VMviPBVzwIcVVO+clgPtG4d7wYBDQBQcVARqqbcKCx2xpiVU4rDgi5TcKzu2uKzceHub/8M+/gXhoninJbaJHm9z+YutfU7d2iJPT SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2016 02:19:02.0395 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507 Archived-At: Cc: "Bocci, Matthew \(Nokia - GB\)" , "draft-ietf-idr-ext-opt-param@ietf.org" , Susan Hares Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:19:08 -0000 [removed rtg-dir from cc, seemed excessive] -05 posted which I believe addresses all comments to date. Please take a = look. I've adjusted the diagram per (my understanding of) Matthew's = comments. I'm ambivalent about it -- I'm not sure it's clearer, but I = did manage to increase the page count :-o. I could go either way, if you = have a distinct preference please say so. --John > On Jun 27, 2016, at 3:24 PM, Jakob Heitz (jheitz) = wrote: >=20 > Fine. Works for me. >=20 > Thanks, > Jakob. >=20 >> -----Original Message----- >> From: John G. Scudder [mailto:jgs@juniper.net] >> Sent: Monday, June 27, 2016 11:53 AM >> To: Jakob Heitz (jheitz) >> Cc: Enke Chen (enkechen) ; idr@ietf.org; = rtg-dir@ietf.org; draft-ietf-idr-ext-opt-param@ietf.org; >> Bocci, Matthew (Nokia - GB) ; Susan Hares = >> Subject: Re: [Idr] Routing directorate QA review of = draft-ietf-idr-ext-opt-param-04 >>=20 >> On Jun 27, 2016, at 1:26 PM, Jakob Heitz (jheitz) = wrote: >>>> -----Original Message----- >>>> From: John G. Scudder [mailto:jgs@juniper.net] >>>> Sent: Monday, June 27, 2016 9:25 AM >>>> To: Jakob Heitz (jheitz) >>>> Cc: Enke Chen (enkechen) ; idr@ietf.org; = rtg-dir@ietf.org; draft-ietf-idr-ext-opt- >> param@ietf.org; >>>> Bocci, Matthew (Nokia - GB) ; Susan Hares = >>>> Subject: Re: [Idr] Routing directorate QA review of = draft-ietf-idr-ext-opt-param-04 >>>>=20 >>>> On Jun 26, 2016, at 7:39 PM, Jakob Heitz (jheitz) = wrote: >>>>>=20 >>>>> "An optional parameter with parameter type of 0xFF MUST NOT appear = in the >>>>> list of optional parameters other than in first place and if it = does appear, >>>>> then the optional parameters length MUST be 0xFF." >>>>=20 >>>> And it's a fatal error if it's not? >>>=20 >>> Absolutely. As you say, the session is not up yet. >>=20 >> I don't really mind doing this. I also don't mind not doing it, since = it's basically a superfluous check -- the >> Optional Parameter Type is sufficient to fully determine that the = message uses the extended format. My slight >> preference is for not doing it, since it's a few more lines of code = (for the check), for a condition that is >> exceedingly unlikely to occur, and doesn't matter if it does occur. = So why spend the code? >>=20 >>>> (Remember this is before the session becomes established, so the = principle of service survival above all that >> would >>>> applied in the error-handling spec doesn't apply.) >>>>=20 >>>>> There is really no reason to entertain other combinations and I = don't >>>>> want to have to write code to handle them. >>>>=20 >>>> Is there some reason insisting that the non-extended length field = be 255 is better than ignoring it once you've >>>> determined by inspection of the non-extended parameter type that = the extended encoding is in use? The logic would >> be, >>>> if the (one byte, non-extended) parameter type =3D 255, then use = the extended encoding, and ignore the one byte >> non- >>>> extended length field. >>>>=20 >>>> If we made this change, the spec would say, MUST send non-extended = length as 255, MUST ignore on receipt if the >>>> following eight bits (the non-extended type field) are 255. >>>=20 >>> To Enke's point, can we make the non-extended length at least 1? >>> Legacy speakers... >>=20 >> Yes, you will see my suggestion was to make the length 255 on Tx (as = you and Enke point out, it has to be >=3D 1, so >> might as well choose 255 as any other value, and it jumps out nicely = in a packet dump). Up for discussion was >> whether to enforce the value on Rx, or ignore. You've spoken in favor = of enforcing it, although I'm not sure what >> the reason for your preference is. >>=20 >>> In addition: An otional parameter of type 255 MUST NOT appear in the >>> list of optional parameters other than in first place. >>=20 >> Good point, thanks. I'll work something like that in. >>=20 >>> Should we set a maximum length of 4k? >>> There will always be smaller boxes wishing to speak BGP that will = never support extended messages. >>=20 >> I'm inclined to leave this alone -- if you can fit in <=3D 4k you = will. If you can't fit in <=3D 4k, a peering with such >> a box isn't going to work regardless. So either it'll be fine anyway, = or it won't work nohow. >>=20 >> --John From nobody Tue Jun 28 19:34:47 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA2412D8F5; Tue, 28 Jun 2016 19:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Feq-R3G4A87h; Tue, 28 Jun 2016 19:34:44 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0107012D51C; Tue, 28 Jun 2016 19:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5216; q=dns/txt; s=iport; t=1467167684; x=1468377284; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=f5cbL7sjFm3q2ITYf62+e5o0Cyqg4nGHX9gICyYtWLA=; b=MyK0bj+p7PNVNLnhwJYqABniPrMpE5tVdTGrBBfjfW5/pJbIpKlFJF3h ietD24zf0cxIR6adgIhQG8+MHGU9LYUM6a7wgbJvzAlme+8EG99wq3lBb hWYp7P3bai/GeZ/A5LeSEpV+wpdITd7ld9QgFu0JouyfqkARv/radEg6W Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQB9MnNX/5NdJa1bgz6BUwa6NoF7h?= =?us-ascii?q?hgCgTM4FAEBAQEBAQFlJ4RMAQEBBDo/DAQCAQgRBAEBAR4JBzIUCQgCBAENBQi?= =?us-ascii?q?IKMNzAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYohE2KGwWTToU1AY4zgXCEVIhok?= =?us-ascii?q?AABHjaCCByBTG6IPwF+AQEB?= X-IronPort-AV: E=Sophos;i="5.26,544,1459814400"; d="scan'208";a="289779714" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2016 02:34:43 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5T2Ygqu029729 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 02:34:43 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Jun 2016 21:34:42 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 28 Jun 2016 21:34:42 -0500 From: "Jakob Heitz (jheitz)" To: "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 Thread-Index: AQHRzmgGBv3fZ5fA9ES7A4n0pFWtDZ/8Z5yQgAFwVID//7bekIAAcl+A//+017CAAlongP//r+VA Date: Wed, 29 Jun 2016 02:34:42 +0000 Message-ID: References: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> <56a07f338f5d4a1f8dfd539040b1002e@XCH-ALN-014.cisco.com> <2FBB796F-76B7-4F5F-B183-62A1FCA30313@juniper.net> <19F86A8D-2414-42BB-B289-ED84AB945DEE@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Bocci, Matthew \(Nokia - GB\)" , "draft-ietf-idr-ext-opt-param@ietf.org" , Susan Hares Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 02:34:46 -0000 Looks good to me. Thanks, Jakob. > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Tuesday, June 28, 2016 7:19 PM > To: idr@ietf.org > Cc: Enke Chen (enkechen) ; draft-ietf-idr-ext-opt-par= am@ietf.org; Bocci, Matthew (Nokia - GB) > ; Susan Hares ; Jakob Heitz (jh= eitz) > Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-op= t-param-04 >=20 > [removed rtg-dir from cc, seemed excessive] >=20 > -05 posted which I believe addresses all comments to date. Please take a = look. I've adjusted the diagram per (my > understanding of) Matthew's comments. I'm ambivalent about it -- I'm not = sure it's clearer, but I did manage to > increase the page count :-o. I could go either way, if you have a distinc= t preference please say so. >=20 > --John >=20 > > On Jun 27, 2016, at 3:24 PM, Jakob Heitz (jheitz) wr= ote: > > > > Fine. Works for me. > > > > Thanks, > > Jakob. > > > >> -----Original Message----- > >> From: John G. Scudder [mailto:jgs@juniper.net] > >> Sent: Monday, June 27, 2016 11:53 AM > >> To: Jakob Heitz (jheitz) > >> Cc: Enke Chen (enkechen) ; idr@ietf.org; rtg-dir@i= etf.org; draft-ietf-idr-ext-opt- > param@ietf.org; > >> Bocci, Matthew (Nokia - GB) ; Susan Hares > >> Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext= -opt-param-04 > >> > >> On Jun 27, 2016, at 1:26 PM, Jakob Heitz (jheitz) w= rote: > >>>> -----Original Message----- > >>>> From: John G. Scudder [mailto:jgs@juniper.net] > >>>> Sent: Monday, June 27, 2016 9:25 AM > >>>> To: Jakob Heitz (jheitz) > >>>> Cc: Enke Chen (enkechen) ; idr@ietf.org; rtg-dir= @ietf.org; draft-ietf-idr-ext-opt- > >> param@ietf.org; > >>>> Bocci, Matthew (Nokia - GB) ; Susan Hares <= shares@ndzh.com> > >>>> Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-e= xt-opt-param-04 > >>>> > >>>> On Jun 26, 2016, at 7:39 PM, Jakob Heitz (jheitz) = wrote: > >>>>> > >>>>> "An optional parameter with parameter type of 0xFF MUST NOT appear = in the > >>>>> list of optional parameters other than in first place and if it doe= s appear, > >>>>> then the optional parameters length MUST be 0xFF." > >>>> > >>>> And it's a fatal error if it's not? > >>> > >>> Absolutely. As you say, the session is not up yet. > >> > >> I don't really mind doing this. I also don't mind not doing it, since = it's basically a superfluous check -- the > >> Optional Parameter Type is sufficient to fully determine that the mess= age uses the extended format. My slight > >> preference is for not doing it, since it's a few more lines of code (f= or the check), for a condition that is > >> exceedingly unlikely to occur, and doesn't matter if it does occur. So= why spend the code? > >> > >>>> (Remember this is before the session becomes established, so the pri= nciple of service survival above all that > >> would > >>>> applied in the error-handling spec doesn't apply.) > >>>> > >>>>> There is really no reason to entertain other combinations and I don= 't > >>>>> want to have to write code to handle them. > >>>> > >>>> Is there some reason insisting that the non-extended length field be= 255 is better than ignoring it once you've > >>>> determined by inspection of the non-extended parameter type that the= extended encoding is in use? The logic > would > >> be, > >>>> if the (one byte, non-extended) parameter type =3D 255, then use the= extended encoding, and ignore the one byte > >> non- > >>>> extended length field. > >>>> > >>>> If we made this change, the spec would say, MUST send non-extended l= ength as 255, MUST ignore on receipt if the > >>>> following eight bits (the non-extended type field) are 255. > >>> > >>> To Enke's point, can we make the non-extended length at least 1? > >>> Legacy speakers... > >> > >> Yes, you will see my suggestion was to make the length 255 on Tx (as y= ou and Enke point out, it has to be >=3D 1, > so > >> might as well choose 255 as any other value, and it jumps out nicely i= n a packet dump). Up for discussion was > >> whether to enforce the value on Rx, or ignore. You've spoken in favor = of enforcing it, although I'm not sure what > >> the reason for your preference is. > >> > >>> In addition: An otional parameter of type 255 MUST NOT appear in the > >>> list of optional parameters other than in first place. > >> > >> Good point, thanks. I'll work something like that in. > >> > >>> Should we set a maximum length of 4k? > >>> There will always be smaller boxes wishing to speak BGP that will nev= er support extended messages. > >> > >> I'm inclined to leave this alone -- if you can fit in <=3D 4k you will= . If you can't fit in <=3D 4k, a peering with > such > >> a box isn't going to work regardless. So either it'll be fine anyway, = or it won't work nohow. > >> > >> --John From nobody Wed Jun 29 09:02:26 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF7312D0CA; Wed, 29 Jun 2016 09:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftHCrF2hd7Xc; Wed, 29 Jun 2016 09:02:22 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417A112D0B7; Wed, 29 Jun 2016 09:02:22 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 186C537CF4630; Wed, 29 Jun 2016 16:02:17 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5TG2J1w029074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Jun 2016 16:02:19 GMT 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 u5TG2JHj015327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jun 2016 18:02:19 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 29 Jun 2016 18:02:19 +0200 From: "Bocci, Matthew (Nokia - GB)" To: "Jakob Heitz (jheitz)" , "John G. Scudder" , "idr@ietf.org" Thread-Topic: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 Thread-Index: AQHR0JkNQ2EumhUfXkqi/h1EnVMOxZ/9h3OAgAAIxwCAAgY2gIAABGsAgADyZoA= Date: Wed, 29 Jun 2016 16:02:19 +0000 Message-ID: References: <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> <56a07f338f5d4a1f8dfd539040b1002e@XCH-ALN-014.cisco.com> <2FBB796F-76B7-4F5F-B183-62A1FCA30313@juniper.net> <19F86A8D-2414-42BB-B289-ED84AB945DEE@juniper.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: <41BDFAEE5439614BA2700A183E900244@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-ext-opt-param@ietf.org" , Susan Hares Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 16:02:25 -0000 TG9va3MgZ29vZCB0byBtZSB0b28uIFRoYW5rIHlvdSBmb3IgYWRkcmVzc2luZyBteSBjb21tZW50 cy4NCg0KTWF0dGhldw0KDQpPbiAyOS8wNi8yMDE2LCAwMzozNCwgIkpha29iIEhlaXR6IChqaGVp dHopIiA8amhlaXR6QGNpc2NvLmNvbT4gd3JvdGU6DQoNCkxvb2tzIGdvb2QgdG8gbWUuDQoNClRo YW5rcywNCkpha29iLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpv aG4gRy4gU2N1ZGRlciBbbWFpbHRvOmpnc0BqdW5pcGVyLm5ldF0NCj4gU2VudDogVHVlc2RheSwg SnVuZSAyOCwgMjAxNiA3OjE5IFBNDQo+IFRvOiBpZHJAaWV0Zi5vcmcNCj4gQ2M6IEVua2UgQ2hl biAoZW5rZWNoZW4pIDxlbmtlY2hlbkBjaXNjby5jb20+OyBkcmFmdC1pZXRmLWlkci1leHQtb3B0 LXBhcmFtQGlldGYub3JnOyBCb2NjaSwgTWF0dGhldyAoTm9raWEgLSBHQikNCj4gPG1hdHRoZXcu Ym9jY2lAbm9raWEuY29tPjsgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT47IEpha29iIEhl aXR6IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPg0KPiBTdWJqZWN0OiBSZTogW0lkcl0gUm91 dGluZyBkaXJlY3RvcmF0ZSBRQSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pZHItZXh0LW9wdC1wYXJh bS0wNA0KPiANCj4gW3JlbW92ZWQgcnRnLWRpciBmcm9tIGNjLCBzZWVtZWQgZXhjZXNzaXZlXQ0K PiANCj4gLTA1IHBvc3RlZCB3aGljaCBJIGJlbGlldmUgYWRkcmVzc2VzIGFsbCBjb21tZW50cyB0 byBkYXRlLiBQbGVhc2UgdGFrZSBhIGxvb2suIEkndmUgYWRqdXN0ZWQgdGhlIGRpYWdyYW0gcGVy IChteQ0KPiB1bmRlcnN0YW5kaW5nIG9mKSBNYXR0aGV3J3MgY29tbWVudHMuIEknbSBhbWJpdmFs ZW50IGFib3V0IGl0IC0tIEknbSBub3Qgc3VyZSBpdCdzIGNsZWFyZXIsIGJ1dCBJIGRpZCBtYW5h Z2UgdG8NCj4gaW5jcmVhc2UgdGhlIHBhZ2UgY291bnQgOi1vLiBJIGNvdWxkIGdvIGVpdGhlciB3 YXksIGlmIHlvdSBoYXZlIGEgZGlzdGluY3QgcHJlZmVyZW5jZSBwbGVhc2Ugc2F5IHNvLg0KPiAN Cj4gLS1Kb2huDQo+IA0KPiA+IE9uIEp1biAyNywgMjAxNiwgYXQgMzoyNCBQTSwgSmFrb2IgSGVp dHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb20+IHdyb3RlOg0KPiA+DQo+ID4gRmluZS4gV29y a3MgZm9yIG1lLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IEpha29iLg0KPiA+DQo+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEpvaG4gRy4gU2N1ZGRlciBbbWFpbHRv Ompnc0BqdW5pcGVyLm5ldF0NCj4gPj4gU2VudDogTW9uZGF5LCBKdW5lIDI3LCAyMDE2IDExOjUz IEFNDQo+ID4+IFRvOiBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbT4NCj4g Pj4gQ2M6IEVua2UgQ2hlbiAoZW5rZWNoZW4pIDxlbmtlY2hlbkBjaXNjby5jb20+OyBpZHJAaWV0 Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWRyLWV4dC1vcHQtDQo+IHBhcmFt QGlldGYub3JnOw0KPiA+PiBCb2NjaSwgTWF0dGhldyAoTm9raWEgLSBHQikgPG1hdHRoZXcuYm9j Y2lAbm9raWEuY29tPjsgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4NCj4gPj4gU3ViamVj dDogUmU6IFtJZHJdIFJvdXRpbmcgZGlyZWN0b3JhdGUgUUEgcmV2aWV3IG9mIGRyYWZ0LWlldGYt aWRyLWV4dC1vcHQtcGFyYW0tMDQNCj4gPj4NCj4gPj4gT24gSnVuIDI3LCAyMDE2LCBhdCAxOjI2 IFBNLCBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBKb2huIEcuIFNjdWRk ZXIgW21haWx0bzpqZ3NAanVuaXBlci5uZXRdDQo+ID4+Pj4gU2VudDogTW9uZGF5LCBKdW5lIDI3 LCAyMDE2IDk6MjUgQU0NCj4gPj4+PiBUbzogSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBj aXNjby5jb20+DQo+ID4+Pj4gQ2M6IEVua2UgQ2hlbiAoZW5rZWNoZW4pIDxlbmtlY2hlbkBjaXNj by5jb20+OyBpZHJAaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWRyLWV4 dC1vcHQtDQo+ID4+IHBhcmFtQGlldGYub3JnOw0KPiA+Pj4+IEJvY2NpLCBNYXR0aGV3IChOb2tp YSAtIEdCKSA8bWF0dGhldy5ib2NjaUBub2tpYS5jb20+OyBTdXNhbiBIYXJlcyA8c2hhcmVzQG5k emguY29tPg0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbSWRyXSBSb3V0aW5nIGRpcmVjdG9yYXRlIFFB IHJldmlldyBvZiBkcmFmdC1pZXRmLWlkci1leHQtb3B0LXBhcmFtLTA0DQo+ID4+Pj4NCj4gPj4+ PiBPbiBKdW4gMjYsIDIwMTYsIGF0IDc6MzkgUE0sIEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVp dHpAY2lzY28uY29tPiB3cm90ZToNCj4gPj4+Pj4NCj4gPj4+Pj4gIkFuIG9wdGlvbmFsIHBhcmFt ZXRlciB3aXRoIHBhcmFtZXRlciB0eXBlIG9mIDB4RkYgTVVTVCBOT1QgYXBwZWFyIGluIHRoZQ0K PiA+Pj4+PiBsaXN0IG9mIG9wdGlvbmFsIHBhcmFtZXRlcnMgb3RoZXIgdGhhbiBpbiBmaXJzdCBw bGFjZSBhbmQgaWYgaXQgZG9lcyBhcHBlYXIsDQo+ID4+Pj4+IHRoZW4gdGhlIG9wdGlvbmFsIHBh cmFtZXRlcnMgbGVuZ3RoIE1VU1QgYmUgMHhGRi4iDQo+ID4+Pj4NCj4gPj4+PiBBbmQgaXQncyBh IGZhdGFsIGVycm9yIGlmIGl0J3Mgbm90Pw0KPiA+Pj4NCj4gPj4+IEFic29sdXRlbHkuIEFzIHlv dSBzYXksIHRoZSBzZXNzaW9uIGlzIG5vdCB1cCB5ZXQuDQo+ID4+DQo+ID4+IEkgZG9uJ3QgcmVh bGx5IG1pbmQgZG9pbmcgdGhpcy4gSSBhbHNvIGRvbid0IG1pbmQgbm90IGRvaW5nIGl0LCBzaW5j ZSBpdCdzIGJhc2ljYWxseSBhIHN1cGVyZmx1b3VzIGNoZWNrIC0tIHRoZQ0KPiA+PiBPcHRpb25h bCBQYXJhbWV0ZXIgVHlwZSBpcyBzdWZmaWNpZW50IHRvIGZ1bGx5IGRldGVybWluZSB0aGF0IHRo ZSBtZXNzYWdlIHVzZXMgdGhlIGV4dGVuZGVkIGZvcm1hdC4gTXkgc2xpZ2h0DQo+ID4+IHByZWZl cmVuY2UgaXMgZm9yIG5vdCBkb2luZyBpdCwgc2luY2UgaXQncyBhIGZldyBtb3JlIGxpbmVzIG9m IGNvZGUgKGZvciB0aGUgY2hlY2spLCBmb3IgYSBjb25kaXRpb24gdGhhdCBpcw0KPiA+PiBleGNl ZWRpbmdseSB1bmxpa2VseSB0byBvY2N1ciwgYW5kIGRvZXNuJ3QgbWF0dGVyIGlmIGl0IGRvZXMg b2NjdXIuIFNvIHdoeSBzcGVuZCB0aGUgY29kZT8NCj4gPj4NCj4gPj4+PiAoUmVtZW1iZXIgdGhp cyBpcyBiZWZvcmUgdGhlIHNlc3Npb24gYmVjb21lcyBlc3RhYmxpc2hlZCwgc28gdGhlIHByaW5j aXBsZSBvZiBzZXJ2aWNlIHN1cnZpdmFsIGFib3ZlIGFsbCB0aGF0DQo+ID4+IHdvdWxkDQo+ID4+ Pj4gYXBwbGllZCBpbiB0aGUgZXJyb3ItaGFuZGxpbmcgc3BlYyBkb2Vzbid0IGFwcGx5LikNCj4g Pj4+Pg0KPiA+Pj4+PiBUaGVyZSBpcyByZWFsbHkgbm8gcmVhc29uIHRvIGVudGVydGFpbiBvdGhl ciBjb21iaW5hdGlvbnMgYW5kIEkgZG9uJ3QNCj4gPj4+Pj4gd2FudCB0byBoYXZlIHRvIHdyaXRl IGNvZGUgdG8gaGFuZGxlIHRoZW0uDQo+ID4+Pj4NCj4gPj4+PiBJcyB0aGVyZSBzb21lIHJlYXNv biBpbnNpc3RpbmcgdGhhdCB0aGUgbm9uLWV4dGVuZGVkIGxlbmd0aCBmaWVsZCBiZSAyNTUgaXMg YmV0dGVyIHRoYW4gaWdub3JpbmcgaXQgb25jZSB5b3UndmUNCj4gPj4+PiBkZXRlcm1pbmVkIGJ5 IGluc3BlY3Rpb24gb2YgdGhlIG5vbi1leHRlbmRlZCBwYXJhbWV0ZXIgdHlwZSB0aGF0IHRoZSBl eHRlbmRlZCBlbmNvZGluZyBpcyBpbiB1c2U/IFRoZSBsb2dpYw0KPiB3b3VsZA0KPiA+PiBiZSwN Cj4gPj4+PiBpZiB0aGUgKG9uZSBieXRlLCBub24tZXh0ZW5kZWQpIHBhcmFtZXRlciB0eXBlID0g MjU1LCB0aGVuIHVzZSB0aGUgZXh0ZW5kZWQgZW5jb2RpbmcsIGFuZCBpZ25vcmUgdGhlIG9uZSBi eXRlDQo+ID4+IG5vbi0NCj4gPj4+PiBleHRlbmRlZCBsZW5ndGggZmllbGQuDQo+ID4+Pj4NCj4g Pj4+PiBJZiB3ZSBtYWRlIHRoaXMgY2hhbmdlLCB0aGUgc3BlYyB3b3VsZCBzYXksIE1VU1Qgc2Vu ZCBub24tZXh0ZW5kZWQgbGVuZ3RoIGFzIDI1NSwgTVVTVCBpZ25vcmUgb24gcmVjZWlwdCBpZiB0 aGUNCj4gPj4+PiBmb2xsb3dpbmcgZWlnaHQgYml0cyAodGhlIG5vbi1leHRlbmRlZCB0eXBlIGZp ZWxkKSBhcmUgMjU1Lg0KPiA+Pj4NCj4gPj4+IFRvIEVua2UncyBwb2ludCwgY2FuIHdlIG1ha2Ug dGhlIG5vbi1leHRlbmRlZCBsZW5ndGggYXQgbGVhc3QgMT8NCj4gPj4+IExlZ2FjeSBzcGVha2Vy cy4uLg0KPiA+Pg0KPiA+PiBZZXMsIHlvdSB3aWxsIHNlZSBteSBzdWdnZXN0aW9uIHdhcyB0byBt YWtlIHRoZSBsZW5ndGggMjU1IG9uIFR4IChhcyB5b3UgYW5kIEVua2UgcG9pbnQgb3V0LCBpdCBo YXMgdG8gYmUgPj0gMSwNCj4gc28NCj4gPj4gbWlnaHQgYXMgd2VsbCBjaG9vc2UgMjU1IGFzIGFu eSBvdGhlciB2YWx1ZSwgYW5kIGl0IGp1bXBzIG91dCBuaWNlbHkgaW4gYSBwYWNrZXQgZHVtcCku IFVwIGZvciBkaXNjdXNzaW9uIHdhcw0KPiA+PiB3aGV0aGVyIHRvIGVuZm9yY2UgdGhlIHZhbHVl IG9uIFJ4LCBvciBpZ25vcmUuIFlvdSd2ZSBzcG9rZW4gaW4gZmF2b3Igb2YgZW5mb3JjaW5nIGl0 LCBhbHRob3VnaCBJJ20gbm90IHN1cmUgd2hhdA0KPiA+PiB0aGUgcmVhc29uIGZvciB5b3VyIHBy ZWZlcmVuY2UgaXMuDQo+ID4+DQo+ID4+PiBJbiBhZGRpdGlvbjogQW4gb3Rpb25hbCBwYXJhbWV0 ZXIgb2YgdHlwZSAyNTUgTVVTVCBOT1QgYXBwZWFyIGluIHRoZQ0KPiA+Pj4gbGlzdCBvZiBvcHRp b25hbCBwYXJhbWV0ZXJzIG90aGVyIHRoYW4gaW4gZmlyc3QgcGxhY2UuDQo+ID4+DQo+ID4+IEdv b2QgcG9pbnQsIHRoYW5rcy4gSSdsbCB3b3JrIHNvbWV0aGluZyBsaWtlIHRoYXQgaW4uDQo+ID4+ DQo+ID4+PiBTaG91bGQgd2Ugc2V0IGEgbWF4aW11bSBsZW5ndGggb2YgNGs/DQo+ID4+PiBUaGVy ZSB3aWxsIGFsd2F5cyBiZSBzbWFsbGVyIGJveGVzIHdpc2hpbmcgdG8gc3BlYWsgQkdQIHRoYXQg d2lsbCBuZXZlciBzdXBwb3J0IGV4dGVuZGVkIG1lc3NhZ2VzLg0KPiA+Pg0KPiA+PiBJJ20gaW5j bGluZWQgdG8gbGVhdmUgdGhpcyBhbG9uZSAtLSBpZiB5b3UgY2FuIGZpdCBpbiA8PSA0ayB5b3Ug d2lsbC4gSWYgeW91IGNhbid0IGZpdCBpbiA8PSA0aywgYSBwZWVyaW5nIHdpdGgNCj4gc3VjaA0K PiA+PiBhIGJveCBpc24ndCBnb2luZyB0byB3b3JrIHJlZ2FyZGxlc3MuIFNvIGVpdGhlciBpdCds bCBiZSBmaW5lIGFueXdheSwgb3IgaXQgd29uJ3Qgd29yayBub2hvdy4NCj4gPj4NCj4gPj4gLS1K b2huDQoNCg0KDQo= From nobody Wed Jun 29 14:54:40 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F8212D1B1; Wed, 29 Jun 2016 14:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdWCqEsqnMrq; Wed, 29 Jun 2016 14:54:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0390C12D520; Wed, 29 Jun 2016 14:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6467; q=dns/txt; s=iport; t=1467237259; x=1468446859; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Xe1cViduwIw5ob90+BdbWNq02SqvZ5ah2FF9WwQ84n4=; b=P9sklwPZMIYZQGh5QfBQeSex1wq+BBW1Q7KHgyRnETPzxvTyPNfKwQpz ehXsxGYtFvSyOBnZG39GUBuIDQWaLscwerJUbHLOXkeKHHhhfBGSGm+Pn RYb0JbeLp4O9M+w7oprwNqpNLOpxaU3nfI5Eb1TwXSa5umc9zYbphzFBI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQDVQnRX/5FdJa1bgz6BUwa3N4IPg?= =?us-ascii?q?XuGGAKBNDgUAQEBAQEBAWUnhE0BAQQ6PxACAQgYHhAyJQIEDgWIMMM5AQEBAQE?= =?us-ascii?q?BAQMBAQEBAQEBAR+GKIRNihsBBJNQhTUBjj2BaYRUiGiQAgEeNoI7gTVuiEl/A?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.26,548,1459814400"; d="scan'208";a="123308965" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2016 21:54:18 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5TLsH44024560 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 21:54:18 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Jun 2016 16:54:17 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 29 Jun 2016 16:54:17 -0500 From: "Alvaro Retana (aretana)" To: Jari Arkko Thread-Topic: Jari Arkko's Discuss on draft-ietf-idr-route-oscillation-stop-03: (with DISCUSS and COMMENT) Thread-Index: AQHRprRTmhXdCvFQWUW3H4yt0d2g+J+qizoAgByzwQCAOiXpgA== Date: Wed, 29 Jun 2016 21:54:17 +0000 Message-ID: References: <20160505095556.15385.64588.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-idr-route-oscillation-stop@ietf.org" , "idr@ietf.org" , "idr-chairs@ietf.org" , "pkyzivat@alum.mit.edu" , The IESG , Susan Hares Subject: Re: [Idr] Jari Arkko's Discuss on draft-ietf-idr-route-oscillation-stop-03: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 21:54:32 -0000 Ping! On 5/23/16, 5:55 PM, "Alvaro Retana (aretana)" wrote: >On 5/5/16, 11:36 AM, "Alvaro Retana (aretana)" wrote: > >Jari: > >Hi! Took me longer than I thought... > >Please see below and let me know if you think it is clearer -- I'll then >include it in the next version. > >Thanks! > >Alvaro. > > >>> >>> >>> >>>>When the ADD-PATH Capability is also received from >>>>the IBGP peer with the "Send/Receive" field set to 1 (receive >>>>multiple paths) or 3 (send/receive multiple paths) for the same >>>SAFI>, then the following procedures shall be followed: >>>>If the peer is a route reflection client, the route reflector SHOULD >>>>advertise to the peer the Group Best Paths (or the Available Paths) >>>>received from its non-client IBGP peers. Depending on the >>>>configuration, the route reflector MAY also advertise to the peer the >>>>Group Best Paths (or the Available Paths) received from its clients. >>> >>>I am picking this text excerpt as an example. >>> >>>Like Paul, some of this language makes me slightly uncomfortable, >>>and it would be good to understand what the aim is. If the intent >>>is to describe a procedure that can be followed and fully specified, >>>the expectations on the text are different from an informative >>>description of the kinds of things an implementation could do. >>> >>>In the above text, there's quite a lot of imprecision. That may >>>be fine, but I wanted to check that this is the case. >>> >>>For instance, why is a "shall" (and in lowercase) followed by >>>a set of "SHOULD"s and "MAY"s? Is there any guidance on >>>when the "SHOULD"s should be followed? There seems to >>>be thinking behind, could that be documented? What kind >>>of configuration issues affect the decisions? >> >>Yes, I see what you mean. I think that at the time we wrote the text we >>were probably thinking in terms of "SHOULD" because this is one of the >>options (Group Best Paths vs All the Paths), but within that option we >>can >>be more precise. >> >>We will work on clarifying and get back to you -- I'm traveling, so it >>might take a couple of days. > > >OLD> >5.1. Route Reflection > > Depending on the configuration, for a particular a route > reflector SHOULD include the with the "Send/Receive" > field set to 2 (send multiple paths) or 3 (send/receive multiple > paths) in the ADD-PATH Capability [I-D.ietf-idr-add-paths] advertised > to an IBGP peer. When the ADD-PATH Capability is also received from > the IBGP peer with the "Send/Receive" field set to 1 (receive > multiple paths) or 3 (send/receive multiple paths) for the same SAFI>, then the following procedures shall be followed: > > If the peer is a route reflection client, the route reflector SHOULD > advertise to the peer the Group Best Paths (or the Available Paths) > received from its non-client IBGP peers. Depending on the > configuration, the route reflector MAY also advertise to the peer the > Group Best Paths (or the Available Paths) received from its clients. > > If the peer is a non-client, the route reflector SHOULD advertise to > the peer the Group Best Paths (or the Available Paths) received from > its clients. > >5.2. Confederation > > Depending on the configuration, for a particular a > confederation ASBR SHOULD include the with the "Send/ > Receive" field set to 2 (send multiple paths) or 3 (send/receive > multiple paths) in the ADD-PATH Capability [I-D.ietf-idr-add-paths] > advertised to an IBGP peer, and to a confederation external peer. > When the ADD-PATH Capability is also received from the IBGP peer or > the confederation external peer with the "Send/Receive" field set to > 1 (receive multiple paths) or 3 (send/receive multiple paths) for the > same , then the following procedures shall be followed: > > If the peer is internal, the confederation ASBR SHOULD advertise to > the peer the Group Best Paths (or the Available Paths) received from > its confederation external peers. > > If the peer is confederation external, the confederation ASBR SHOULD > advertise to the peer the Group Best Paths (or the Available Paths) > received from its IBGP peers. > > > >NEW> >5.1. Route Reflection > > For a particular a route reflector MUST include the SAFI> with the "Send/Receive" field set to 2 (send multiple paths) or > 3 (send/receive multiple paths) in the ADD-PATH Capability > [I-D.ietf-idr-add-paths] advertised to an IBGP peer. When the ADD- > PATH Capability is also received from the IBGP peer with the "Send/ > Receive" field set to 1 (receive multiple paths) or 3 (send/receive > multiple paths) for the same , then the following > procedures apply: > > If the peer is a route reflection client, the route reflector MUST > advertise to the peer the Group Best Paths (or the Available Paths) > received from its non-client IBGP peers. The route reflector MAY > also advertise to the peer the Group Best Paths (or the Available > Paths) received from its clients. > > If the peer is a non-client, the route reflector MUST advertise to > the peer the Group Best Paths (or the Available Paths) received from > its clients. > >5.2. Confederation > > For a particular a confederation ASBR MUST include the > with the "Send/Receive" field set to 2 (send multiple > paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability > [I-D.ietf-idr-add-paths] advertised to an IBGP peer, and to a > confederation external peer. When the ADD-PATH Capability is also > received from the IBGP peer or the confederation external peer with > the "Send/Receive" field set to 1 (receive multiple paths) or 3 > (send/receive multiple paths) for the same , then the > following procedures apply: > > If the peer is internal, the confederation ASBR MUST advertise to the > peer the Group Best Paths (or the Available Paths) received from its > confederation external peers. > > If the peer is confederation external, the confederation ASBR MUST > advertise to the peer the Group Best Paths (or the Available Paths) > received from its IBGP peers. > > > > > > From nobody Wed Jun 29 15:24:08 2016 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0E612B056; Wed, 29 Jun 2016 15:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJPvraOmQ2lk; Wed, 29 Jun 2016 15:23:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8CF12B05A; Wed, 29 Jun 2016 15:23:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B62A62CCB0; Thu, 30 Jun 2016 01:23:57 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3l7S2z7_GWH; Thu, 30 Jun 2016 01:23:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 10C672CC64; Thu, 30 Jun 2016 01:23:57 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FC2CD879-E84E-4C01-A73A-9191512C9BAC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Jari Arkko In-Reply-To: Date: Thu, 30 Jun 2016 01:23:55 +0300 Message-Id: <462CD46B-24D4-4B64-969E-8CAD90654826@piuha.net> References: <20160505095556.15385.64588.idtracker@ietfa.amsl.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "draft-ietf-idr-route-oscillation-stop@ietf.org" , "idr@ietf.org" , "idr-chairs@ietf.org" , "pkyzivat@alum.mit.edu" , The IESG , Susan Hares Subject: Re: [Idr] Jari Arkko's Discuss on draft-ietf-idr-route-oscillation-stop-03: (with DISCUSS and COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 22:24:00 -0000 --Apple-Mail=_FC2CD879-E84E-4C01-A73A-9191512C9BAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alvaro - thank you. I think the changes you suggest are reasonable, and = certainly remove my questions. I have cleared and leave it to you to take the changes to the document = and/or vet them with the rest of the working group, as needed. Jari --Apple-Mail=_FC2CD879-E84E-4C01-A73A-9191512C9BAC 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 iQIcBAEBCgAGBQJXdEp7AAoJEM80gCTQU46q2dsP/RllMoKdtUvsrXiynRASztvN d/FPVBBNgQoqig4gMbL96C7XB0JbKml8PjpAeKRKL4T4fmJ8/62ThM++J6Tx1SIN D+2tJK2eUDgxCWau3wMrJNatNDxlIPng3Zl9c7KJlL/2L0RGhTJVVoP8BSkcvqHu Y4MG8J6NUjrZrDoTP7zpoZG/2DPjD64zxTSteTzbGUtHMY6kwWLyjUA4+o3KM+7S QLI+tUic3EigoTbIF5dIvtSTxo2h4eM5dk2+XlXQ0u90HnwtCn3as0yq6mtpeyCw rcZVOJ9Qze2dof887SVvSubsOTItAoJBIfrAD6zwD7+oQmTtSS91fFM4xumjxXsN 5Pv2F0nGHmCaT2tELX0FnTXJTCQzXotnP9dbgpH1LEDDu3NiyYU18nJpMIQp21Lg ar/XyGoY8BOOZtIh6tp55WqFpVe0fR+7JplF91a2YmkvnldZmfTGhYouPuGghNYR JH9q/DOHvKyV3y2WvL515hGCrY4aeAsHLGnCzhTSP/bLA5OapSDDOiDPlyCrAEsT E0wb17xI5Q8YS9d3xjiVx/Bd3m7mpKf1MFfAXWkLqKDTznvUS3YZkEwYmpy21p4r CX7hNV6NxAtoHxp4JYWlr9FQ5chQQJppgeqpGNo3rSdqktqS5OOx63SrLWEAhD/Z oV/+I70yA47z62gRBYKX =rE5O -----END PGP SIGNATURE----- --Apple-Mail=_FC2CD879-E84E-4C01-A73A-9191512C9BAC-- From nobody Thu Jun 30 08:29:49 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B4A12DA98; Thu, 30 Jun 2016 08:29:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160630152947.29546.95651.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2016 08:29:47 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ix-bgp-route-server-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 15:29:48 -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 of the IETF. Title : Internet Exchange BGP Route Server Authors : Elisa Jasinska Nick Hilliard Robert Raszuk Niels Bakker Filename : draft-ietf-idr-ix-bgp-route-server-12.txt Pages : 12 Date : 2016-06-30 Abstract: This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more external 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 among 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: https://tools.ietf.org/html/draft-ietf-idr-ix-bgp-route-server-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ix-bgp-route-server-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/