From Torunn.Narvestad@telenor.com Fri Apr 1 04:18:58 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A6F3A680E for ; Fri, 1 Apr 2011 04:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AAMUp2ieke9 for ; Fri, 1 Apr 2011 04:18:57 -0700 (PDT) Received: from sv02.e.nsc.no (vip1scan.telenor.net [148.123.15.75]) by core3.amsl.com (Postfix) with ESMTP id AF7B53A67F3 for ; Fri, 1 Apr 2011 04:18:57 -0700 (PDT) Received: from tns-fbu-22-250.corp.telenor.no ([134.47.162.19] [134.47.162.19]) by sv02.nsc.no with ESMTPS id BT-MMP-449840; Fri, 1 Apr 2011 13:20:39 +0200 Received: from TNS-FBU-2E-016.corp.telenor.no ([134.47.163.219]) by tns-fbu-22-250.corp.telenor.no ([134.47.162.19]) with mapi; Fri, 1 Apr 2011 13:20:34 +0200 From: To: , Date: Fri, 1 Apr 2011 13:20:33 +0200 Thread-Topic: [Idr] Dissemination of Flow Specification Rules for IPv6 Thread-Index: AcvvqBa5w6PZeDYzSb69kKM7QSpRlQAtrKlA Message-ID: <6269ED7E9CBCE3499B62B7FCDD4BE8841B66BB9F31@TNS-FBU-2E-016.corp.telenor.no> References: <4D94823E.9070806@cisco.com> In-Reply-To: <4D94823E.9070806@cisco.com> Accept-Language: nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] Dissemination of Flow Specification Rules for IPv6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:18:58 -0000 +1 - Torunn -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: 31. mars 2011 15:32 To: idr@ietf.org List Subject: [Idr] Dissemination of Flow Specification Rules for IPv6 Authors of "Dissemination of Flow Specification Rules for IPv6" draft=20 document would like to propose the adoption of this work as the IDR WG item= . Ref: http://tools.ietf.org/html/draft-raszuk-idr-flow-spec-v6-01 Rgs, R. Raszuk B. Pithawala D. McPherson _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From christian.jacquenet@orange-ftgroup.com Fri Apr 1 04:24:44 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0711A3A6812 for ; Fri, 1 Apr 2011 04:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2mvZKvog8RF for ; Fri, 1 Apr 2011 04:24:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id C33C13A67F3 for ; Fri, 1 Apr 2011 04:24:42 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 2932C18C10C; Fri, 1 Apr 2011 13:26:22 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1156827C05B; Fri, 1 Apr 2011 13:26:22 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 1 Apr 2011 13:26:22 +0200 From: To: "raszuk@cisco.com" , "idr@ietf.org" Date: Fri, 1 Apr 2011 13:26:21 +0200 Thread-Topic: [Idr] Dissemination of Flow Specification Rules for IPv6 Thread-Index: AcvvqBa5w6PZeDYzSb69kKM7QSpRlQAtrKlAAAAwaUA= Message-ID: <32505_1301657182_4D95B65E_32505_550_1_983A1D8DA0DA5F4EB747BF34CBEE5CD14AE2A0812D@PUEXCB1C.nanterre.francetelecom.fr> References: <4D94823E.9070806@cisco.com> <6269ED7E9CBCE3499B62B7FCDD4BE8841B66BB9F31@TNS-FBU-2E-016.corp.telenor.no> In-Reply-To: <6269ED7E9CBCE3499B62B7FCDD4BE8841B66BB9F31@TNS-FBU-2E-016.corp.telenor.no> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.31.105417 Subject: Re: [Idr] Dissemination of Flow Specification Rules for IPv6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:24:44 -0000 Hi, I support the adoption of this draft as an idr WG item. Cheers, Christian.=20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: 31. mars 2011 15:32 To: idr@ietf.org List Subject: [Idr] Dissemination of Flow Specification Rules for IPv6 Authors of "Dissemination of Flow Specification Rules for IPv6" draft docum= ent would like to propose the adoption of this work as the IDR WG item. Ref: http://tools.ietf.org/html/draft-raszuk-idr-flow-spec-v6-01 Rgs, R. Raszuk B. Pithawala D. McPherson _______________________________________________ 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 ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From ljb@merit.edu Fri Apr 1 10:27:39 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7EDA3A690D for ; Fri, 1 Apr 2011 10:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERQBO4R2wcZJ for ; Fri, 1 Apr 2011 10:27:39 -0700 (PDT) Received: from int-mailstore01.merit.edu (int-mailstore01.merit.edu [207.75.116.232]) by core3.amsl.com (Postfix) with ESMTP id 5AAEB3A690C for ; Fri, 1 Apr 2011 10:27:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-mailstore01.merit.edu (Postfix) with ESMTP id 974ED30574F0 for ; Fri, 1 Apr 2011 13:29:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at int-mailstore01.merit.edu Received: from int-mailstore01.merit.edu ([127.0.0.1]) by localhost (int-mailstore01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6J7wzkPWotTJ for ; Fri, 1 Apr 2011 13:29:17 -0400 (EDT) Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151]) by int-mailstore01.merit.edu (Postfix) with ESMTPSA id 280B23057360 for ; Fri, 1 Apr 2011 13:29:17 -0400 (EDT) Message-ID: <4D960B6C.8070601@merit.edu> Date: Fri, 01 Apr 2011 13:29:16 -0400 From: Larry Blunk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: idr@ietf.org References: <201103310734.p2V7YCbx046854@harbor.orleans.occnc.com> <20110331085401.GD20140@slice> In-Reply-To: <20110331085401.GD20140@slice> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 17:27:39 -0000 On 03/31/2011 04:54 AM, Jeffrey Haas wrote: > O > > P.S. At the time I was becoming involved in BGP standards, the archives were > somewhat divided between Merit and, I think ANS? > _______________________________________________ > The following archives have a number of discussions on AS_SET's in BGP4. ftp://ftp.ietf.org/concluded-wg-ietf-mail-archive/bgp/ -Larry From jakob.heitz@ericsson.com Sat Apr 2 10:40:04 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1E33A6873 for ; Sat, 2 Apr 2011 10:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpO4LFtVLJ98 for ; Sat, 2 Apr 2011 10:40:03 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id E2D663A685B for ; Sat, 2 Apr 2011 10:40:02 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p32HfhwL029681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 2 Apr 2011 12:41:43 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 2 Apr 2011 13:41:42 -0400 From: Jakob Heitz To: idr Date: Sat, 2 Apr 2011 13:41:45 -0400 Thread-Topic: draft-retana-bgp-custom-decision-01: compare from different AS Thread-Index: AcvxXTpbvqRelUTnQ+eGmgDN/DJcfQ== Message-ID: References: <8249B703AE8442429AF89B86E8206AA26EF567C36F@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <8249B703AE8442429AF89B86E8206AA26EF567C36F@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] draft-retana-bgp-custom-decision-01: compare from different AS X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 17:40:04 -0000 Was there a discussion among the authors about the merit of a rule like for= the med not to compare values of the transitive cost community received fr= om different AS's? Could you summarize the discussions please? -- Jakob Heitz.= From raszuk@cisco.com Sat Apr 2 10:58:14 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240503A687A for ; Sat, 2 Apr 2011 10:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 211d5L+7s7cz for ; Sat, 2 Apr 2011 10:58:12 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C272A3A6877 for ; Sat, 2 Apr 2011 10:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=790; q=dns/txt; s=iport; t=1301767194; x=1302976794; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9i61vsn1GZ5TzyNIHHsey4oAaVXYPkT5IQ7AjBm07iM=; b=Kkv7TEAmg9CeXChFVPI5zCsjYi1FU+nuIdhi42OL6+LfZx/23FUzDifO NNmV+kZv+nGjwIjIcENY4aKY5IWO8ITvkQPXIYOIJ0Twp23Xewpbj11If V7G0HMC6ZqGA3M3M/kFJY/pDQ190S+YUWdwX331047Pezv+OMB27cFNul 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIBjl02rRDoI/2dsb2JhbAClY3eIeZpZgnAOAZhRhWsEjSODWw X-IronPort-AV: E=Sophos;i="4.63,288,1299456000"; d="scan'208";a="329558606" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 02 Apr 2011 17:59:54 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p32Hxqdq010392; Sat, 2 Apr 2011 17:59:53 GMT Message-ID: <4D97642A.2050908@cisco.com> Date: Sat, 02 Apr 2011 20:00:10 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jakob Heitz References: <8249B703AE8442429AF89B86E8206AA26EF567C36F@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-retana-bgp-custom-decision-01: compare from different AS X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 17:58:14 -0000 Hi Jakob, IMHO we should learn form the past (read: MED experience) and when allowing for a given cost community to be transitive across ASes it's definition should very clearly indicate that in the event of using potentially different ranges of values they must be normalized to be able to be comparable in each AS they are transmitted to without necessity of any additional grouping. Cheers, R. > Was there a discussion among the authors about the merit of a rule > like for the med not to compare values of the transitive cost > community received from different AS's? Could you summarize the > discussions please? > > -- Jakob Heitz. _______________________________________________ Idr > mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > From jakob.heitz@ericsson.com Sat Apr 2 11:01:48 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92EF23A687C for ; Sat, 2 Apr 2011 11:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka2yGYIoYUBA for ; Sat, 2 Apr 2011 11:01:47 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 831883A687B for ; Sat, 2 Apr 2011 11:01:47 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p32I3RRI029984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Apr 2011 13:03:27 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 2 Apr 2011 14:03:26 -0400 From: Jakob Heitz To: idr , Ahmed Bashandy Date: Sat, 2 Apr 2011 14:03:28 -0400 Thread-Topic: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? Thread-Index: AcvxYENfLQojkhZRQ5Co4o05FUWwOw== Message-ID: <082705C2-349C-4837-8E30-D5F9F6987FE4@ericsson.com> References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> In-Reply-To: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 18:01:48 -0000 I think the draft needs to state that a received native IP packet is NEVER = sent using the repair label. Specifically, if the IP path to the CE is brok= en, a packet received as a native IP packet shoul be sent to the PE next ho= p using the regular label, not the repair label. The repair label should on= ly be used for packets received from MPLS.=20 -- Jakob Heitz. On Mar 31, 2011, at 2:38 AM, "Jakob Heitz" wrote= : > After the link to the CE fails, the PE1 uses the repair label to send to = PE2. > If the link to the CE is never restored, does PE1 ever use the regular la= bel again? >=20 > Suppose the CE is first attached to PE1 and PE2. > Then it detaches from PE1 and attaches to PE3. > It will never reattach to PE1. >=20 > Now, PE1 is stuck using the repair label to PE2. >=20 > -- > Jakob Heitz. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Sat Apr 2 11:13:30 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C3528C122 for ; Sat, 2 Apr 2011 11:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eYcTcEokfjD for ; Sat, 2 Apr 2011 11:13:30 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0483928C103 for ; Sat, 2 Apr 2011 11:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=971; q=dns/txt; s=iport; t=1301768111; x=1302977711; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tGJj9ggqQpU5Dl83vdO9zDgZyOx1riEpA8A1zBGIYj4=; b=eFjGrAvgE+RYnOIZ5BGW1yW+fIDu8LAu4Cf/DYvaLeCiKwFzbwZ5U5fl 230BeFW25bTb9FyIaSe7xVJjWZQOn2CFj3EAoyR/wQi8/Aounoq2AevGU MCS50zDatghbRVoCsfsQfARvFBQ6lcZR4rxeVpJtFMwtMZV2W6gBo7usD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAANnl02rRDoI/2dsb2JhbAClY3eIeZpJgnAOAZhShWsEjSODWw X-IronPort-AV: E=Sophos;i="4.63,288,1299456000"; d="scan'208";a="329561372" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 02 Apr 2011 18:15:11 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p32IFANL017562; Sat, 2 Apr 2011 18:15:10 GMT Message-ID: <4D9767BF.1060205@cisco.com> Date: Sat, 02 Apr 2011 20:15:27 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jakob Heitz References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> In-Reply-To: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 18:13:30 -0000 Hi Jakob, > After the link to the CE fails, the PE1 uses the repair label to send to PE2. > If the link to the CE is never restored, does PE1 ever use the regular label again? > > Suppose the CE is first attached to PE1 and PE2. > Then it detaches from PE1 and attaches to PE3. > It will never reattach to PE1. > > Now, PE1 is stuck using the repair label to PE2. Not at all :) The repair label of CE-PE2 is used as a backup path for CE-PE1 primary best path on PE1. When the on the PE1 the link to CE fails we will switch to use backup only for the duration it takes routing protocol to remove the primary path CE-PE1 reachability and make the CE-PE2 as best path. Keep in mind that we are protecting the best path of the net not the net itself. Then such best will be unprotected till we get a new path via CE-PE3 and install it as backup or till the link comes up again and new best path CE-PE1 will be installed. Cheers, R. From raszuk@cisco.com Sat Apr 2 11:23:56 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95303A6879 for ; Sat, 2 Apr 2011 11:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn-n0uMB8KiV for ; Sat, 2 Apr 2011 11:23:56 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 03F493A6878 for ; Sat, 2 Apr 2011 11:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1075; q=dns/txt; s=iport; t=1301768737; x=1302978337; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nc0AiGk9+fP2kM76FKA7vE/RtNGDuBWrdg2b4NNJBvw=; b=ANUbTXgjZbJfW+oJQuxs1oB91ubx1lkdr7DBDYL1wzqRFOR32IehIVcd xwL4ZRY5O+Fx7EExXaAdHwIR7WdSkqSrtiEvDDCPFRiUKqKOq3Uc88p5z Q6xQ37kYA/wFxZaeAC2rscHtOTHgJQj03MRUIoMbmdftnTPbfdpUmwbGB A=; X-IronPort-AV: E=Sophos;i="4.63,288,1299456000"; d="scan'208";a="288063404" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2011 18:25:37 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p32IPZwX016602; Sat, 2 Apr 2011 18:25:36 GMT Message-ID: <4D976A31.4080407@cisco.com> Date: Sat, 02 Apr 2011 20:25:53 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jakob Heitz References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> <082705C2-349C-4837-8E30-D5F9F6987FE4@ericsson.com> In-Reply-To: <082705C2-349C-4837-8E30-D5F9F6987FE4@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 18:23:57 -0000 Hi Jakob, > I think the draft needs to state that a received native IP packet is > NEVER sent using the repair label. Specifically, if the IP path to > the CE is broken, a packet received as a native IP packet shoul be > sent to the PE next hop using the regular label, not the repair > label. The repair label should only be used for packets received from > MPLS. The draft already states this: In a BGP free core, where traffic is tunneled between edge routers and edge routers assign labels to prefixes, BGP speakers advertise reachability information about prefixes and associate a local label with each prefix such as L3VPN [9], 6PE [10], and Softwire [8]. But thinking further I do not see perhaps anything wrong on attaching this attribute to unicast IPv4 and IPv6 AFIs where ASBRs and network between them are MPLS enabled. In fact if we would explicitly permit this in draft-bashandy-idr-bgp-repair-label it will automatically address the problem as described in draft-xu-idr-best-external-loop-avoidance. Thx, R. From jakob.heitz@ericsson.com Sat Apr 2 13:06:22 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E273A689F for ; Sat, 2 Apr 2011 13:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHEZWNwntGbD for ; Sat, 2 Apr 2011 13:06:21 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 8FB853A6840 for ; Sat, 2 Apr 2011 13:06:21 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p32K7xq0018342; Sat, 2 Apr 2011 15:08:00 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sat, 2 Apr 2011 16:07:54 -0400 From: Jakob Heitz To: "raszuk@cisco.com" Date: Sat, 2 Apr 2011 16:07:55 -0400 Thread-Topic: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? Thread-Index: AcvxcaZrgqhHY14eRuGbwGmAGTL7Zg== Message-ID: References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> <082705C2-349C-4837-8E30-D5F9F6987FE4@ericsson.com> <4D976A31.4080407@cisco.com> In-Reply-To: <4D976A31.4080407@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 20:06:22 -0000 Your comment is orthogonal to mine.=20 -- Jakob Heitz. On Apr 2, 2011, at 11:25 AM, "Robert Raszuk" wrote: > Hi Jakob, >=20 >> I think the draft needs to state that a received native IP packet is >> NEVER sent using the repair label. Specifically, if the IP path to >> the CE is broken, a packet received as a native IP packet shoul be >> sent to the PE next hop using the regular label, not the repair >> label. The repair label should only be used for packets received from >> MPLS. >=20 > The draft already states this: >=20 > In a BGP free core, where traffic is tunneled between edge routers > and edge routers assign labels to prefixes, BGP speakers advertise > reachability information about prefixes and associate a local label > with each prefix such as L3VPN [9], 6PE [10], and Softwire [8]. >=20 > But thinking further I do not see perhaps anything wrong on attaching=20 > this attribute to unicast IPv4 and IPv6 AFIs where ASBRs and network=20 > between them are MPLS enabled. >=20 > In fact if we would explicitly permit this in=20 > draft-bashandy-idr-bgp-repair-label it will automatically address the=20 > problem as described in draft-xu-idr-best-external-loop-avoidance. >=20 > Thx, > R. >=20 >=20 From jakob.heitz@ericsson.com Sat Apr 2 14:02:09 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859563A68B8 for ; Sat, 2 Apr 2011 14:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.431 X-Spam-Level: X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7QQPROsrtgb for ; Sat, 2 Apr 2011 14:02:08 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 925DD3A689F for ; Sat, 2 Apr 2011 14:02:08 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p32L3leH019081; Sat, 2 Apr 2011 16:03:48 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 2 Apr 2011 17:03:41 -0400 From: Jakob Heitz To: "raszuk@cisco.com" Date: Sat, 2 Apr 2011 17:03:40 -0400 Thread-Topic: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? Thread-Index: AcvxYepoCNntq6CgQJyOa76l0zSpjwAFpVsQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F74F409@EUSAACMS0701.eamcs.ericsson.se> References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> <4D9767BF.1060205@cisco.com> In-Reply-To: <4D9767BF.1060205@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 21:02:09 -0000 PE1 gets no new update from PE2, therefore will continue to use the repair label to PE2. Ahmed clarified it for me like this: If PE1 receives a packet destined for a prefix advertised by CE, PE1 will p= ush the primary label advertised by the primary egress PE (be it PE2 or any= other PE) and then tunnel the packet to that PE. I merely asked to have it clarified in the draft in my other email: If no IP path exists to the CE (only mpls path): For packets received as native IP, push the primary label. For packets received as MPLS, push the repair label. -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Saturday, April 02, 2011 11:15 AM > To: Jakob Heitz > Cc: idr > Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01:=20 > when does PE revert back to standard label? >=20 > Hi Jakob, >=20 > > After the link to the CE fails, the PE1 uses the repair=20 > label to send to PE2. > > If the link to the CE is never restored, does PE1 ever use=20 > the regular label again? > > > > Suppose the CE is first attached to PE1 and PE2. > > Then it detaches from PE1 and attaches to PE3. > > It will never reattach to PE1. > > > > Now, PE1 is stuck using the repair label to PE2. >=20 > Not at all :) >=20 > The repair label of CE-PE2 is used as a backup path for=20 > CE-PE1 primary=20 > best path on PE1. >=20 > When the on the PE1 the link to CE fails we will switch to use backup=20 > only for the duration it takes routing protocol to remove the primary=20 > path CE-PE1 reachability and make the CE-PE2 as best path. >=20 > Keep in mind that we are protecting the best path of the net=20 > not the net=20 > itself. >=20 > Then such best will be unprotected till we get a new path via=20 > CE-PE3 and=20 > install it as backup or till the link comes up again and new=20 > best path=20 > CE-PE1 will be installed. >=20 > Cheers, > R. > = From raszuk@cisco.com Sat Apr 2 14:07:47 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE763A68B8 for ; Sat, 2 Apr 2011 14:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnoor162NtKP for ; Sat, 2 Apr 2011 14:07:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 696083A68B7 for ; Sat, 2 Apr 2011 14:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2286; q=dns/txt; s=iport; t=1301778568; x=1302988168; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Rhp+LgB4Do0QeOxspRPv0QSGeZEcwgjL0cehHpyrGCE=; b=JgIgnTUr/wGHxuCMsMjSjuEuNk9p1BU3JjIcBPuVbNsU6O1AX7IDtn89 qVLzWY+t8mrJJmc+ZzKtTKR6oK4jbEFPonEBBKS9+6l7AFpExYIy+Rd1n WXSWVWzUW8KU6+NbmhPzpY+g6G6Th9P6tVoihHYA0wqJFbPz9kLRfN86E Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQBAHKPl02rRDoJ/2dsb2JhbACYJY09d4h5mkOCcA4BmCyFawSNI4Nb X-IronPort-AV: E=Sophos;i="4.63,290,1299456000"; d="scan'208";a="288112876" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2011 21:09:27 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p32L9Qff017785; Sat, 2 Apr 2011 21:09:26 GMT Message-ID: <4D979098.9080508@cisco.com> Date: Sat, 02 Apr 2011 23:09:44 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jakob Heitz References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> <4D9767BF.1060205@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F409@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F74F409@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 21:07:47 -0000 Jakob, > PE1 gets no new update from PE2, therefore will continue to use the > repair label to PE2. No update is required to be received from PE2. Loosing PE1's directly attached path and recalculating all information already present in control plane is already sufficient. > Ahmed clarified it for me like this: If PE1 receives a packet > destined for a prefix advertised by CE, PE1 will push the primary > label advertised by the primary egress PE (be it PE2 or any other PE) > and then tunnel the packet to that PE. Yes, but only after the local control plane convergence happens. > I merely asked to have it clarified in the draft in my other email: > > If no IP path exists to the CE (only mpls path): For packets received > as native IP, push the primary label. For packets received as MPLS, > push the repair label. Nope. It does not matter what type of packets are received. Described in the other (non orthogonal) mail. Cheers, R. >> -----Original Message----- From: Robert Raszuk >> [mailto:raszuk@cisco.com] Sent: Saturday, April 02, 2011 11:15 AM >> To: Jakob Heitz Cc: idr Subject: Re: [Idr] >> draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to >> standard label? >> >> Hi Jakob, >> >>> After the link to the CE fails, the PE1 uses the repair >> label to send to PE2. >>> If the link to the CE is never restored, does PE1 ever use >> the regular label again? >>> >>> Suppose the CE is first attached to PE1 and PE2. Then it detaches >>> from PE1 and attaches to PE3. It will never reattach to PE1. >>> >>> Now, PE1 is stuck using the repair label to PE2. >> >> Not at all :) >> >> The repair label of CE-PE2 is used as a backup path for CE-PE1 >> primary best path on PE1. >> >> When the on the PE1 the link to CE fails we will switch to use >> backup only for the duration it takes routing protocol to remove >> the primary path CE-PE1 reachability and make the CE-PE2 as best >> path. >> >> Keep in mind that we are protecting the best path of the net not >> the net itself. >> >> Then such best will be unprotected till we get a new path via >> CE-PE3 and install it as backup or till the link comes up again and >> new best path CE-PE1 will be installed. >> >> Cheers, R. >> From jakob.heitz@ericsson.com Sat Apr 2 14:08:48 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E243A68BF for ; Sat, 2 Apr 2011 14:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tRDCGMf-kNo for ; Sat, 2 Apr 2011 14:08:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 803613A68BD for ; Sat, 2 Apr 2011 14:08:47 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p32LAQIj019139; Sat, 2 Apr 2011 16:10:27 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sat, 2 Apr 2011 17:10:21 -0400 From: Jakob Heitz To: "raszuk@cisco.com" Date: Sat, 2 Apr 2011 17:10:19 -0400 Thread-Topic: [Idr] draft-retana-bgp-custom-decision-01: compare from different AS Thread-Index: AcvxX8epmBS4SzG5R2C4wfJi9ypgigAGoLlQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40A@EUSAACMS0701.eamcs.ericsson.se> References: <8249B703AE8442429AF89B86E8206AA26EF567C36F@EUSAACMS0703.eamcs.ericsson.se> <4D97642A.2050908@cisco.com> In-Reply-To: <4D97642A.2050908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr Subject: Re: [Idr] draft-retana-bgp-custom-decision-01: compare from different AS X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 21:08:48 -0000 Agreed. Could this be added to the draft? -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Saturday, April 02, 2011 11:00 AM > To: Jakob Heitz > Cc: idr > Subject: Re: [Idr] draft-retana-bgp-custom-decision-01:=20 > compare from different AS >=20 > Hi Jakob, >=20 > IMHO we should learn form the past (read: MED experience) and when=20 > allowing for a given cost community to be transitive across ASes it's=20 > definition should very clearly indicate that in the event of using=20 > potentially different ranges of values they must be normalized to be=20 > able to be comparable in each AS they are transmitted to without=20 > necessity of any additional grouping. >=20 > Cheers, > R. >=20 > > Was there a discussion among the authors about the merit of a rule > > like for the med not to compare values of the transitive cost > > community received from different AS's? Could you summarize the > > discussions please? > > > > -- Jakob Heitz. _______________________________________________ Idr > > mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > >=20 > = From jakob.heitz@ericsson.com Sat Apr 2 14:11:35 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7853A68BF for ; Sat, 2 Apr 2011 14:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qOMwa0TNds5 for ; Sat, 2 Apr 2011 14:11:29 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id B21563A68C6 for ; Sat, 2 Apr 2011 14:11:28 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p32LD7r8032232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Apr 2011 16:13:07 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sat, 2 Apr 2011 17:13:06 -0400 From: Jakob Heitz To: "raszuk@cisco.com" Date: Sat, 2 Apr 2011 17:13:04 -0400 Thread-Topic: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? Thread-Index: AcvxekMri64XaWxoQHOPd3DuoLfsiQAADniw Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40B@EUSAACMS0701.eamcs.ericsson.se> References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> <4D9767BF.1060205@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F409@EUSAACMS0701.eamcs.ericsson.se> <4D979098.9080508@cisco.com> In-Reply-To: <4D979098.9080508@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 21:11:35 -0000 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Saturday, April 02, 2011 2:10 PM > To: Jakob Heitz > Cc: idr > Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01:=20 > when does PE revert back to standard label? >=20 > Jakob, >=20 > > PE1 gets no new update from PE2, therefore will continue to use the > > repair label to PE2. >=20 > No update is required to be received from PE2. Loosing PE1's directly > attached path and recalculating all information already present in > control plane is already sufficient. That causes the repair label to be used towards PE2. >=20 > > Ahmed clarified it for me like this: If PE1 receives a packet > > destined for a prefix advertised by CE, PE1 will push the primary > > label advertised by the primary egress PE (be it PE2 or any=20 > other PE) > > and then tunnel the packet to that PE. >=20 > Yes, but only after the local control plane convergence happens. Not necessary. >=20 > > I merely asked to have it clarified in the draft in my other email: > > > > If no IP path exists to the CE (only mpls path): For=20 > packets received > > as native IP, push the primary label. For packets received as MPLS, > > push the repair label. >=20 > Nope. It does not matter what type of packets are received.=20 > Described in=20 > the other (non orthogonal) mail. Not described. Please read carefully and understand before answering. >=20 > Cheers, > R. >=20 >=20 > >> -----Original Message----- From: Robert Raszuk > >> [mailto:raszuk@cisco.com] Sent: Saturday, April 02, 2011 11:15 AM > >> To: Jakob Heitz Cc: idr Subject: Re: [Idr] > >> draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to > >> standard label? > >> > >> Hi Jakob, > >> > >>> After the link to the CE fails, the PE1 uses the repair > >> label to send to PE2. > >>> If the link to the CE is never restored, does PE1 ever use > >> the regular label again? > >>> > >>> Suppose the CE is first attached to PE1 and PE2. Then it detaches > >>> from PE1 and attaches to PE3. It will never reattach to PE1. > >>> > >>> Now, PE1 is stuck using the repair label to PE2. > >> > >> Not at all :) > >> > >> The repair label of CE-PE2 is used as a backup path for CE-PE1 > >> primary best path on PE1. > >> > >> When the on the PE1 the link to CE fails we will switch to use > >> backup only for the duration it takes routing protocol to remove > >> the primary path CE-PE1 reachability and make the CE-PE2 as best > >> path. > >> > >> Keep in mind that we are protecting the best path of the net not > >> the net itself. > >> > >> Then such best will be unprotected till we get a new path via > >> CE-PE3 and install it as backup or till the link comes up again and > >> new best path CE-PE1 will be installed. > >> > >> Cheers, R. > >> >=20 > = From raszuk@cisco.com Sat Apr 2 14:28:40 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD163A68C6 for ; Sat, 2 Apr 2011 14:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.218 X-Spam-Level: X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgp2uKfxCr9O for ; Sat, 2 Apr 2011 14:28:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4B91A3A68BF for ; Sat, 2 Apr 2011 14:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2028; q=dns/txt; s=iport; t=1301779819; x=1302989419; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yO4LglhLqPbsTzGT/bxfq4AELqJ59zhjoXvTrIGH+kc=; b=GwM43hIbMQ5xOS2NmFOb3TYPvsdVxzndFCIvRkSPaGgLDivBT+3iLC+7 ckZFdTneUstKcv5Dvy5C5VQGjmVSCg5hMFPXMaG6VjS6MeQZxLIBcfIjx 7deyDLCvLDiQbvYn8Nl6q71qAcln2LOSTNw9YNdTVf6J//HYVGoK1KxE2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP+Ul02rRDoJ/2dsb2JhbAClYneIeZpGgnAOAZgrhWsEjSODWw X-IronPort-AV: E=Sophos;i="4.63,290,1299456000"; d="scan'208";a="674915313" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2011 21:30:19 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p32LUIUl026893; Sat, 2 Apr 2011 21:30:18 GMT Message-ID: <4D97957B.7050801@cisco.com> Date: Sat, 02 Apr 2011 23:30:35 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jakob Heitz References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> <4D9767BF.1060205@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F409@EUSAACMS0701.eamcs.ericsson.se> <4D979098.9080508@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40B@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40B@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 21:28:40 -0000 Jakob, >>> PE1 gets no new update from PE2, therefore will continue to use the >>> repair label to PE2. >> >> No update is required to be received from PE2. Loosing PE1's directly >> attached path and recalculating all information already present in >> control plane is already sufficient. > > That causes the repair label to be used towards PE2. No. You need to realize that control plane trigger is not equal to data plane trigger. Those are two totally separate message paths with different forwarding outcome. Any sort of FRR uses data plane/forwarding event to trigger really fast prefix independent switchover (usually less then 50ms) to a backup path. However control plane is much slower. But will eventually in 100s of ms converge completely removing the original directly connected best path and it's protection via PE2. It is really very simple. >>> Ahmed clarified it for me like this: If PE1 receives a packet >>> destined for a prefix advertised by CE, PE1 will push the primary >>> label advertised by the primary egress PE (be it PE2 or any >> other PE) >>> and then tunnel the packet to that PE. >> >> Yes, but only after the local control plane convergence happens. > > Not necessary. ;) >> Nope. It does not matter what type of packets are received. >> Described in the other (non orthogonal) mail. > > Not described. > Please read carefully and understand before answering. I did, but apparently my answer was a little bit implicit but I hoped you will parse it. So let me try again ... The draft says black on white: "and associate a local label with each prefix such as L3VPN [9], 6PE [10], and Softwire [8]" it directly means to me that as written it is not applicable to IPv4 and IPv6 non mpls protection. And as suggested that can be fixed extending the scope of the draft to make it applicable also to unicast IPv4 and IPv6 as this is not only safe, but also desired in mpls networks where best external is injected. R. From jakob.heitz@ericsson.com Sat Apr 2 14:57:45 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6797C3A68D5 for ; Sat, 2 Apr 2011 14:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXmnOeCFN4lS for ; Sat, 2 Apr 2011 14:57:44 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 8BD4E3A68D4 for ; Sat, 2 Apr 2011 14:57:44 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p32LxN3B019860; Sat, 2 Apr 2011 16:59:24 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sat, 2 Apr 2011 17:59:17 -0400 From: Jakob Heitz To: "raszuk@cisco.com" , idr Date: Sat, 2 Apr 2011 17:59:16 -0400 Thread-Topic: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? Thread-Index: AcvxfSyCzQ3zI1BKT0Gk/Ui1hE0yAwAALImw Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40F@EUSAACMS0701.eamcs.ericsson.se> References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> <4D9767BF.1060205@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F409@EUSAACMS0701.eamcs.ericsson.se> <4D979098.9080508@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40B@EUSAACMS0701.eamcs.ericsson.se> <4D97957B.7050801@cisco.com> In-Reply-To: <4D97957B.7050801@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 21:57:45 -0000 Robert, You are talking about something quite different. Please understand the scenario I described and answer it directly. I'll describe it again, using the diagram from the draft: I will add another CE, CE2. CE2 will send an IP packet to CE. Initial topology: +--------------------------+ | | +-----CE2 | BGP free Core | / | | / | +------------------PE1----+ | / | \ | / | \ | / | \ | / | \ | / | * PE3 | CE....... VPN prefix | \ | * (P/p) | \ | / | \ | / | \ | / | \ | / | +------------------PE2----+ | | | | +--------------------------+ CE detaches from PE1 and attaches to PE3. +--------------------------+ | | +-----CE2 | BGP free Core | / | | / | +------------------PE1 | / | | / | | / | | / | | / | PE3 | CE....... VPN prefix / | \ | * (P/p) + | \ | /| | | \ | / | | | \ | / | | | \ | / | | | +------------------PE2----+ | | | | | | | | | | +--------------------------+ | | | +----------------------------------------+ If PE3 sends an MPLS packet to PE1, PE1 uses the repair label to send to PE= 2. If CE2 sends an IP packet to PE1, PE1 should use the primary label to send = it to PE2. It should NEVER use the repair label to send that packet. The reason? If the link PE2 - CE were to fail, PE2 would not use the backup= to PE3. +--------------------------+ | | +-----CE2 | BGP free Core | / | | / | +------------------PE1 | / | | / | | / | | / | | / | PE3 | CE....... VPN prefix / | \ | * (P/p) + | \ | | | | \ | | | | \ | | | | \ | | | | +------------------PE2 | | | | | | | | | | +--------------------------+ | | | +----------------------------------------+ -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Saturday, April 02, 2011 2:31 PM > To: Jakob Heitz > Cc: idr > Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01:=20 > when does PE revert back to standard label? >=20 > Jakob, >=20 > >>> PE1 gets no new update from PE2, therefore will continue=20 > to use the > >>> repair label to PE2. > >> > >> No update is required to be received from PE2. Loosing=20 > PE1's directly > >> attached path and recalculating all information already present in > >> control plane is already sufficient. > > > > That causes the repair label to be used towards PE2. >=20 > No. You need to realize that control plane trigger is not=20 > equal to data=20 > plane trigger. Those are two totally separate message paths with=20 > different forwarding outcome. >=20 > Any sort of FRR uses data plane/forwarding event to trigger=20 > really fast=20 > prefix independent switchover (usually less then 50ms) to a=20 > backup path. >=20 > However control plane is much slower. But will eventually in=20 > 100s of ms=20 > converge completely removing the original directly connected=20 > best path=20 > and it's protection via PE2. >=20 > It is really very simple. >=20 > >>> Ahmed clarified it for me like this: If PE1 receives a packet > >>> destined for a prefix advertised by CE, PE1 will push the primary > >>> label advertised by the primary egress PE (be it PE2 or any > >> other PE) > >>> and then tunnel the packet to that PE. > >> > >> Yes, but only after the local control plane convergence happens. > > > > Not necessary. >=20 > ;) >=20 > >> Nope. It does not matter what type of packets are received. > >> Described in the other (non orthogonal) mail. > > > > Not described. > > Please read carefully and understand before answering. >=20 > I did, but apparently my answer was a little bit implicit but I hoped=20 > you will parse it. So let me try again ... >=20 > The draft says black on white: >=20 > "and associate a local label with each prefix such as L3VPN [9], 6PE=20 > [10], and Softwire [8]" >=20 > it directly means to me that as written it is not applicable=20 > to IPv4 and=20 > IPv6 non mpls protection. >=20 > And as suggested that can be fixed extending the scope of the=20 > draft to=20 > make it applicable also to unicast IPv4 and IPv6 as this is not only=20 > safe, but also desired in mpls networks where best external=20 > is injected. >=20 > R. > = From raszuk@cisco.com Sat Apr 2 15:22:10 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4AF3A68E2 for ; Sat, 2 Apr 2011 15:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTjpkcsqnDI9 for ; Sat, 2 Apr 2011 15:22:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3F8433A68D4 for ; Sat, 2 Apr 2011 15:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1072; q=dns/txt; s=iport; t=1301783028; x=1302992628; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=s42GMWIXUiF5ku+izL3IlBZgJBq/Ok0kPrW6XtZAN6c=; b=RKNz+BuDzny3/KHC5+sx0ac5JXyk7OgmkCJSbGUJybtn00biflZBVXn+ zd7d7583VdKLSifpNqZl4KpbVNA7jtI9E7Q+gkSqgmhEKeWdXC6DScbNm x5wtMuRl1esJ7CI2cIxCwkU3QlE8iuq6IuRb0hn+po0i1jGw1bJDXqAvT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMWgl02rRDoI/2dsb2JhbAClYneIeZoygnAOAZgfhWsEjSODWw X-IronPort-AV: E=Sophos;i="4.63,290,1299456000"; d="scan'208";a="674919057" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2011 22:23:48 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p32MNliG027706; Sat, 2 Apr 2011 22:23:48 GMT Message-ID: <4D97A204.8090703@cisco.com> Date: Sun, 03 Apr 2011 00:24:04 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jakob Heitz References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> <4D9767BF.1060205@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F409@EUSAACMS0701.eamcs.ericsson.se> <4D979098.9080508@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40B@EUSAACMS0701.eamcs.ericsson.se> <4D97957B.7050801@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40F@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40F@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 22:22:10 -0000 Hi Jakob, > If PE3 sends an MPLS packet to PE1, PE1 uses the repair label to send > to PE2. If CE2 sends an IP packet to PE1, PE1 should use the primary > label to send it to PE2. It should NEVER use the repair label to send > that packet. > > The reason? If the link PE2 - CE were to fail, PE2 would not use the > backup to PE3. Nope - sorry. 1st point: We are working here to protect against single failure not double failure like in your example. Now direct answer with sequence of events including time scale for better description: - -10ms CE2 communicates via PE1 with CE without any protection - 0ms CE is getting re-homed from PE1 to PE3 - 20ms PE1 on data plane is starting to use a backup label and nh=PE2 - 300ms PE1 converges control plane and starts to use primary label as advertised by PE2 (in the same time all network is recalculating as well removing CE via PE1 path) - @ next failure - PE2-CE fails PE2 will already have a backup via PE3 in it's data plane using backup label as advertised by PE3. Rgs, R. From jakob.heitz@ericsson.com Sat Apr 2 17:22:02 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDEB3A68F6 for ; Sat, 2 Apr 2011 17:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WTYIo6u-e5K for ; Sat, 2 Apr 2011 17:22:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id E72193A68F4 for ; Sat, 2 Apr 2011 17:22:01 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p330NesY021637; Sat, 2 Apr 2011 19:23:42 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 2 Apr 2011 20:23:40 -0400 From: Jakob Heitz To: "raszuk@cisco.com" Date: Sat, 2 Apr 2011 20:23:39 -0400 Thread-Topic: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? Thread-Index: AcvxhKnD5OqnHVSjSxmdjjQKV15IgwADzolQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F74F413@EUSAACMS0701.eamcs.ericsson.se> References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> <4D9767BF.1060205@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F409@EUSAACMS0701.eamcs.ericsson.se> <4D979098.9080508@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40B@EUSAACMS0701.eamcs.ericsson.se> <4D97957B.7050801@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40F@EUSAACMS0701.eamcs.ericsson.se> <4D97A204.8090703@cisco.com> In-Reply-To: <4D97A204.8090703@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 00:22:02 -0000 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Saturday, April 02, 2011 3:24 PM > To: Jakob Heitz > Cc: idr > Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01:=20 > when does PE revert back to standard label? >=20 > Hi Jakob, >=20 > > If PE3 sends an MPLS packet to PE1, PE1 uses the repair=20 > label to send > > to PE2. If CE2 sends an IP packet to PE1, PE1 should use the primary > > label to send it to PE2. It should NEVER use the repair=20 > label to send > > that packet. > > > > The reason? If the link PE2 - CE were to fail, PE2 would not use the > > backup to PE3. >=20 > Nope - sorry. >=20 > 1st point: We are working here to protect against single failure not > double failure like in your example. It's not a double failure. >=20 > Now direct answer with sequence of events including time scale for=20 > better description: >=20 > - -10ms CE2 communicates via PE1 with CE without any protection > - 0ms CE is getting re-homed from PE1 to PE3 > - 20ms PE1 on data plane is starting to use a backup label and nh=3DPE2 It uses repair label for packets received from PE3. (MPLS) It uses primary label for packets received from CE2. (native IP) > - 300ms PE1 converges control plane and starts to use primary label as > advertised by PE2 (in the same time all network is recalculating as > well removing CE via PE1 path) still: It uses repair label for packets received from PE3. (MPLS) It uses primary label for packets received from CE2. (native IP) > - @ next failure - PE2-CE fails PE2 will already have a backup via PE3 > in it's data plane using backup label as advertised by PE3. >=20 > Rgs, > R. >=20 > = From rjs@rob.sh Mon Apr 4 04:39:00 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776363A67B2 for ; Mon, 4 Apr 2011 04:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6xMMjflY9ZO for ; Mon, 4 Apr 2011 04:38:33 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by core3.amsl.com (Postfix) with ESMTP id 36DDB3A696A for ; Mon, 4 Apr 2011 04:38:33 -0700 (PDT) Received: from [195.10.56.23] (helo=[212.137.15.55]) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1Q6i6E-0000fT-A6; Mon, 04 Apr 2011 12:37:38 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Rob Shakir X-Priority: 3 In-Reply-To: Date: Mon, 4 Apr 2011 12:40:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: iLya X-Mailer: Apple Mail (2.1082) Cc: idr@ietf.org Subject: Re: [Idr] WG adoption of draft-varlashkin-bgp-nh-cost-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 11:39:00 -0000 On 31 Mar 2011, at 15:46, iLya wrote: > IDR, >=20 > authors of "Carrying next-hop cost information in BGP" draft would = like to ask to adopt this document as IDR WG item. >=20 > Latest version of the draft is available at = http://tools.ietf.org/html/draft-varlashkin-bgp-nh-cost-01 I've read this, and support adoption as a working group item. Cheers, r. From iesg-secretary@ietf.org Mon Apr 4 11:54:02 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079883A67AC; Mon, 4 Apr 2011 11:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cKrsznyncbX; Mon, 4 Apr 2011 11:54:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36EC33A6768; Mon, 4 Apr 2011 11:54:01 -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: 3.14 Message-ID: <20110404185401.29271.77148.idtracker@localhost> Date: Mon, 04 Apr 2011 11:54:01 -0700 Cc: idr@ietf.org Subject: [Idr] Last Call: (AS-wide Unique BGP Identifier for BGP-4) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:54:02 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'AS-wide Unique BGP Identifier for BGP-4' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-identifier/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-identifier/ No IPR declarations have been submitted directly on this I-D. From stephane.litkowski@orange-ftgroup.com Tue Apr 5 01:30:24 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C09D3A68ED for ; Tue, 5 Apr 2011 01:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2mUd2SbCfCz for ; Tue, 5 Apr 2011 01:30:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 0B51E3A68EB for ; Tue, 5 Apr 2011 01:30:16 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 040EE1B829A; Tue, 5 Apr 2011 10:31:59 +0200 (CEST) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id E0D9338403A; Tue, 5 Apr 2011 10:31:58 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Apr 2011 10:31:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 10:31:57 +0200 Message-ID: <30542_1301992318_4D9AD37E_30542_51787_1_4FC3556A36EE3646A09DAA60429F5335062625B2@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <4D9482E7.5010905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] BGP Optimal Route Reflection (BGP-ORR) Thread-Index: AcvvqGKRVtZHGQAkSdOSuVfbsWmu3ADw2h0A References: <4D9482E7.5010905@cisco.com> From: To: , X-OriginalArrivalTime: 05 Apr 2011 08:31:58.0915 (UTC) FILETIME=[EDEFB130:01CBF36B] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.5.72119 Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 08:30:24 -0000 I support adoption of this draft as a working group work item. -----Message d'origine----- De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de Rober= t Raszuk Envoy=E9 : jeudi 31 mars 2011 15:35 =C0 : idr@ietf.org List Objet : [Idr] BGP Optimal Route Reflection (BGP-ORR) Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document would li= ke to propose the adoption of this work as the IDR WG item. Ref: http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 Rgs, R. Raszuk C. Cassar E. Aman B. Decraene _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From david.freedman@uk.clara.net Tue Apr 5 02:52:23 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92FD03A690D for ; Tue, 5 Apr 2011 02:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pE3DM6UuMji for ; Tue, 5 Apr 2011 02:52:15 -0700 (PDT) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by core3.amsl.com (Postfix) with ESMTP id 9F2E53A6905 for ; Tue, 5 Apr 2011 02:52:15 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.72) (envelope-from ) id 1Q72we-0000y3-7z for idr@ietf.org; Tue, 05 Apr 2011 10:53:08 +0100 Message-ID: <4D9AE684.8040407@uk.clara.net> Date: Tue, 05 Apr 2011 10:53:08 +0100 From: David Freedman Organization: Claranet LImited User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: idr References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACL-Warn: Message has been frozen because it contains sensitive words (ietf.org), please unfreeze it manually Subject: Re: [Idr] WG adoption of draft-varlashkin-bgp-nh-cost-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 09:52:23 -0000 Support! On 31/03/11 15:46, iLya wrote: > IDR, > > authors of "Carrying next-hop cost information in BGP" draft would like > to ask to adopt this document as IDR WG item. > > Latest version of the draft is available at > http://tools.ietf.org/html/draft-varlashkin-bgp-nh-cost-01 > > Kind regards, > I. Varlashkin, > R. Raszuk > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- David Freedman Group Network Engineering Claranet Group From danny@tcb.net Tue Apr 5 20:27:49 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1953A684E for ; Tue, 5 Apr 2011 20:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.317 X-Spam-Level: X-Spam-Status: No, score=-110.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMyvnHMYDjJL for ; Tue, 5 Apr 2011 20:27:48 -0700 (PDT) Received: from farnsworth.verisignlabs.com (farnsworth.verisignlabs.com [72.13.58.64]) by core3.amsl.com (Postfix) with ESMTP id 3CA9F3A684B for ; Tue, 5 Apr 2011 20:27:48 -0700 (PDT) Received: from monsoon.verisignlabs.com (h87.s239.verisign.com [216.168.239.87]) by farnsworth.verisignlabs.com (Postfix) with ESMTP id 922AB37D9D for ; Wed, 6 Apr 2011 03:29:31 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (dul1dmcphers-m2.vcorp.ad.vrsn.com [10.100.0.78]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 5ACC82420BA for ; Tue, 5 Apr 2011 23:29:30 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1082) From: Danny McPherson In-Reply-To: <30542_1301992318_4D9AD37E_30542_51787_1_4FC3556A36EE3646A09DAA60429F5335062625B2@PUEXCBL0.nanterre.francetelecom.fr> Date: Tue, 5 Apr 2011 23:29:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C466675-EE55-4C8E-9216-9EDF03061378@tcb.net> References: <4D9482E7.5010905@cisco.com> <30542_1301992318_4D9AD37E_30542_51787_1_4FC3556A36EE3646A09DAA60429F5335062625B2@PUEXCBL0.nanterre.francetelecom.fr> To: "idr@ietf.org List" X-Mailer: Apple Mail (2.1082) Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 03:27:49 -0000 I support WG adoption as well.. -danny On Apr 5, 2011, at 4:31 AM, = wrote: > I support adoption of this draft as a working group work item. >=20 >=20 > -----Message d'origine----- > De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de = Robert Raszuk > Envoy=E9 : jeudi 31 mars 2011 15:35 > =C0 : idr@ietf.org List > Objet : [Idr] BGP Optimal Route Reflection (BGP-ORR) >=20 >=20 > Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document = would like to propose the adoption of this work as the IDR WG item. >=20 > Ref: > = http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 >=20 > Rgs, > R. Raszuk > C. Cassar > E. Aman > B. Decraene > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > = **************************************************************************= ****** > IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) = destinataire(s) mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas = destine, veuillez immediatement le signaler a l expediteur et effacer = ce message=20 > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de = tout virus. >=20 > IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. > Any unauthorized view, usage or disclosure ofthis message is = prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > = **************************************************************************= ****** >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rjs@rob.sh Wed Apr 6 10:00:17 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8415F3A68BD for ; Wed, 6 Apr 2011 10:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH+-d7TaaOoJ for ; Wed, 6 Apr 2011 10:00:16 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by core3.amsl.com (Postfix) with ESMTP id 9B37F3A68B9 for ; Wed, 6 Apr 2011 10:00:15 -0700 (PDT) Received: from [195.10.56.30] (helo=[212.137.15.244]) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1Q7W7B-00037Q-Q9; Wed, 06 Apr 2011 18:01:57 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <4D9482E7.5010905@cisco.com> Date: Wed, 6 Apr 2011 18:01:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9482E7.5010905@cisco.com> To: raszuk@cisco.com X-Mailer: Apple Mail (2.1082) Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:00:17 -0000 On 31 Mar 2011, at 14:34, Robert Raszuk wrote: >=20 > Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document = would like to propose the adoption of this work as the IDR WG item. >=20 > Ref: > = http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 Hi, I have read/reviewed this draft and support it's adoption as a working = group item. Kind regards, r. From ub@cs.uni-bonn.de Wed Apr 6 11:17:03 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EFA28C10E for ; Wed, 6 Apr 2011 11:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfDU1ZhU9tf8 for ; Wed, 6 Apr 2011 11:17:02 -0700 (PDT) Received: from postfix.iai.uni-bonn.de (postfix.iai.uni-bonn.de [131.220.8.4]) by core3.amsl.com (Postfix) with ESMTP id 4CBD428C0D6 for ; Wed, 6 Apr 2011 11:17:01 -0700 (PDT) X-IAI-Env-From: : [93.129.125.118] Received: from pad-wlan-workingroomub.fritz.box (koln-5d817d76.pool.mediaWays.net [93.129.125.118]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id 6C3655C401; Wed, 6 Apr 2011 20:18:44 +0200 (MEST) (envelope-from ub@cs.uni-bonn.de) (envelope-to VARIOUS) (3) (internal use: ta=1, tu=1, te=1, am=P, au=ub) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Uli Bornhauser In-Reply-To: <4D9482E7.5010905@cisco.com> Date: Wed, 6 Apr 2011 20:18:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9482E7.5010905@cisco.com> To: raszuk@cisco.com X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 18:17:03 -0000 Hi Robert, all I carefully read the new version today. In principle, I fully support WG = adoption. However, I have two minor notes concerning the draft: In the abstract, you mention that RFC4456 specifies a deployment = approach that yields the same result as a full-mesh will do. Reading = this paragraph, I implicitly assumed that ORR realizes the same, which = is not the case. Of course, this was my fault, but it could be helpful = to state this in the abstract. In section 2, you state that "the route reflector selects and = distributes a route to each client based on what would be optimal from = the client's perspective". After that, you state that clients do not = need new software. I had two aspects in mind, which should IMHO be = explicitly mentioned here: First, if clients do not have a modified software (Add-path and adequate = implementation guidelines), Route Reflectors select the same path for a = client as if the client would do in a full-mesh BGP environment. = However, this path may not be optimal from the client's perspective. Second, even if the optimal path is distributed by the server, it may be = that the client chooses another (local) path which is sub-optimal from a = global perspective. That's all. Again, all in all, I fully support WG adoption. Regards Uli Am 31.03.2011 um 15:34 schrieb Robert Raszuk: >=20 > Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document = would like to propose the adoption of this work as the IDR WG item. >=20 > Ref: > = http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 >=20 > Rgs, > R. Raszuk > C. Cassar > E. Aman > B. Decraene > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --=20 _______________________________________________________ ULI BORNHAUSER University of Bonn - Institute of Computer Science 4 Friedrich-Ebert-Allee 144 - D 53113 Bonn - Germany Web: www.cs.bonn.edu/IV/ub Email: ub@cs.uni-bonn.de =09 Phone: +49 (228) 73 - 54219 Fax: +49 (228) 73 - 4571 From raszuk@cisco.com Wed Apr 6 11:23:22 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8DF3A690A for ; Wed, 6 Apr 2011 11:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.514 X-Spam-Level: X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyVo-vFVr3oR for ; Wed, 6 Apr 2011 11:23:21 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 84B8F28C0D6 for ; Wed, 6 Apr 2011 11:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2065; q=dns/txt; s=iport; t=1302114305; x=1303323905; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=26oBB5a4gcuxkDnGcjRYmCH8EnGRafCh6zdg4Qwx4Is=; b=k1J5cU01tWLVeZ/Vjbxa1sHlDAlDU2biHG2juU1MLd+BulOhEFCJxW7k 35vvT75VB881mX4302OtEAPhUyMN5Zm89jO8FuOiS5XG3vkKdckCB5ajC EofrvVwi4VnnnbQqusvxqJmQL9sLZEAA6SNDIGYMPDW3n4uymg22kBG0H s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPGunE2rRDoH/2dsb2JhbAClfHeIeZ1/gnMOAZlHhWwEjTyDYw X-IronPort-AV: E=Sophos;i="4.63,311,1299456000"; d="scan'208";a="290663264" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2011 18:25:05 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p36IP4Bk010355; Wed, 6 Apr 2011 18:25:04 GMT Message-ID: <4D9CB003.1000107@cisco.com> Date: Wed, 06 Apr 2011 20:25:07 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Uli Bornhauser References: <4D9482E7.5010905@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 18:23:22 -0000 Hello Uli, Many thx for your valuable comments as well as for your support to adopt this work as IDR WG work item. I will incorporate your points into the next revision of the draft. Best regards, R. > Hi Robert, all > > I carefully read the new version today. In principle, I fully support > WG adoption. > > However, I have two minor notes concerning the draft: > > In the abstract, you mention that RFC4456 specifies a deployment > approach that yields the same result as a full-mesh will do. Reading > this paragraph, I implicitly assumed that ORR realizes the same, > which is not the case. Of course, this was my fault, but it could be > helpful to state this in the abstract. > > In section 2, you state that "the route reflector selects and > distributes a route to each client based on what would be optimal > from the client's perspective". After that, you state that clients do > not need new software. I had two aspects in mind, which should IMHO > be explicitly mentioned here: First, if clients do not have a > modified software (Add-path and adequate implementation guidelines), > Route Reflectors select the same path for a client as if the client > would do in a full-mesh BGP environment. However, this path may not > be optimal from the client's perspective. Second, even if the optimal > path is distributed by the server, it may be that the client chooses > another (local) path which is sub-optimal from a global perspective. > > That's all. Again, all in all, I fully support WG adoption. > > Regards > > Uli > > Am 31.03.2011 um 15:34 schrieb Robert Raszuk: > >> >> Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document >> would like to propose the adoption of this work as the IDR WG >> item. >> >> Ref: >> http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 >> >> >> Rgs, >> R. Raszuk C. Cassar E. Aman B. Decraene >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > From rbonica@juniper.net Wed Apr 6 14:44:08 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED223A67E3 for ; Wed, 6 Apr 2011 14:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.522 X-Spam-Level: X-Spam-Status: No, score=-106.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omH5clCYCphN for ; Wed, 6 Apr 2011 14:44:07 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id A99E53A67D7 for ; Wed, 6 Apr 2011 14:44:06 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTZzfDpK4vK3MXkI4VyJvQYBpcuzZ5Qbl@postini.com; Wed, 06 Apr 2011 14:45:51 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Apr 2011 14:41:55 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 6 Apr 2011 17:43:38 -0400 From: Ronald Bonica To: "raszuk@cisco.com" , "idr@ietf.org List" Date: Wed, 6 Apr 2011 17:43:38 -0400 Thread-Topic: [Idr] BGP Optimal Route Reflection (BGP-ORR) Thread-Index: AcvvqGJnqSPv/KSSRPS8KPumlVkgmwE9+vVQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> References: <4D9482E7.5010905@cisco.com> In-Reply-To: <4D9482E7.5010905@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:44:08 -0000 Folks, I would like to discourage adoption of this draft for the following reasons= : 1) A relatively inexpensive solution to this problem is already available. = That is, to deploy slightly larger number of route reflectors and to assign= clients to reflectors based upon IGP distance. 2) The solutions described in this draft do not scale well. In particular, = it is not clear how the solution described in Section 3 works when the BGP = domain is so large that it does not fit in a single IGP area. Even if the B= GP domain were to fit in a single IGP area, the solution described in Secti= on 3 becomes computationally expensive if the domain contains many POPs. 3) The solution described in Section 4 is operationally complex. While it i= s theoretically possible to assign an angular position to each rr client, i= n some network topologies, this is easier said than done. AFAICS, calculati= on and configuration of the angular position is always a manual operation. = Angular positions must be re-evaluated periodically, to account for the add= ition of network links. Ron > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Robert Raszuk > Sent: Thursday, March 31, 2011 9:35 AM > To: idr@ietf.org List > Subject: [Idr] BGP Optimal Route Reflection (BGP-ORR) >=20 >=20 > Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document > would > like to propose the adoption of this work as the IDR WG item. >=20 > Ref: > http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 >=20 > Rgs, > R. Raszuk > C. Cassar > E. Aman > B. Decraene > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Wed Apr 6 15:08:42 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861E73A69CF for ; Wed, 6 Apr 2011 15:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sf82TxbmOGvT for ; Wed, 6 Apr 2011 15:08:41 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 52E093A67EA for ; Wed, 6 Apr 2011 15:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=3903; q=dns/txt; s=iport; t=1302127825; x=1303337425; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=styx1+ewnwLLj9FpbGDd2HjN57FFTfnEO94VGm/Lm2A=; b=FNnowHgnx4fLoqUl7SqZ8pAqosbcZdD8+BFtRAVzkGwI5Ah3BCoJP6CK nS3UOugFZllnnZKOvNShpJwjmzKvgwujESjf8D7mV7sLiB/20ceZQ8U6/ p2Kc7KmK6zIooPeHpW+TnGi/L8+wdoSCs/Po/wPwA8HflzpAvYEzXGOlG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBALHjnE2rRDoI/2dsb2JhbACYM41Md4h5nh6Ccw4BmV6DEIJcBI08g2M X-IronPort-AV: E=Sophos;i="4.63,312,1299456000"; d="scan'208";a="290826805" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2011 22:10:25 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p36MAN6E026001; Wed, 6 Apr 2011 22:10:24 GMT Message-ID: <4D9CE4D3.9060401@cisco.com> Date: Thu, 07 Apr 2011 00:10:27 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ronald Bonica References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 22:08:42 -0000 Thank you for your opinion. Let me explain what the draft proposes in the light of your comments ... > 1) A relatively inexpensive solution to this problem is already > available. That is, to deploy slightly larger number of route > reflectors and to assign clients to reflectors based upon IGP > distance. Both route reflectors as well as their network operation carry a non negligible opex and capex values. It should be the network operator to decide if given solution vs available alternative is attractive to him or not. Clearly such decision should not be made by a vendor. The goal of the draft is to provide such choice to the network operator. > 2) The solutions described in this draft do not scale well. In > particular, it is not clear how the solution described in Section 3 > works when the BGP domain is so large that it does not fit in a > single IGP area. The draft already contains the detailed explanation on this point: In the case of a hierarchical IGP deployment where the client is in a different level in the hierarchy to the route reflector, the route reflector will compute IGP distance to the BGP nexthop from the Area Border Routers (ABR) leading to the client in lieu of the route reflector client itself, and use the shortest distance from these ABRs to the nexthop. This provides an approximation to the desired functionality. This scales just fine. Moreover there is another method to provide precise and not approximated distance of the client to the next hop metric. The details are described in document titled: "Carrying next-hop cost information in BGP" available at http://tools.ietf.org/html/draft-varlashkin-bgp-nh-cost-01 > Even if the BGP domain were to fit in a single IGP > area, the solution described in Section 3 becomes computationally > expensive if the domain contains many POPs. Let me point out that what may be computationally expensive for one RR platform may not provide a significant load for some other RR implementation on other choice of computational platform. Therefor your above stated comment seems to be very subjective and quite narrowly focused. > 3) The solution described in Section 4 is operationally complex. > While it is theoretically possible to assign an angular position to > each rr client, in some network topologies, this is easier said than > done. AFAICS, calculation and configuration of the angular position > is always a manual operation. Angular positions must be re-evaluated > periodically, to account for the addition of network links. While the draft does describe angular approximation as manual configuration today the aim is for small or middle size networks. For much larger networks angular approximation does not need to be a manual operation or other ways of deriving client to next hop metric can be used. One size does not fit all. With this in mind let me point out that there are number of automated methods to be used for angular metric calculation and assignment which if there is further interest in the IDR WG could be documented in a separate proposals. Best regards, Robert Raszuk. >> -----Original Message----- From: idr-bounces@ietf.org >> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >> Thursday, March 31, 2011 9:35 AM To: idr@ietf.org List Subject: >> [Idr] BGP Optimal Route Reflection (BGP-ORR) >> >> >> Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document >> would like to propose the adoption of this work as the IDR WG >> item. >> >> Ref: >> http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 >> >> >> Rgs, >> R. Raszuk C. Cassar E. Aman B. Decraene >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > From randy@psg.com Wed Apr 6 16:04:15 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF4073A67EB for ; Wed, 6 Apr 2011 16:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Zvc3g10pTZ1 for ; Wed, 6 Apr 2011 16:04:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 486223A67E1 for ; Wed, 6 Apr 2011 16:04:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7bmE-0004yc-IH; Wed, 06 Apr 2011 23:04:42 +0000 Date: Wed, 06 Apr 2011 16:04:42 -0700 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4D9CE4D3.9060401@cisco.com> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 23:04:15 -0000 > Both route reflectors as well as their network operation carry a non > negligible opex and capex values. It should be the network operator to > decide if given solution vs available alternative is attractive to him > or not. Clearly such decision should not be made by a vendor. The goal > of the draft is to provide such choice to the network operator. oh come on. that logic covers making totally broken routers available to operators' choice. ron's point was that this is a bad choice and the ietf should not be standardizing or blessing bad choices. randy From raszuk@cisco.com Wed Apr 6 16:07:39 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4803A6801 for ; Wed, 6 Apr 2011 16:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75Zlxsh-6WSW for ; Wed, 6 Apr 2011 16:07:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E25093A67E1 for ; Wed, 6 Apr 2011 16:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=206; q=dns/txt; s=iport; t=1302131363; x=1303340963; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3cd+oo/ZN2DAdIeIPXCElOPQi5YqBpI0vOmCPUVgkWM=; b=LRSxeTlrW64nh/rA8YkrUQHTU31mALXdG+KFYaz+nLINEopgd6Q75pIS 6+1nfZMm5FZVTZP4KJD0Z2nKOznnivdNd0bFn0LoERhhY21FlQUQR+1V7 py0L5UL+C4CPZKSrv6qu8hXd+eVGHFQhA8OlgAHbm33HLtZjQrXQfkBBS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADDynE2rRDoH/2dsb2JhbACmAHeIeZ4bgnMOAZlxhWwEjT2DZg X-IronPort-AV: E=Sophos;i="4.63,313,1299456000"; d="scan'208";a="425209345" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 06 Apr 2011 23:09:23 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p36N9LJD013282; Wed, 6 Apr 2011 23:09:22 GMT Message-ID: <4D9CF2A5.3010603@cisco.com> Date: Thu, 07 Apr 2011 01:09:25 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Randy Bush References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 23:07:39 -0000 > the ietf should not be standardizing or blessing bad choices. Truly golden statement ! And I wish it would apply to all choices IETF makes what should be standardized and what not ..... R. From ilya@nobulus.com Wed Apr 6 16:47:41 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710203A6948 for ; Wed, 6 Apr 2011 16:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHzUm3eQzRKt for ; Wed, 6 Apr 2011 16:47:40 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 072EE3A6801 for ; Wed, 6 Apr 2011 16:47:39 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 2EA1717425; Thu, 7 Apr 2011 01:49:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RVYpV1occrSa; Thu, 7 Apr 2011 01:49:21 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id A0F5E1732F; Thu, 7 Apr 2011 01:49:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> Date: Thu, 7 Apr 2011 01:49:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> To: Ronald Bonica , "idr@ietf.org List" X-Mailer: Apple Mail (2.1084) Cc: Robert Raszuk Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 23:47:41 -0000 Ron, let me add few words to what Robert has already said in his response. On Apr 6, 2011, at 23:43 , Ronald Bonica wrote: > Folks, >=20 > I would like to discourage adoption of this draft for the following = reasons: >=20 > 1) A relatively inexpensive solution to this problem is already = available. That is, to deploy slightly larger number of route reflectors = and to assign clients to reflectors based upon IGP distance. >=20 (speaking as operator) consider a ring of several dozens of PoP's, two = edge routers in each, and extensive set of external peers per router. = Distance between PoP's is noticeable, and calls for careful selection of = the exit. If we don't deploy route reflector at each PoP we will have to = send way too many alternative path's. On the other hand deploying route = reflector at each PoP only halves number of participants in the full = mesh, while increasing cost significantly because route reflectors need = to support very large number of prefixes (both Internet and VPN) so they = would need to be high-end devices. =46rom operator perspective BGP-ORR = solution looks more appealing. > 2) The solutions described in this draft do not scale well. In = particular, it is not clear how the solution described in Section 3 = works when the BGP domain is so large that it does not fit in a single = IGP area. Even if the BGP domain were to fit in a single IGP area, the = solution described in Section 3 becomes computationally expensive if the = domain contains many POPs. >=20 (as author of complementary draft) Originally presented at IETF79 = solution with exchanging next-hop cost within BGP itself was meant to be = part of BGP-ORR draft. But since BGP-ORR does not change neither BGP = messages nor algorithm (only source of some info changes) whereas = carrying next-hop cost in BGP naturally calls for extension to the = protocol, this solution has been published as separate draft (NH SAFI). Kind regards, iLya From ub@cs.uni-bonn.de Wed Apr 6 23:44:57 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55A83A6863 for ; Wed, 6 Apr 2011 23:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3etmcY-s9BeH for ; Wed, 6 Apr 2011 23:44:53 -0700 (PDT) Received: from postfix.iai.uni-bonn.de (postfix.iai.uni-bonn.de [131.220.8.4]) by core3.amsl.com (Postfix) with ESMTP id 3C7273A67F3 for ; Wed, 6 Apr 2011 23:44:52 -0700 (PDT) X-IAI-Env-From: : [77.11.6.7] Received: from pad-wlan-workingroomub.fritz.box (koln-4d0b0607.pool.mediaWays.net [77.11.6.7]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id BD7F75C401; Thu, 7 Apr 2011 08:46:35 +0200 (MEST) (envelope-from ub@cs.uni-bonn.de) (envelope-to VARIOUS) (4) (internal use: ta=1, tu=1, te=1, am=P, au=ub) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8--418431332 From: Uli Bornhauser In-Reply-To: <726E8DAC-A0ED-44A7-9D8D-0A55BA364B5B@juniper.net> Date: Thu, 7 Apr 2011 08:46:39 +0200 Message-Id: <4FA78F62-0AD8-4B9A-87E0-8C9F68414DC9@cs.uni-bonn.de> References: <1D23749D4168CC4D8B8652397B5F643204E57756@XMB-RCD-206.cisco.com> <726E8DAC-A0ED-44A7-9D8D-0A55BA364B5B@juniper.net> To: "idr@ietf.org List" , John Scudder X-Mailer: Apple Mail (2.1084) Cc: "Alvaro Retana \(aretana\)" Subject: Re: [Idr] BGP Persistent Route Oscillation Solutions as WG item X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 06:44:57 -0000 --Apple-Mail-8--418431332 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi John, Alvaro, all, Am 31.03.2011 um 09:26 schrieb John Scudder: > Please send comments to the list by April 14, 2011. >=20 > I note there was some discussion of this on the list around May 10-12 = 2010, which wasn't resolved. Folks may want to take a look at the = archives. thanks for bringing this point up. Unfortunately, the new -04 draft = still does not solve the problem (or I oversaw a simple solution). As = defined in the current version, IMO the BGP path selection process may = still come to a non-defined state. Doesn't it make sense to solve this = fundamental problem first and then let the draft become a WG item? Best Regards Uli PS: For those who are interested in the problem but do not remember it = any more, here a quick refresh: Using the draft as specified, situations = may happen where BGP speakers cannot select a unique best path any more. = Here is an example: | p1-> |----| | ------| | | |----| | \ / \ AS1 / \ -----------/ |----| 1 |----| | R1 |-----| R2 | -----------\ |----| |----| AS2 \ / / / \ p2-> |----| | ------| | | |----| | We assume equivalent global attributes for p1 and p2. If both paths are = reflected by R1 to R2, R2 learns two paths of same preference. We have = an unsolved tie-breaker situation. BGP's path selection process as = defined by RFC4271 (and extensions) does not take this situation into = account. All details may be found in my emails sent on May, 11th and = 12,th 2010. Finally, a general remark: As advertising group best paths is a serious = modification, IMHO it could make sense to search for other interactions = that cause unwanted side effects. This is only an example showing that = principal problems exist. >=20 > --John >=20 > On Mar 30, 2011, at 11:34 AM, Alvaro Retana (aretana) wrote: >=20 >> Hi! >>=20 >> The 'BGP Persistent Route Oscillation Solutions' draft has been = stable >> for quite some time; here's the latest version (no changes, just a >> refresh): >> http://tools.ietf.org/html/draft-walton-bgp-route-oscillation-stop-04 >>=20 >> I would like to request that this draft become a WG item. >>=20 >> As a reminder, I included the abstract below. >>=20 >> Thanks!! >>=20 >> Alvaro. >>=20 >>=20 >> Abstract >>=20 >> In this document we present two sets of paths for an address prefix >> that can be advertised by a BGP route reflector or confederation = ASBR >> to eliminate the MED-induced route oscillations in a network. The >> first set involves all the available paths, and would achieve the >> same routing consistency as the full IBGP mesh. The second set, >> which is a subset of the first one, involves the neighbor-AS based >> Group Best Paths, and would be sufficient to eliminate the MED- >> induced route oscillations (subject to certain commonly adopted >> topological constrains). >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --=20 _______________________________________________________ ULI BORNHAUSER University of Bonn - Institute of Computer Science 4 Friedrich-Ebert-Allee 144 - D 53113 Bonn - Germany Web: www.cs.bonn.edu/IV/ub Email: ub@cs.uni-bonn.de =09 Phone: +49 (228) 73 - 54219 Fax: +49 (228) 73 - 4571 --Apple-Mail-8--418431332 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = John, Alvaro, all,

Am 31.03.2011 um 09:26 schrieb = John Scudder:

Please = send comments to the list by April 14, 2011.

I note there was = some discussion of this on the list around May 10-12 2010, which wasn't = resolved.  Folks may want to take a look at the = archives.

thanks for = bringing this point up. Unfortunately, the new -04 draft still = does not solve the problem (or I oversaw a simple solution). As defined = in the current version, IMO the BGP path selection process may still = come to a non-defined state. Doesn't it make sense to solve this = fundamental problem first and then let the draft become a WG = item?

Best = Regards

Uli

PS: For = those who are interested in the problem but do not remember it any more, = here a quick refresh: Using the draft as specified, situations may = happen where BGP speakers cannot select a unique best path any more. = Here is an example:

       =        |
p1->  |----|  |
------| =    |  |
      |----| =  |
            \ = /
             \
AS1   =       / \
-----------/  |----|  1 =  |----|
              | = R1 |-----| R2 |
-----------\  |----|     |----|
AS2 =         \ /
         =     /
            / = \
p2->  |----|  |
------|    | =  |
      |----| =  |

We assume equivalent global = attributes for p1 and p2. If both paths are reflected by R1 to R2, R2 = learns two paths of same preference. We have an unsolved tie-breaker = situation. BGP's path selection process as defined by RFC4271 (and = extensions) does not take this situation into account. All details may = be found in my emails sent on May, 11th and 12,th = 2010.

Finally, a general remark: As advertising = group best paths is a serious modification, IMHO it could make sense to = search for other interactions that cause unwanted side effects. This is = only an example showing that principal problems = exist.


--John

On = Mar 30, 2011, at 11:34 AM, Alvaro Retana (aretana) = wrote:

Hi!

The 'BGP = Persistent Route Oscillation Solutions' draft has been = stable
for quite some time; = here's the latest version (no changes, just = a
refresh):
http://tools.ietf.org/html/draft-walton-bgp-route-oscillation-stop-04=

I would like to = request that this draft become a WG item.

As a reminder, = I included the abstract below.

Thanks!!

Alvaro.


Abstract

 In this = document we present two sets of paths for an address = prefix
 that can be = advertised by a BGP route reflector or confederation = ASBR
 to eliminate the = MED-induced route oscillations in a network. =  The
 first set = involves all the available paths, and would achieve = the
 same routing = consistency as the full IBGP mesh.  The second = set,
 which is a subset = of the first one, involves the neighbor-AS = based
 Group Best Paths, = and would be sufficient to eliminate the = MED-
 induced route = oscillations (subject to certain commonly = adopted
 topological = constrains).
_______________________________________________
Idr mailing = list
Idr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/idr

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

-- 
________________________________= _______________________
ULI BORNHAUSER
University of Bonn - = Institute of Computer Science 4
Friedrich-Ebert-Allee 144 - D 53113 = Bonn - Germany

Web: www.cs.bonn.edu/IV/ub
Email: = ub@cs.uni-bonn.de =
Phone: +49 (228) 73 - 54219
Fax: +49 (228) 73 - = 4571

= --Apple-Mail-8--418431332-- From paul@jakma.org Thu Apr 7 03:15:45 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D363A68F7 for ; Thu, 7 Apr 2011 03:15:45 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDC+jIPlOiwx for ; Thu, 7 Apr 2011 03:15:43 -0700 (PDT) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by core3.amsl.com (Postfix) with ESMTP id 702A728C0CF for ; Thu, 7 Apr 2011 03:15:42 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk [130.209.244.4]) (authenticated bits=0) by hibernia.jakma.org (8.14.4/8.14.3) with ESMTP id p37AGj9e002627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2011 11:16:50 +0100 Date: Thu, 7 Apr 2011 11:16:40 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Ronald Bonica In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> Message-ID: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "raszuk@cisco.com" , "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 10:15:45 -0000 On Wed, 6 Apr 2011, Ronald Bonica wrote: > Folks, > > I would like to discourage adoption of this draft for the following reasons: > > 1) A relatively inexpensive solution to this problem is already > available. That is, to deploy slightly larger number of route > reflectors and to assign clients to reflectors based upon IGP > distance. And in that vein: http://tools.ietf.org/html/draft-jakma-idr-stable-bgp-rr-00 As has been pointed out to me by Robert though, this can not address cases where BGP and forwarding topology are quite divorced (the various overlay / tunneling things that exist to hack around various shortcomings of IP), particularly when RR clients sessions are deliberately distributed to RRs far and wide in order to load-share the BGP/control-plane overhead. But for the forwarding / aligned-topology case it seems a simple and neat solution. regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: "Protozoa are small, and bacteria are small, but viruses are smaller than the both put together." From bruno.decraene@orange-ftgroup.com Thu Apr 7 03:24:23 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34EF28C0DF for ; Thu, 7 Apr 2011 03:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOsvGvq3nsTY for ; Thu, 7 Apr 2011 03:24:23 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id B93CF3A69BD for ; Thu, 7 Apr 2011 03:24:22 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A6BFB6D8003; Thu, 7 Apr 2011 12:26:40 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 9B1A26C8003; Thu, 7 Apr 2011 12:26:40 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 12:26:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2011 12:26:05 +0200 Message-ID: In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] BGP Optimal Route Reflection (BGP-ORR) Thread-Index: AcvvqGJnqSPv/KSSRPS8KPumlVkgmwE9+vVQABkIGNA= References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> From: To: , , X-OriginalArrivalTime: 07 Apr 2011 10:26:06.0751 (UTC) FILETIME=[34640AF0:01CBF50E] Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 10:24:23 -0000 Ron, I understand your view and can certainly agree on some points. Let me present a different perspective. > 1) A relatively inexpensive solution to this problem is already = available. That is, to deploy slightly > larger number of route reflectors and to assign clients to reflectors = based upon IGP distance. Agreed. Now, where should we place those RR functions? I see a few options: - on existing core routers used for packet forwarding. Chosen closed to = its clients. Pro: That definitely works on some ASes. Con: Others ASes (e.g. BGP free core) may have a policy to not run BGP = on P routers. - on a dedicated router collocated with the above "core" router. Pro: good topological/IGP location (near its sets of clients). Con: There is typically a mismatch between the low speed interface = needed/available on the RR and the high speed interfaces available on = the core router. - on a edge router connected to the above core router Pro: good match of interface speed. RR box chosen for its control plane = performance (hard & soft), independently of the forwarding box. Control = & forwarding plane hardware/software/configuration can be upgraded = independently. Con: Not so good IGP location (biased point of view) - in a centralized location, in a "service" POP Pro: idem above. Con: Bad IGP location. IMO, to allow for flexibility, it would be useful to be able to = physically place a RR in a location, and to logically place it in a = different location (RR computes IGP costs as if it were somewhere else = in the network. Cf =A73.2). > 2) The solutions described in this draft do not scale well.=20 Now indeed, there is a whole range of options, from a single IGP/BGP = computation per RR, to one IGP/BGP computation per group of clients, up = to one IGP/BGP computation per client. With different tradeoffs. Taking your above use case (a "slightly larger number of RR"), having = the ability to place the RR functions anywhere does not change the = scaling. On the contrary, you now have the ability to run the RR = functions on a reduce number of boxes and simplify the iBGP topology = (smaller iBGP full mesh between RR or avoiding an addition level of RR = hierarchy). > In particular, it is not clear how the > solution described in Section 3 works when the BGP domain is so large = that it does not fit in a single > IGP area. Even if the BGP domain were to fit in a single IGP area, the = solution described in Section 3 > becomes computationally expensive if the domain contains many POPs. >=20 > 3) The solution described in Section 4 is operationally complex. While = it is theoretically possible to > assign an angular position to each rr client, in some network = topologies, this is easier said than > done. AFAICS, calculation and configuration of the angular position is = always a manual operation. > Angular positions must be re-evaluated periodically, to account for = the addition of network links. Draft discusses different options with different tradeoff. Personally, I = would tend to agree with you and would probably not use the option = proposed in section 4. But discussions on "complexity" are usually about = a tradeoff between perceived benefits and perceived costs... Regards, Bruno =20 From raszuk@cisco.com Thu Apr 7 03:31:53 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BF128C0DF for ; Thu, 7 Apr 2011 03:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.521 X-Spam-Level: X-Spam-Status: No, score=-11.521 tagged_above=-999 required=5 tests=[AWL=1.078, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdUK5STge6Q7 for ; Thu, 7 Apr 2011 03:31:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0BECA3A68EF for ; Thu, 7 Apr 2011 03:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2140; q=dns/txt; s=iport; t=1302172416; x=1303382016; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wsm+i2bbkj56lxgPCdmQiUdiurPaFwM76xtfGkjMAPw=; b=Xn1hZmlxr8C5/Mp3M57l1aoadN57tg9O0h4t+3ctxUZA46uJPv4mJNej TkEo7WAoemMZS1gSquHHFbL/DGmGntmC2CdHa24gvY0XyBCaZTXQBaob1 4eTzzJ23VQ4OGx6tyrpqnjzYKJ9/ohBu6R20O+NVSt69nvAAjwTalWYR6 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM6RnU2rRDoI/2dsb2JhbACmBHeIeZw8gnMOAZlnhW0EjUWDaA X-IronPort-AV: E=Sophos;i="4.63,315,1299456000"; d="scan'208";a="332396948" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2011 10:33:36 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p37AXZeA010238; Thu, 7 Apr 2011 10:33:35 GMT Message-ID: <4D9D9304.7070501@cisco.com> Date: Thu, 07 Apr 2011 12:33:40 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Paul Jakma References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 10:31:53 -0000 Hi Paul, Very good comment indeed. On that very point just to explain more I have spent significant amount of time traveling between NANOG, RIPE and other smaller NOGs last year to talk about good, old fashioned RR design where RRs are in the data plane or at least where clients are "behind" RRs. Nothing beats this both from optimal path selection as well as from fast connectivity restoration for almost no additional burden and cost (case where RRs are in data plane on POP to core boundary). Some references ... http://www.nanog.org/meetings/nanog48/presentations/Tuesday/Raszuk_To_AddPaths_N48.pdf http://ripe60.ripe.net/presentations/Raszuk-To_add-paths_or_not_to_add-paths.pdf Then I got number of comments from real world operators that even though they do agree in principle with my slides the suggestions will no longer apply to their architectures as their networks are infected by 4 letter forwarding encapsulation paradigm. That was the trigger to start work on Optimal Route Reflection document where control plane RRs can be placed in arbitrary network location without compromising hot potato routing principle. Many thx, R. > On Wed, 6 Apr 2011, Ronald Bonica wrote: > >> Folks, >> >> I would like to discourage adoption of this draft for the following >> reasons: >> >> 1) A relatively inexpensive solution to this problem is already >> available. That is, to deploy slightly larger number of route >> reflectors and to assign clients to reflectors based upon IGP distance. > > And in that vein: > > http://tools.ietf.org/html/draft-jakma-idr-stable-bgp-rr-00 > > As has been pointed out to me by Robert though, this can not address > cases where BGP and forwarding topology are quite divorced (the various > overlay / tunneling things that exist to hack around various > shortcomings of IP), particularly when RR clients sessions are > deliberately distributed to RRs far and wide in order to load-share the > BGP/control-plane overhead. > > But for the forwarding / aligned-topology case it seems a simple and > neat solution. > > regards, From paul@jakma.org Thu Apr 7 04:09:23 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901403A68EF for ; Thu, 7 Apr 2011 04:09:23 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giqr8jGButdw for ; Thu, 7 Apr 2011 04:09:23 -0700 (PDT) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by core3.amsl.com (Postfix) with ESMTP id 149993A68A7 for ; Thu, 7 Apr 2011 04:09:18 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk [130.209.244.4]) (authenticated bits=0) by hibernia.jakma.org (8.14.4/8.14.3) with ESMTP id p37BAWca003322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2011 12:10:36 +0100 Date: Thu, 7 Apr 2011 12:10:27 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Robert Raszuk In-Reply-To: <4D9D9304.7070501@cisco.com> Message-ID: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9D9304.7070501@cisco.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Inter-Domain Routing List Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paul@jakma.org, Inter-Domain Routing List List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 11:09:23 -0000 On Thu, 7 Apr 2011, Robert Raszuk wrote: > On that very point just to explain more I have spent significant > amount of time traveling between NANOG, RIPE and other smaller NOGs > last year to talk about good, old fashioned RR design where RRs are > in the data plane or at least where clients are "behind" RRs. > Nothing beats this both from optimal path selection as well as from > fast connectivity restoration for almost no additional burden and > cost (case where RRs are in data plane on POP to core boundary). AFAIK, you still need to tweak BGP though in this case to be sure to avoid oscillations, IMU. E.g. some thing like using CLUSTER_LIST to apply a consistent ordering to decisions, as per Flavel and Roughan's work. Thanks for the links - very interesting! regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: Save energy: be apathetic. From jsw@inconcepts.biz Thu Apr 7 06:26:22 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B216B3A6916 for ; Thu, 7 Apr 2011 06:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.102 X-Spam-Level: X-Spam-Status: No, score=-3.102 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU-CRHJ+sJ5v for ; Thu, 7 Apr 2011 06:26:22 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id DA7093A690F for ; Thu, 7 Apr 2011 06:26:21 -0700 (PDT) Received: by vxg33 with SMTP id 33so2318026vxg.31 for ; Thu, 07 Apr 2011 06:28:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.76 with SMTP id cv12mr260666vcb.128.1302182885871; Thu, 07 Apr 2011 06:28:05 -0700 (PDT) Received: by 10.220.182.132 with HTTP; Thu, 7 Apr 2011 06:28:05 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9D9304.7070501@cisco.com> Date: Thu, 7 Apr 2011 09:28:05 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 13:26:23 -0000 I had emailed Robert about this off-list, as I have not followed this discussion closely (limited time in the day), but he suggested I post it to the list for consideration. ---------- Forwarded message ---------- From: Jeff Wheeler Date: Thu, Apr 7, 2011 at 9:13 AM Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) To: raszuk@cisco.com On Thu, Apr 7, 2011 at 6:33 AM, Robert Raszuk wrote: > Then I got number of comments from real world operators that even though > they do agree in principle with my slides the suggestions will no longer > apply to their architectures as their networks are infected by 4 letter > forwarding encapsulation paradigm. I have not posted on these topics because I don't have enough time to follow more than a few issues, but when I read your post this morning I wanted to give you an additional point in support of your idea. Having route-reflectors in the "data plane" can add to cost, plain and simple. I have more CPU/RAM for BGP available on few-thousand-dollars branch office type routers and other current-model < $5k devices than I have on my older, yet still useful and in production, DFZ routers. =A0BGP / control plane limits have forced me to upgrade numerous routers over the years because they simply do not have enough RAM or fast enough CPU for being DFZ routers anymore. =A0If I was doing much R-R on these boxes I would have had to upgrade them many years ago. I don't want to replace a 6500/SUP720-3BXL or a M160 that is still working fine, for the purpose of packets in -> packets out, just because my iBGP mesh has grown too large and the box no longer has enough control plane resources to converge quickly. =A0That upgrade costs a lot more than a few thousand dollars. The network need not make use of MPLS to see a cost advantage from moving R-R duties out of the data plane. -- Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From randy@psg.com Thu Apr 7 07:59:02 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1F0B3A69C6 for ; Thu, 7 Apr 2011 07:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsnNWtipuqL5 for ; Thu, 7 Apr 2011 07:59:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 4E1F93A6946 for ; Thu, 7 Apr 2011 07:59:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7qgF-0008LJ-2p; Thu, 07 Apr 2011 14:59:31 +0000 Date: Thu, 07 Apr 2011 07:59:30 -0700 Message-ID: From: Randy Bush To: Jeff Wheeler In-Reply-To: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9D9304.7070501@cisco.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 14:59:02 -0000 > The network need not make use of MPLS to see a cost advantage from > moving R-R duties out of the data plane. history has repeatedly shown that, when the control plane and the data plane, in fact any two layers, are not congruent, debugging and other opex costs go quite badly. randy From jsw@inconcepts.biz Thu Apr 7 08:40:59 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092193A6A13 for ; Thu, 7 Apr 2011 08:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa4y-dfyoBIr for ; Thu, 7 Apr 2011 08:40:58 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 646E53A6A11 for ; Thu, 7 Apr 2011 08:40:58 -0700 (PDT) Received: by vxg33 with SMTP id 33so2463316vxg.31 for ; Thu, 07 Apr 2011 08:42:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.135 with SMTP id ei7mr1472412vdb.229.1302190962626; Thu, 07 Apr 2011 08:42:42 -0700 (PDT) Received: by 10.220.182.132 with HTTP; Thu, 7 Apr 2011 08:42:42 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9D9304.7070501@cisco.com> Date: Thu, 7 Apr 2011 11:42:42 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 15:40:59 -0000 On Thu, Apr 7, 2011 at 10:59 AM, Randy Bush wrote: > history has repeatedly shown that, when the control plane and the data > plane, in fact any two layers, are not congruent, debugging and other > opex costs go quite badly. If you want the BGP control plane and data plane to have identical topologies, then you had better do one of these things: * confederate and make every router its own sub-AS * make every router an R-R client of every other router * install links between every router and every other router (full mesh) If you have not done this, your iBGP mesh is already a control plane with a different topology for signalling than your data plane for bearing traffic. It's designed to work that way. Since you enjoy arguing in useless generalities, rather than the practical world, I suggest you stay away from telephony. The PSTN has relied on SS7 for inter-office signalling for quite some time. Perhaps you would care to share some specific accounts of incidents where dedicated route-reflectors have caused you debugging difficulty or increased operational expense which offset the cost advantage of deferring upgrades to backbone routers. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From hannes@juniper.net Thu Apr 7 09:51:22 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306A928C164 for ; Thu, 7 Apr 2011 09:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmRAJ7lBzDhH for ; Thu, 7 Apr 2011 09:51:19 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id A3CE328C168 for ; Thu, 7 Apr 2011 09:51:15 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ3r6ylHTARZa0A6+9ceAmcI5SX3XZBX@postini.com; Thu, 07 Apr 2011 09:53:01 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Thu, 7 Apr 2011 09:48:45 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id B52FD25AE0; Thu, 7 Apr 2011 18:50:35 +0200 (CEST) Date: Thu, 7 Apr 2011 18:50:35 +0200 From: Hannes Gredler To: Robert Raszuk Message-ID: <20110407161756.GA7617@juniper.net> References: <4D9482E7.5010905@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4D9482E7.5010905@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:51:22 -0000 hi robert, i have mixed feelings about this draft: 1. downside: there is no real advantage in terms of computational load. i.e. it is a zero-sum game - you are proposing to _centralize_ a _distributed_ computation by moving (BGP per-POP best-path selection, non-self-rooted IGP calculation) from the clients to the RR. i am bit worried if RRs can be scaled up enough to support "enough" distinct POPs. note: ilya's next-hop AF cost NLRI solves the IGP calculation nicely, but has the usual deployment-tax of new protocols (especially since we need to consider that new software needs to get deployed on older control-plane CPUs). 2. upside: section - 3.2. Configuration-based flexible route reflector placement. this is a neat idea, as one can deploy central RRs in the data-center and still get decent path-diversity. suggestion: any hard feelings about spinning out section 3.2 into a "Virtualized Route Reflection" draft, where all the implications wrt to IGP changes, BGP route resolver changes etc. are described in more detail ? - i can contribute some text if you want; /hannes On Thu, Mar 31, 2011 at 03:34:31PM +0200, Robert Raszuk wrote: | | Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document | would like to propose the adoption of this work as the IDR WG item. | | Ref: | http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 From shane@castlepoint.net Thu Apr 7 09:58:18 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6717728C16A for ; Thu, 7 Apr 2011 09:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdh4q940LQld for ; Thu, 7 Apr 2011 09:58:17 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 1E7AA28C160 for ; Thu, 7 Apr 2011 09:58:17 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C7719268037; Thu, 7 Apr 2011 11:00:01 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 07 Apr 2011 11:00:01 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=54057; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Thu, 7 Apr 2011 11:00:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9D9304.7070501@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:58:18 -0000 On Apr 7, 2011, at 8:59 AM, Randy Bush wrote: >> The network need not make use of MPLS to see a cost advantage from >> moving R-R duties out of the data plane. >=20 > history has repeatedly shown that, when the control plane and the data > plane, in fact any two layers, are not congruent, debugging and other > opex costs go quite badly. To be clear, "not congruent" should not be taken to mean "perfectly = congruent", i.e.: one must run RR's on Core or PE routers. Said = differently, history also shows that even though the speeds + feeds + = data-plane features in routers are [generally] more than adequate for = several years of useful life; however, CPU + DRAM in RE's/RP's have = traditionally *not* kept pace with the need for moderate to fast = convergence of the RIB, (let alone the added 'stress' of acting as a = RR). =20 In case it's not clear from the above, I have read this draft and = support it's adoption as a WG draft. -shane= From randy@psg.com Thu Apr 7 10:05:12 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298283A694F for ; Thu, 7 Apr 2011 10:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TQychJpCvYx for ; Thu, 7 Apr 2011 10:05:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 8D6023A67CF for ; Thu, 7 Apr 2011 10:05:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7sfW-0008q8-BP; Thu, 07 Apr 2011 17:06:54 +0000 Date: Thu, 07 Apr 2011 10:06:53 -0700 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9D9304.7070501@cisco.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:05:12 -0000 >> history has repeatedly shown that, when the control plane and the >> data plane, in fact any two layers, are not congruent, debugging and >> other opex costs go quite badly. > To be clear, "not congruent" should not be taken to mean "perfectly > congruent" my damned mac keeps running out of ink > ie.: one must run RR's on Core or PE routers. that can not forward the traffic? randy From shane@castlepoint.net Thu Apr 7 10:30:34 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E0F3A6955 for ; Thu, 7 Apr 2011 10:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5ZlAP+lbcGh for ; Thu, 7 Apr 2011 10:30:33 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id DD0183A6823 for ; Thu, 7 Apr 2011 10:30:33 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id B1F3C268037; Thu, 7 Apr 2011 11:32:18 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 07 Apr 2011 11:32:18 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=54270; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Thu, 7 Apr 2011 11:32:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <405FC7A3-A1AE-4369-ADB7-17059430269C@castlepoint.net> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9D9304.7070501@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:30:34 -0000 On Apr 7, 2011, at 11:06 AM, Randy Bush wrote: >>> history has repeatedly shown that, when the control plane and the >>> data plane, in fact any two layers, are not congruent, debugging and >>> other opex costs go quite badly. >> To be clear, "not congruent" should not be taken to mean "perfectly >> congruent" >=20 > my damned mac keeps running out of ink :-) >> ie.: one must run RR's on Core or PE routers. >=20 > that can not forward the traffic? I'm not sure what you're getting at. Like many design choices, = dedicated, "out-of-band" RR's are a trade-off, each operator gets to = make, currently between 'congruency' vs. moderate to fast convergence. =20= - route-reflection is /already/ a CPU and memory (DRAM) intensive = process; - RR's need to consume several [very] large Adj-RIB-In's from their iBGP = peers (RR's at the same level of the RR hierarchy) as well as a much = smaller number of (best-path) routes from downstream RR clients. OTOH, RR-clients (typically, PE's), only need to hold Adj-RIB-In from = their eBGP peers (customers/peers) as well as a much, much smaller = Adj-RIB-In from (two) upstream RR's. Just given the existence of the ORR + NH-SAFI drafts, should point out = that many operators have already gone done the path of "out-of-band" = RR's and are [finally] seeking improvements to get back to [optimal] = congruency. -shane= From raszuk@cisco.com Thu Apr 7 10:33:16 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207AC28C157 for ; Thu, 7 Apr 2011 10:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYLyPwLiOMWo for ; Thu, 7 Apr 2011 10:33:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A3CE728C141 for ; Thu, 7 Apr 2011 10:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=4190; q=dns/txt; s=iport; t=1302197699; x=1303407299; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Sy2XCcYVItcTSX8vc8QpR+k/QbNSgHwK4t+QRzVprk4=; b=acCh34FaQd3ZV2EAgB/FjF9WhhDjV5UXJ3sCv6TprG3thmSWyjkF6uAh uVGZKNhPIXQJA9/7phtTEM2GVySl0cmbBRhb33U3mlEWSI8rsd50JUfw2 C6b8PjVT2wsTFbqfQwGEOUFUO9DR1FewyXY2u9eOO7Tta4Y87PyZgjdYR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHT1nU2rRDoI/2dsb2JhbACmCHeIcgebW4JzDgGZV4VtBI1Fg2g X-IronPort-AV: E=Sophos;i="4.63,317,1299456000"; d="scan'208";a="332677661" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2011 17:34:59 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p37HYviH032266; Thu, 7 Apr 2011 17:34:58 GMT Message-ID: <4D9DF5C6.9050901@cisco.com> Date: Thu, 07 Apr 2011 19:35:02 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hannes Gredler References: <4D9482E7.5010905@cisco.com> <20110407161756.GA7617@juniper.net> In-Reply-To: <20110407161756.GA7617@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:33:16 -0000 Hello Hannes, > 1. downside: > there is no real advantage in terms of > computational load. i.e. it is a zero-sum game - > you are proposing to _centralize_ a _distributed_ computation > by moving (BGP per-POP best-path selection, non-self-rooted IGP > calculation) from the clients to the RR. i am bit worried if RRs can be > scaled up enough to support "enough" distinct POPs. It is not a zero-sum game. Even if you would need to perform customized path selection and customized update generation for each client it would still be much better then pushing all domain external paths to all clients and allow them to select the best and optimal path. It is even more of a non zero-sum game due to the fact that Optimal Reflection easily allows to group clients and generate optimal best path for the group of them which both saves the total sum of network processing and amount of BGP state other wise needed to be distributed and maintain across all clients. There are number of other advantages which are very important to keep in mind: * Even if you would place RRs within each POP (not acting as ABR) it will only have visibility into given POP. While intra POP best path selection will be optimal inter-POP BGP best path selection will be far from optimal. * As you are very well aware we already have all the tools in the implementations to allow non-self-rooted IGP calculations. We do it for all surrounding nodes during LFA. As it has been already indicated on the list before there are algorithms allowing for implementation optimizations in this space as well if it turns out that there is a need. * The point of computational load needs to be substantial and demonstrated in practice in order to start considering this or any proposal as "too heavy". I have not seen any solid data proving that RR implementation could not run 20-50 non-self-rooted SPFs (including all SPF optimizations). As a matter of fact you may only need as many SPFs or update generations as many unique BGP next hops you have if you take an up-side down BGP implementation design into consideration. > note: ilya's next-hop AF cost NLRI solves the IGP calculation > nicely, but has the usual deployment-tax of new protocols > (especially since we need to consider that new software > needs to get deployed on older control-plane CPUs). Ilya's proposal is extremely light way of providing the nh metric. And no this is not a new protocol as such, but an extension to existing protocol. If your worry is that it would have problems to be deployed due to CPU processing power limits I think you may be envisioning something very different then what is currently in the spec. NH SAFI does not require any new computation overhead. It just lifts the values already present and sends it over new BGP SAFI. > 2. upside: > section - 3.2. Configuration-based flexible route reflector > placement. this is a neat idea, as one can deploy central > RRs in the data-center and still get decent path-diversity. > > suggestion: > any hard feelings about spinning out section 3.2 into > a "Virtualized Route Reflection" draft, where all the implications > wrt to IGP changes, BGP route resolver changes etc. are described > in more detail ? - i can contribute some text if you want; It is true that section 3.2 of the current spec was invented as a side product and it has it's own value even if used as stand-alone. However it has even greater value if used together with optimal route reflection. And considering all support received from number of network operators both on the list as well as off the list for the draft as is today I would not like to separate it from the main spec at this point. Many thx, R. > On Thu, Mar 31, 2011 at 03:34:31PM +0200, Robert Raszuk wrote: > | > | Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document > | would like to propose the adoption of this work as the IDR WG item. > | > | Ref: > | http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 > From randy@psg.com Thu Apr 7 10:56:53 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB61C3A6966 for ; Thu, 7 Apr 2011 10:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kWWdlSsxr6F for ; Thu, 7 Apr 2011 10:56:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 704383A695D for ; Thu, 7 Apr 2011 10:56:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7tTY-00092T-BD; Thu, 07 Apr 2011 17:58:36 +0000 Date: Thu, 07 Apr 2011 10:58:35 -0700 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: <405FC7A3-A1AE-4369-ADB7-17059430269C@castlepoint.net> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9D9304.7070501@cisco.com> <405FC7A3-A1AE-4369-ADB7-17059430269C@castlepoint.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:56:54 -0000 >>> ie.: one must run RR's on Core or PE routers. >> that can not forward the traffic? > - route-reflection is /already/ a CPU and memory (DRAM) intensive > process; > - RR's need to consume several [very] large Adj-RIB-In's those are RE loads. should still be able to forward. > Just given the existence of the ORR + NH-SAFI drafts, should point out > that many operators have already gone done the path of "out-of-band" > RR's and are [finally] seeking improvements to get back to [optimal] > congruency. i usually suspect that the number of drafts is an indicator of resume issues, not useful technology. if i was in a deeper curmudgeonly mood i might comment on adding more kludge in an attempt to ameliorate a poor design choice. randy From hannes@juniper.net Thu Apr 7 10:59:07 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7702A3A695F for ; Thu, 7 Apr 2011 10:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCi9hV8TJiZP for ; Thu, 7 Apr 2011 10:59:06 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 4EB2B3A695D for ; Thu, 7 Apr 2011 10:59:05 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ370SbWwQmDpCwMueEZ/dptO/6jK14O@postini.com; Thu, 07 Apr 2011 11:00:51 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Thu, 7 Apr 2011 10:57:08 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 1AF57254EA; Thu, 7 Apr 2011 19:58:59 +0200 (CEST) Date: Thu, 7 Apr 2011 19:58:59 +0200 From: Hannes Gredler To: Robert Raszuk Message-ID: <20110407175858.GB8101@juniper.net> References: <4D9482E7.5010905@cisco.com> <20110407161756.GA7617@juniper.net> <4D9DF5C6.9050901@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4D9DF5C6.9050901@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:59:07 -0000 On Thu, Apr 07, 2011 at 07:35:02PM +0200, Robert Raszuk wrote: | Hello Hannes, | | >1. downside: | > there is no real advantage in terms of | > computational load. i.e. it is a zero-sum game - | > you are proposing to _centralize_ a _distributed_ computation | > by moving (BGP per-POP best-path selection, non-self-rooted IGP | > calculation) from the clients to the RR. i am bit worried if RRs can be | > scaled up enough to support "enough" distinct POPs. | | It is not a zero-sum game. | | Even if you would need to perform customized path selection and | customized update generation for each client it would still be much | better then pushing all domain external paths to all clients and | allow them to select the best and optimal path. guess my main concern here is that on RRs you have typically a single peer-group. your proposal forces the RRs to have N peer-groups (at least one per POP). so update generation is not as cheap as it used to be. | It is even more of a non zero-sum game due to the fact that Optimal | Reflection easily allows to group clients and generate optimal best | path for the group of them which both saves the total sum of network | processing and amount of BGP state other wise needed to be | distributed and maintain across all clients. | | There are number of other advantages which are very important to | keep in mind: | | * Even if you would place RRs within each POP (not acting as ABR) it | will only have visibility into given POP. While intra POP best path | selection will be optimal inter-POP BGP best path selection will be | far from optimal. | | * As you are very well aware we already have all the tools in the | implementations to allow non-self-rooted IGP calculations. We do it | for all surrounding nodes during LFA. As it has been already | indicated on the list before there are algorithms allowing for | implementation optimizations in this space as well if it turns out | that there is a need. | | * The point of computational load needs to be substantial and | demonstrated in practice in order to start considering this or any | proposal as "too heavy". I have not seen any solid data proving that | RR implementation could not run 20-50 non-self-rooted SPFs | (including all SPF optimizations). As a matter of fact you may only | need as many SPFs or update generations as many unique BGP next hops | you have if you take an up-side down BGP implementation design into | consideration. you are right, usually router vendors know how to get this right. do you think that the additional internal peer-groups for update generation come for free ? | > note: ilya's next-hop AF cost NLRI solves the IGP calculation | > nicely, but has the usual deployment-tax of new protocols | > (especially since we need to consider that new software | > needs to get deployed on older control-plane CPUs). | | Ilya's proposal is extremely light way of providing the nh metric. | And no this is not a new protocol as such, but an extension to | existing protocol. If your worry is that it would have problems to | be deployed due to CPU processing power limits I think you may be | envisioning something very different then what is currently in the | spec. my reasoning is as such: usually proto-extensions are available for the lastest software release, - later software releases have typically a larger footprint, and since this work is targeted at preserving older infrastructure, i am wondering if this is practicaly feasible. | NH SAFI does not require any new computation overhead. It just lifts | the values already present and sends it over new BGP SAFI. i understand that, but i'd assume (unless your company has found the magic key to unbloat software ;-)) that a potential optimal-RR/next-hop AFI enabled software comes with a software release, which has storage/mem/cpu requirements not suitable to the routers which the feature tries to protect. | >2. upside: | > section - 3.2. Configuration-based flexible route reflector | > placement. this is a neat idea, as one can deploy central | > RRs in the data-center and still get decent path-diversity. | > | >suggestion: | > any hard feelings about spinning out section 3.2 into | > a "Virtualized Route Reflection" draft, where all the implications | > wrt to IGP changes, BGP route resolver changes etc. are described | > in more detail ? - i can contribute some text if you want; | | It is true that section 3.2 of the current spec was invented as a | side product and it has it's own value even if used as stand-alone. | However it has even greater value if used together with optimal | route reflection. | | And considering all support received from number of network | operators both on the list as well as off the list for the draft as | is today I would not like to separate it from the main spec at this | point. bummer; for the record, i do not support this draft as a wg-item, since it breaks the most important scaling tool available on RRs. which is efficient update generation through a single peer-group. /hannes | >On Thu, Mar 31, 2011 at 03:34:31PM +0200, Robert Raszuk wrote: | >| | >| Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document | >| would like to propose the adoption of this work as the IDR WG item. | >| | >| Ref: | >| http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 | > | From jgs@juniper.net Thu Apr 7 14:10:09 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22613A6974 for ; Thu, 7 Apr 2011 14:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWQK292oh3ca for ; Thu, 7 Apr 2011 14:10:09 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 08B5E3A67CC for ; Thu, 7 Apr 2011 14:10:08 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ4omLGg/YxYoDiNO6ZDWD/z/s8E620A@postini.com; Thu, 07 Apr 2011 14:11:54 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 7 Apr 2011 14:08:34 -0700 From: John Scudder To: "raszuk@cisco.com" Date: Thu, 7 Apr 2011 14:10:17 -0700 Thread-Topic: [Idr] BGP Optimal Route Reflection (BGP-ORR) Thread-Index: Acv1Z/PnUcnIoZ43SRuc0hkcv+0lXQ== Message-ID: <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> In-Reply-To: <4D9CE4D3.9060401@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 21:10:10 -0000 On Apr 6, 2011, at 6:10 PM, Robert Raszuk wrote: ... >> Even if the BGP domain were to fit in a single IGP >> area, the solution described in Section 3 becomes computationally >> expensive if the domain contains many POPs. >=20 > Let me point out that what may be computationally expensive for one RR=20 > platform may not provide a significant load for some other RR=20 > implementation on other choice of computational platform. Therefor your=20 > above stated comment seems to be very subjective and quite narrowly=20 > focused. It depends on how you construe "computationally expensive". I had my compu= ter science big-O scaling glasses on, and from that point of view I think R= on's comment is right on. Your response seems to express the view that if = you have a platform with a factor of N headroom, you may not care that some= of BGP's core computations have gotten N times more expensive. =20 As an outline, components of increased cost include: - Best path run per distinct group of clients - Update generation and queueing per distinct group of clients - Possibly, IGP run per distinct group of clients (I realize this=20 is optional in some variants; the others are not) A straightforward Theory of Comp 101 analysis of the relevant algorithms sa= ys that no matter how much you finesse your implementation, you are going t= o increase the costs of several of the key computations of the BGP protocol= , at least those listed above. The increase will be at best linear in the = number of topologically distinct groups of clients. Another way of thinking about this is that you'll need similar computationa= l resources on your converged RR as you need on distributed set of RRs. If= you're replacing 10 RRs with one converged one, you will need something li= ke 10x the computes and memory on that converged box. Some economy of scal= e may be possible but remember that sometimes you get diseconomies of scale= too, such as the step function to upgrade to a larger and more complex box= . This doesn't mean that the proposal is infeasible. People may want to impl= ement software for, install and maintain fewer, much larger, boxes. But it= does mean that the costs have to be very clearly understood and not hand-w= aved over. With my individual contributor hat and other clothing items on, I discourag= e adoption of this draft until the scaling implications are more clearly el= ucidated. I realize Section 5 touches on this briefly but I think a more r= igorous analysis is called for. --John= From raszuk@cisco.com Thu Apr 7 14:46:55 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0DC3A69E2 for ; Thu, 7 Apr 2011 14:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf4FR5xXM9Pw for ; Thu, 7 Apr 2011 14:46:54 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5C4B83A67CC for ; Thu, 7 Apr 2011 14:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=5020; q=dns/txt; s=iport; t=1302212919; x=1303422519; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zEM66jF2Fq343+svqAQb+sY/g1de2tOASyLcOFAbjWw=; b=mJRBvMUaSUp7dihEZimnd5QuQ7mNeQY+3yEfYM26Dn+5uMgJwxdVNHnS /uNLw9MkAmL0HbR1yOQYywFNELhQmS7boTX6pYG71jZNodf8fpcngd8Ge n3UKaqK/P6zoOQH5dqwMtZk5LYK+2baUOPCs0VaXo7SKRXfL1XvJyEJit U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPcvnk2rRDoJ/2dsb2JhbACmEHeIeZtrgnMOAZlEhW0EjUWDaA X-IronPort-AV: E=Sophos;i="4.63,319,1299456000"; d="scan'208";a="332851135" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2011 21:48:39 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p37LmbRp008527; Thu, 7 Apr 2011 21:48:38 GMT Message-ID: <4D9E313A.5070000@cisco.com> Date: Thu, 07 Apr 2011 23:48:42 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Scudder References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> In-Reply-To: <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 21:46:55 -0000 Hi John, Since you asked for it please allow me to focus and summarize few facts which should address comments from you, Ron and Hannes which perhaps just accidentally are all from the same page: * It is a well known fact that routers have limited CPUs as compared with industry computing platforms. Even CPU refresh of an average computing platform does happen much more frequently then respin of any RP or RE in the router. Leave alone the cost of it. However let me point out that once we are discussing control plane RRs those do not need to run on routers. * It is also to be observed that some routing operating systems already for years are 64 bit and can easily address large amount of memory while some other operating systems are still 32 bit and the work is just in progress to move them to 64 bit. While I could prove in the numbers some particular platforms scaling data I do not believe that this sort of marketing data is a proper argument to be used in any of the IETF working groups and I find it improper. With this in mind it is perfectly understood that if someone does not have a right car to participate in the race they will discourage or perhaps even attempt to try to call off the tournament all together even before the race starts. Please allow me to "more clearly elucidate" that basic tests over linux home made PC reveal that even running 50 separate instances of BGP each generating updates of full IPv4 real Internet table feed of 10 paths to group of clients does not indicate any significant CPU or processing burden. And this is 50 independent IGPs too without any optimization between SPFs. After all there are multi CPU motherboards in Fry's today with each CPU containing 4-6 cores. Last let's keep in mind that by adopting a work item which clearly already has indicated a strong support among real world operators we are allowing to officially work on it within IDR. It is not last call, it is not place to review the implementation reports and compare it's implementation scaling numbers. I do hope that you as the IDR co-chair will recognize this and would in fact encourage this or perhaps many other similar proposals to be adopted within the working group in spite of the fact that some of the vendor's may have an issue with commercially productizing them today. Best regards, R. > On Apr 6, 2011, at 6:10 PM, Robert Raszuk wrote: ... >>> Even if the BGP domain were to fit in a single IGP area, the >>> solution described in Section 3 becomes computationally expensive >>> if the domain contains many POPs. >> >> Let me point out that what may be computationally expensive for one >> RR platform may not provide a significant load for some other RR >> implementation on other choice of computational platform. Therefor >> your above stated comment seems to be very subjective and quite >> narrowly focused. > > It depends on how you construe "computationally expensive". I had my > computer science big-O scaling glasses on, and from that point of > view I think Ron's comment is right on. Your response seems to > express the view that if you have a platform with a factor of N > headroom, you may not care that some of BGP's core computations have > gotten N times more expensive. > > As an outline, components of increased cost include: > > - Best path run per distinct group of clients - Update generation and > queueing per distinct group of clients - Possibly, IGP run per > distinct group of clients (I realize this is optional in some > variants; the others are not) > > A straightforward Theory of Comp 101 analysis of the relevant > algorithms says that no matter how much you finesse your > implementation, you are going to increase the costs of several of the > key computations of the BGP protocol, at least those listed above. > The increase will be at best linear in the number of topologically > distinct groups of clients. > > Another way of thinking about this is that you'll need similar > computational resources on your converged RR as you need on > distributed set of RRs. If you're replacing 10 RRs with one > converged one, you will need something like 10x the computes and > memory on that converged box. Some economy of scale may be possible > but remember that sometimes you get diseconomies of scale too, such > as the step function to upgrade to a larger and more complex box. > > This doesn't mean that the proposal is infeasible. People may want > to implement software for, install and maintain fewer, much larger, > boxes. But it does mean that the costs have to be very clearly > understood and not hand-waved over. > > With my individual contributor hat and other clothing items on, I > discourage adoption of this draft until the scaling implications are > more clearly elucidated. I realize Section 5 touches on this briefly > but I think a more rigorous analysis is called for. > > --John From ilya@nobulus.com Thu Apr 7 15:29:53 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A8428C17E for ; Thu, 7 Apr 2011 15:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B08UgDpefXh8 for ; Thu, 7 Apr 2011 15:29:52 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 2508028C17A for ; Thu, 7 Apr 2011 15:29:52 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 206D61743C; Fri, 8 Apr 2011 00:31:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VLL1SDV0LLdv; Fri, 8 Apr 2011 00:31:33 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 8993717428; Fri, 8 Apr 2011 00:31:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> Date: Fri, 8 Apr 2011 00:31:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: "raszuk@cisco.com" , "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 22:29:53 -0000 John, On Apr 7, 2011, at 23:10 , John Scudder wrote: > As an outline, components of increased cost include: >=20 > - Best path run per distinct group of clients > - Update generation and queueing per distinct group of clients > - Possibly, IGP run per distinct group of clients (I realize this=20 > is optional in some variants; the others are not) >=20 > A straightforward Theory of Comp 101 analysis of the relevant = algorithms says that no matter how much you finesse your implementation, = you are going to increase the costs of several of the key computations = of the BGP protocol, at least those listed above. The increase will be = at best linear in the number of topologically distinct groups of = clients. >=20 I think Best Path and IGP computations will have less than linear = increase of cost. For Best Path if you sort next-hops in "certain way" = you can calculate Best Path in single traversal of the RIB, spending = more time not on every step but only when next-hops are considered, = which grows less than linearly. Some blocks of Update Generation could = be potentially optimised in similar fashion or even done at the same = time. For IGP it has been already shown some month's ago that algorithms = exist that could find multiple shortest paths in single go, may be even = with the same O-complexity as some routers may already use now for = single-rooted SPF calculations. Have I misunderstood something? > Another way of thinking about this is that you'll need similar = computational resources on your converged RR as you need on distributed = set of RRs. If you're replacing 10 RRs with one converged one, you will = need something like 10x the computes and memory on that converged box. = Some economy of scale may be possible but remember that sometimes you = get diseconomies of scale too, such as the step function to upgrade to a = larger and more complex box. >=20 Upgrading memory on one RR won't cost as much as 10 complete boxes. On = the other hand, it looks like there is better-than-linear scaleability, = in which case we don't even need 10 times better hardware. /iLya From marka888@gmail.com Fri Apr 8 00:12:32 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74CB13A6A44 for ; Fri, 8 Apr 2011 00:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ms2geoT9CnmN for ; Fri, 8 Apr 2011 00:12:31 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 155E33A6889 for ; Fri, 8 Apr 2011 00:12:31 -0700 (PDT) Received: by vws12 with SMTP id 12so3058356vws.31 for ; Fri, 08 Apr 2011 00:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=y6AlWvjiZuxbCDAfQ+8kO+r7Sp0A+yAMMLGEgEvXn18=; b=nRwIqZ1LZlf+jXBDMSJvQcB6lSAteKKbHcl7fh0W+ie+Ex2LI5rMzh4ACK14kOASAP ZcK5zrzF4z6XJFoVenPTZM8M/nhxgue1RnS/fr+OPtFz3W6sOj4Y5SW8vIeMkSJ9jeX5 sRPVa5cQEyHRibxmttTxKfohzLThbOrI2UkXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hzX/6gfIiogvARiv1cilxgULaAgGrVU5DOK2oFgpUFtbulnBow4oFkqEORGXmNDbgY iZxf8lcNyhLjUcA/vKVABMgvnu5bhaWMXQ3Fq/kmSi0DK2rlc43t3hjZpDVNe1r8iIhd 7rvdCXntGUGbFEG73ddlH1OJpMatMtBxbzJsw= MIME-Version: 1.0 Received: by 10.52.167.161 with SMTP id zp1mr2560374vdb.276.1302246854608; Fri, 08 Apr 2011 00:14:14 -0700 (PDT) Received: by 10.52.88.48 with HTTP; Fri, 8 Apr 2011 00:14:14 -0700 (PDT) In-Reply-To: <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> Date: Fri, 8 Apr 2011 17:14:14 +1000 Message-ID: From: Mark Austen To: Ilya Varlashkin Content-Type: multipart/alternative; boundary=bcaec53f8e3d2dce1c04a062f96e Cc: "raszuk@cisco.com" , "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 07:12:32 -0000 --bcaec53f8e3d2dce1c04a062f96e Content-Type: text/plain; charset=ISO-8859-1 >From an operators perspective I fully support the solutions put forward in this draft. They provide the best approach that I have seen so far to ensure a centralized route reflector selects the optimal BGP route for a client. On 8 April 2011 08:31, Ilya Varlashkin wrote: > John, > > On Apr 7, 2011, at 23:10 , John Scudder wrote: > > > As an outline, components of increased cost include: > > > > - Best path run per distinct group of clients > > - Update generation and queueing per distinct group of clients > > - Possibly, IGP run per distinct group of clients (I realize this > > is optional in some variants; the others are not) > > > > A straightforward Theory of Comp 101 analysis of the relevant algorithms > says that no matter how much you finesse your implementation, you are going > to increase the costs of several of the key computations of the BGP > protocol, at least those listed above. The increase will be at best linear > in the number of topologically distinct groups of clients. > > > > I think Best Path and IGP computations will have less than linear increase > of cost. For Best Path if you sort next-hops in "certain way" you can > calculate Best Path in single traversal of the RIB, spending more time not > on every step but only when next-hops are considered, which grows less than > linearly. Some blocks of Update Generation could be potentially optimised in > similar fashion or even done at the same time. For IGP it has been already > shown some month's ago that algorithms exist that could find multiple > shortest paths in single go, may be even with the same O-complexity as some > routers may already use now for single-rooted SPF calculations. Have I > misunderstood something? > > > Another way of thinking about this is that you'll need similar > computational resources on your converged RR as you need on distributed set > of RRs. If you're replacing 10 RRs with one converged one, you will need > something like 10x the computes and memory on that converged box. Some > economy of scale may be possible but remember that sometimes you get > diseconomies of scale too, such as the step function to upgrade to a larger > and more complex box. > > > Upgrading memory on one RR won't cost as much as 10 complete boxes. On the > other hand, it looks like there is better-than-linear scaleability, in which > case we don't even need 10 times better hardware. > > /iLya > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --bcaec53f8e3d2dce1c04a062f96e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From an operators=A0perspective=A0I fully support the solutions put forward= in this draft. They provide the best approach that I have seen so far to e= nsure a centralized route reflector selects the optimal BGP route for a cli= ent.

On 8 April 2011 08:31, Ilya Varlashkin = <ilya@nobulus.com<= /a>> wrote:
John,

On Apr 7, 2011, at 23:10 , John Scudder wrote:

> As an outline, components of increased cost include:
>
> - Best path run per distinct group of clients
> - Update generation and queueing per distinct group of clients
> - Possibly, IGP run per distinct group of clients (I realize this
> =A0is optional in some variants; the others are not)
>
> A straightforward Theory of Comp 101 analysis of the relevant algorith= ms says that no matter how much you finesse your implementation, you are go= ing to increase the costs of several of the key computations of the BGP pro= tocol, at least those listed above. =A0The increase will be at best linear = in the number of topologically distinct groups of clients.
>

I think Best Path and IGP computations will have less than linear inc= rease of cost. For Best Path if you sort next-hops in "certain way&quo= t; you can calculate Best Path in single traversal of the RIB, spending mor= e time not on every step but only when next-hops are considered, which grow= s less than linearly. Some blocks of Update Generation could be potentially= optimised in similar fashion or even done at the same time. For IGP it has= been already shown some month's ago that algorithms exist that could f= ind multiple shortest paths in single go, may be even with the same O-compl= exity as some routers may already use now for single-rooted SPF calculation= s. Have I misunderstood something?

> Another way of thinking about this is that you'll need similar com= putational resources on your converged RR as you need on distributed set of= RRs. =A0If you're replacing 10 RRs with one converged one, you will ne= ed something like 10x the computes and memory on that converged box. =A0Som= e economy of scale may be possible but remember that sometimes you get dise= conomies of scale too, such as the step function to upgrade to a larger and= more complex box.
>
Upgrading memory on one RR won't cost as much as 10 complete boxe= s. On the other hand, it looks like there is better-than-linear scaleabilit= y, in which case we don't even need 10 times better hardware.

/iLya

--bcaec53f8e3d2dce1c04a062f96e-- From russ@cisco.com Fri Apr 8 05:29:42 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F813A68DC for ; Fri, 8 Apr 2011 05:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.526 X-Spam-Level: X-Spam-Status: No, score=-10.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfkyWSUVQVzM for ; Fri, 8 Apr 2011 05:29:41 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EB7283A68C0 for ; Fri, 8 Apr 2011 05:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1270; q=dns/txt; s=iport; t=1302265887; x=1303475487; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=0joNC+GjvPz9SHaww+728cmfh5x42kgmQUrCYtKwwfQ=; b=ggLtpgudjk417HgJ6THW4qS2eL0pglPvVP3qVjyIHGEUBWHS0a8UdOSw M/SLhFpuOkmG5ESOfcr6KpFeac8h+N7WiwWZ5qwpYCA81pkLfTdT9Hu17 c8ACW3V88+ada+rR+BCZaxYS2N6E1aCpSORbAo0M1uAzqzQenpELC6Tfx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwIAKD/nk2tJXHA/2dsb2JhbACZAY0Ud6RonDWFbQSNToNq X-IronPort-AV: E=Sophos;i="4.63,323,1299456000"; d="scan'208";a="229549819" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-2.cisco.com with ESMTP; 08 Apr 2011 12:31:24 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p38CVOc8005494 for ; Fri, 8 Apr 2011 12:31:24 GMT Message-ID: <4D9F0004.7000409@cisco.com> Date: Fri, 08 Apr 2011 08:31:00 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: idr@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 12:29:42 -0000 I support this draft for WG adoption. The solution proposed in section 3 seems fairly trivial given the widespread use of multiple SPFs, and the tradeoff at the BGP level seems to be mostly about shifting processing from one point in the network to another (as John as pointed out) --but isn't this the point of virtualizing just about anything? One nit: == In the case of a hierarchical IGP deployment where the client is in a different level in the hierarchy to the route reflector, the route reflector will compute IGP distance to the BGP nexthop from the Area Border Routers (ABR) leading to the client in lieu of the route reflector client itself, and use the shortest distance from these ABRs to the nexthop. == It seems like this should be extended for IS-IS (?). Or are we assuming L1/L2 routers can use the same terminology here? For the solution outlined in section 4 --it seems to be fairly computationally expensive today, but then again, SPF itself was fairly computationally expensive when first used for OSPF/IS-IS --over time, people have figured out how to reduce the computational expense to a much more reasonable level. I would see this as more of a future solution, but well worth documenting and working on. Russ From jgs@juniper.net Fri Apr 8 12:02:10 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0181F3A6A10 for ; Fri, 8 Apr 2011 12:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFHZQzCtgGUk for ; Fri, 8 Apr 2011 12:02:08 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id E3A863A6A17 for ; Fri, 8 Apr 2011 12:02:07 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ9cFyoIurASmht7VGcgpC6k0EOIuyJV@postini.com; Fri, 08 Apr 2011 12:03:53 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 8 Apr 2011 11:59:52 -0700 From: John Scudder To: "raszuk@cisco.com" Date: Fri, 8 Apr 2011 12:01:37 -0700 Thread-Topic: [Idr] BGP Optimal Route Reflection (BGP-ORR) Thread-Index: Acv2HyRC3+jnhiWQTeKpswFw9veKbQ== Message-ID: <5F07C910-B796-4577-982E-87F9F091438C@juniper.net> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <4D9E313A.5070000@cisco.com> In-Reply-To: <4D9E313A.5070000@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:02:10 -0000 Robert, With regard to your points that bigger boxes can be built: Yes of course. = In fact I directly addressed this point in my previous message. =20 Your exclusive focus in your reply on proving that bigger boxes can be buil= t maybe is an implicit agreement with my analysis of the computational comp= lexity of an ORR -- that is, maybe you are agreeing that there is no free l= unch, an ORR will require more compute resources than a current RR. In tha= t case, we are close to being on the same page. The fact that bigger boxes= can be built has nothing to do with analysis of the proposal's computation= al complexity. [*] In my reading of both the draft and the conversation to= date it seems as though there is (what may be) too much optimism about the= ability to optimize ORR code to perform at equal scale on current hardware= . That may be possible with current workloads. It very likely may not. I= t definitely will not with a pessimal workload. (See also my reply to Ilya= .) I am perplexed by your apparent dismissal of the value of understanding of = the proposal's intrinsic scaling properties. I realize this is not an acad= emic conference but I assume that most of us as protocol designers have som= e Computer Science background and understand there is a place for analysis = of computational complexity. To draw an analogy to mechanical engineering,= it is not always necessary to build a bridge and watch it fall down in ord= er to know there was something wrong with its design. [**] So, to be clear: My concern is that those who are supporting the proposal's= adoption should understand that we are talking about replacing N smaller b= oxes with one box containing O(N) times the compute resources. I want to b= e sure the proposal is not being represented (and bought) as a free lunch. = People become justifiably upset when their free lunch turns out to have a = cost. On the other hand, if the WG has considered the cost of the lunch an= d wants to buy and eat it, OK. --John [*] http://en.wikipedia.org/wiki/Computational_complexity [**] This is an analogy, meant to illustrate the value of analysis as oppos= ed to pure build-it-and-try-it or throw-more-hardware-at-it hacking. It is= NOT meant to be an opinion about the value of the current proposal. On Apr 7, 2011, at 5:48 PM, Robert Raszuk wrote: > Hi John, >=20 > Since you asked for it please allow me to focus and summarize few facts=20 > which should address comments from you, Ron and Hannes which perhaps=20 > just accidentally are all from the same page: >=20 > * It is a well known fact that routers have limited CPUs as compared=20 > with industry computing platforms. Even CPU refresh of an average=20 > computing platform does happen much more frequently then respin of any=20 > RP or RE in the router. Leave alone the cost of it. However let me point= =20 > out that once we are discussing control plane RRs those do not need to=20 > run on routers. >=20 > * It is also to be observed that some routing operating systems already=20 > for years are 64 bit and can easily address large amount of memory while= =20 > some other operating systems are still 32 bit and the work is just in=20 > progress to move them to 64 bit. >=20 > While I could prove in the numbers some particular platforms scaling=20 > data I do not believe that this sort of marketing data is a proper=20 > argument to be used in any of the IETF working groups and I find it=20 > improper. >=20 > With this in mind it is perfectly understood that if someone does not=20 > have a right car to participate in the race they will discourage or=20 > perhaps even attempt to try to call off the tournament all together even= =20 > before the race starts. >=20 > Please allow me to "more clearly elucidate" that basic tests over linux=20 > home made PC reveal that even running 50 separate instances of BGP each=20 > generating updates of full IPv4 real Internet table feed of 10 paths to=20 > group of clients does not indicate any significant CPU or processing=20 > burden. And this is 50 independent IGPs too without any optimization=20 > between SPFs. After all there are multi CPU motherboards in Fry's today=20 > with each CPU containing 4-6 cores. >=20 > Last let's keep in mind that by adopting a work item which clearly=20 > already has indicated a strong support among real world operators we are= =20 > allowing to officially work on it within IDR. It is not last call, it is= =20 > not place to review the implementation reports and compare it's=20 > implementation scaling numbers. I do hope that you as the IDR co-chair=20 > will recognize this and would in fact encourage this or perhaps many=20 > other similar proposals to be adopted within the working group in spite=20 > of the fact that some of the vendor's may have an issue with=20 > commercially productizing them today. >=20 > Best regards, > R. >=20 >> On Apr 6, 2011, at 6:10 PM, Robert Raszuk wrote: ... >>>> Even if the BGP domain were to fit in a single IGP area, the >>>> solution described in Section 3 becomes computationally expensive >>>> if the domain contains many POPs. >>>=20 >>> Let me point out that what may be computationally expensive for one >>> RR platform may not provide a significant load for some other RR >>> implementation on other choice of computational platform. Therefor >>> your above stated comment seems to be very subjective and quite >>> narrowly focused. >>=20 >> It depends on how you construe "computationally expensive". I had my >> computer science big-O scaling glasses on, and from that point of >> view I think Ron's comment is right on. Your response seems to >> express the view that if you have a platform with a factor of N >> headroom, you may not care that some of BGP's core computations have >> gotten N times more expensive. >>=20 >> As an outline, components of increased cost include: >>=20 >> - Best path run per distinct group of clients - Update generation and >> queueing per distinct group of clients - Possibly, IGP run per >> distinct group of clients (I realize this is optional in some >> variants; the others are not) >>=20 >> A straightforward Theory of Comp 101 analysis of the relevant >> algorithms says that no matter how much you finesse your >> implementation, you are going to increase the costs of several of the >> key computations of the BGP protocol, at least those listed above. >> The increase will be at best linear in the number of topologically >> distinct groups of clients. >>=20 >> Another way of thinking about this is that you'll need similar >> computational resources on your converged RR as you need on >> distributed set of RRs. If you're replacing 10 RRs with one >> converged one, you will need something like 10x the computes and >> memory on that converged box. Some economy of scale may be possible >> but remember that sometimes you get diseconomies of scale too, such >> as the step function to upgrade to a larger and more complex box. >>=20 >> This doesn't mean that the proposal is infeasible. People may want >> to implement software for, install and maintain fewer, much larger, >> boxes. But it does mean that the costs have to be very clearly >> understood and not hand-waved over. >>=20 >> With my individual contributor hat and other clothing items on, I >> discourage adoption of this draft until the scaling implications are >> more clearly elucidated. I realize Section 5 touches on this briefly >> but I think a more rigorous analysis is called for. >>=20 >> --John >=20 From jgs@juniper.net Fri Apr 8 12:02:13 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEC63A6A1C for ; Fri, 8 Apr 2011 12:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffJfqJ6Bl1zk for ; Fri, 8 Apr 2011 12:02:13 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id B6F673A6A1B for ; Fri, 8 Apr 2011 12:02:12 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ9cGdJh1EKxZ1CBA69vtKJNcGT3YvZG@postini.com; Fri, 08 Apr 2011 12:03:58 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 8 Apr 2011 11:59:55 -0700 From: John Scudder To: Ilya Varlashkin Date: Fri, 8 Apr 2011 12:01:40 -0700 Thread-Topic: [Idr] BGP Optimal Route Reflection (BGP-ORR) Thread-Index: Acv2HyXZurR3TbsnTlaqLox5lTx6lw== Message-ID: <18DC58C5-2C04-4E12-BE18-D93E041CEE2C@juniper.net> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> In-Reply-To: <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "raszuk@cisco.com" , "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:02:13 -0000 Ilya, Thank you for responding on-topic! =20 After giving your message some thought it seems to me that you are pointing= out that there is scope for optimization such that the expected cost under= some workloads will be less than O(N) in the number of topologically disti= nct groups. Granted, but please note several things: - The upper bound is still O(N). - AFAICT your implicit assumption is that many routes will tie-break before= the=20 IGP step is reached. But for such routes, the behavior of a current RR i= s the same as an ORR. Thus if the ORR is interesting, that would seem to demon= strate=20 that the expected workload does include many routes that tie-break at or = after=20 the IGP step. - This seems to indicate that the optimizations you mention would not often= come=20 into play for the expected workload. - I'm primarily concerned with the costs inherent in the BGP protocol here.= I=20 tried to be clear in my previous that I'm willing for sake of argument to= neglect any IGP related costs. Also, please remember that O(N) doesn't mean "is N times higher" it means "= is linearly higher". (That's what I was trying to get at by "... *somethin= g* *like* 10x ...") I don't see how you get to the conclusion that "it looks like there is bett= er-than-linear scaleability", unless you are talking about the expected cas= e under a workload that tie-breaks before the IGP step, in which case I've = already argued you don't even need an ORR. In closing let me repeat my remark to Robert: My concern is that those who = are supporting the proposal's adoption should understand that we are talkin= g about replacing N smaller boxes with one box containing O(N) times the co= mpute resources. No free lunch. Thanks, --John On Apr 7, 2011, at 6:31 PM, Ilya Varlashkin wrote: > John, >=20 > On Apr 7, 2011, at 23:10 , John Scudder wrote: >=20 >> As an outline, components of increased cost include: >>=20 >> - Best path run per distinct group of clients >> - Update generation and queueing per distinct group of clients >> - Possibly, IGP run per distinct group of clients (I realize this=20 >> is optional in some variants; the others are not) >>=20 >> A straightforward Theory of Comp 101 analysis of the relevant algorithms= says that no matter how much you finesse your implementation, you are goin= g to increase the costs of several of the key computations of the BGP proto= col, at least those listed above. The increase will be at best linear in t= he number of topologically distinct groups of clients. >>=20 >=20 > I think Best Path and IGP computations will have less than linear increas= e of cost. For Best Path if you sort next-hops in "certain way" you can cal= culate Best Path in single traversal of the RIB, spending more time not on = every step but only when next-hops are considered, which grows less than li= nearly. Some blocks of Update Generation could be potentially optimised in = similar fashion or even done at the same time. For IGP it has been already = shown some month's ago that algorithms exist that could find multiple short= est paths in single go, may be even with the same O-complexity as some rout= ers may already use now for single-rooted SPF calculations. Have I misunder= stood something? >=20 >> Another way of thinking about this is that you'll need similar computati= onal resources on your converged RR as you need on distributed set of RRs. = If you're replacing 10 RRs with one converged one, you will need something= like 10x the computes and memory on that converged box. Some economy of s= cale may be possible but remember that sometimes you get diseconomies of sc= ale too, such as the step function to upgrade to a larger and more complex = box. >>=20 > Upgrading memory on one RR won't cost as much as 10 complete boxes. On th= e other hand, it looks like there is better-than-linear scaleability, in wh= ich case we don't even need 10 times better hardware. >=20 > /iLya >=20 >=20 >=20 From raszuk@cisco.com Fri Apr 8 12:20:37 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65FB13A6975 for ; Fri, 8 Apr 2011 12:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.55 X-Spam-Level: X-Spam-Status: No, score=-10.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF2xW3k3tE7R for ; Fri, 8 Apr 2011 12:20:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2A9973A69B4 for ; Fri, 8 Apr 2011 12:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=8745; q=dns/txt; s=iport; t=1302290540; x=1303500140; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=AAVP+MtNekc2jGPB5u12n84XyXbZrnQ3RpgZg6+15hQ=; b=dFOvmRO1cA7oIv/02D292PfVDvUIqUfAJVawPiVaTn9lbBR91y91O1El 3AHyi+QJnAbmDQct8M90/hvhDl9y6QZdKwLzzx5avA/GZXwaVAcfdo24I 7lzNKGcEzSXz25Tv9/8zF6shTM+Yeh7245r3BOhULRZzMP5HwPY4d4z8P I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALZfn02rRDoH/2dsb2JhbACmFneIepxUgnMOAZkOhW0EjU6Dag X-IronPort-AV: E=Sophos;i="4.63,325,1299456000"; d="scan'208";a="678219507" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 08 Apr 2011 19:22:17 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p38JMFVF015139; Fri, 8 Apr 2011 19:22:16 GMT Message-ID: <4D9F606E.1080205@cisco.com> Date: Fri, 08 Apr 2011 21:22:22 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Scudder References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <4D9E313A.5070000@cisco.com> <5F07C910-B796-4577-982E-87F9F091438C@juniper.net> In-Reply-To: <5F07C910-B796-4577-982E-87F9F091438C@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:20:37 -0000 Hi John, Except one point below I do agree with your comments. > In my reading of both the draft and the conversation to date it seems > as though there is (what may be) too much optimism about the ability > to optimize ORR code to perform at equal scale on current hardware. It really depends what you define as the "current hardware". If by "current hardware" you mean currently deployed route reflectors which would get new software and they automagically be able to perform N times more computations per sec - I think everyone on the list is clear that this is not the assumptions the draft makes. However if by "current hardware" you mean currently available control plane computing platforms on the market which do have much more computing power then 10s of current route reflectors for fraction of current route reflector's cost than I do not see any substantial data which would prove that such hardware can not easily meet the computational requirements of the ORR draft in question. Best regards, R. > Robert, > > With regard to your points that bigger boxes can be built: Yes of > course. In fact I directly addressed this point in my previous > message. > > Your exclusive focus in your reply on proving that bigger boxes can > be built maybe is an implicit agreement with my analysis of the > computational complexity of an ORR -- that is, maybe you are > agreeing that there is no free lunch, an ORR will require more > compute resources than a current RR. In that case, we are close to > being on the same page. The fact that bigger boxes can be built has > nothing to do with analysis of the proposal's computational > complexity. [*] In my reading of both the draft and the conversation > to date it seems as though there is (what may be) too much optimism > about the ability to optimize ORR code to perform at equal scale on > current hardware. That may be possible with current workloads. It > very likely may not. It definitely will not with a pessimal workload. > (See also my reply to Ilya.) > > I am perplexed by your apparent dismissal of the value of > understanding of the proposal's intrinsic scaling properties. I > realize this is not an academic conference but I assume that most of > us as protocol designers have some Computer Science background and > understand there is a place for analysis of computational > complexity. To draw an analogy to mechanical engineering, it is not > always necessary to build a bridge and watch it fall down in order to > know there was something wrong with its design. [**] > > So, to be clear: My concern is that those who are supporting the > proposal's adoption should understand that we are talking about > replacing N smaller boxes with one box containing O(N) times the > compute resources. I want to be sure the proposal is not being > represented (and bought) as a free lunch. People become justifiably > upset when their free lunch turns out to have a cost. On the other > hand, if the WG has considered the cost of the lunch and wants to > buy and eat it, OK. > > --John > > [*] http://en.wikipedia.org/wiki/Computational_complexity > > [**] This is an analogy, meant to illustrate the value of analysis > as opposed to pure build-it-and-try-it or throw-more-hardware-at-it > hacking. It is NOT meant to be an opinion about the value of the > current proposal. > > On Apr 7, 2011, at 5:48 PM, Robert Raszuk wrote: > >> Hi John, >> >> Since you asked for it please allow me to focus and summarize few >> facts which should address comments from you, Ron and Hannes which >> perhaps just accidentally are all from the same page: >> >> * It is a well known fact that routers have limited CPUs as >> compared with industry computing platforms. Even CPU refresh of an >> average computing platform does happen much more frequently then >> respin of any RP or RE in the router. Leave alone the cost of it. >> However let me point out that once we are discussing control plane >> RRs those do not need to run on routers. >> >> * It is also to be observed that some routing operating systems >> already for years are 64 bit and can easily address large amount >> of memory while some other operating systems are still 32 bit and >> the work is just in progress to move them to 64 bit. >> >> While I could prove in the numbers some particular platforms >> scaling data I do not believe that this sort of marketing data is >> a proper argument to be used in any of the IETF working groups and >> I find it improper. >> >> With this in mind it is perfectly understood that if someone does >> not have a right car to participate in the race they will >> discourage or perhaps even attempt to try to call off the >> tournament all together even before the race starts. >> >> Please allow me to "more clearly elucidate" that basic tests over >> linux home made PC reveal that even running 50 separate instances >> of BGP each generating updates of full IPv4 real Internet table >> feed of 10 paths to group of clients does not indicate any >> significant CPU or processing burden. And this is 50 independent >> IGPs too without any optimization between SPFs. After all there >> are multi CPU motherboards in Fry's today with each CPU containing >> 4-6 cores. >> >> Last let's keep in mind that by adopting a work item which clearly >> already has indicated a strong support among real world operators >> we are allowing to officially work on it within IDR. It is not >> last call, it is not place to review the implementation reports >> and compare it's implementation scaling numbers. I do hope that you >> as the IDR co-chair will recognize this and would in fact >> encourage this or perhaps many other similar proposals to be >> adopted within the working group in spite of the fact that some of >> the vendor's may have an issue with commercially productizing them >> today. >> >> Best regards, R. >> >>> On Apr 6, 2011, at 6:10 PM, Robert Raszuk wrote: ... >>>>> Even if the BGP domain were to fit in a single IGP area, the >>>>> solution described in Section 3 becomes computationally >>>>> expensive if the domain contains many POPs. >>>> >>>> Let me point out that what may be computationally expensive >>>> for one RR platform may not provide a significant load for >>>> some other RR implementation on other choice of computational >>>> platform. Therefor your above stated comment seems to be very >>>> subjective and quite narrowly focused. >>> >>> It depends on how you construe "computationally expensive". I >>> had my computer science big-O scaling glasses on, and from that >>> point of view I think Ron's comment is right on. Your response >>> seems to express the view that if you have a platform with a >>> factor of N headroom, you may not care that some of BGP's core >>> computations have gotten N times more expensive. >>> >>> As an outline, components of increased cost include: >>> >>> - Best path run per distinct group of clients - Update >>> generation and queueing per distinct group of clients - Possibly, >>> IGP run per distinct group of clients (I realize this is optional >>> in some variants; the others are not) >>> >>> A straightforward Theory of Comp 101 analysis of the relevant >>> algorithms says that no matter how much you finesse your >>> implementation, you are going to increase the costs of several >>> of the key computations of the BGP protocol, at least those >>> listed above. The increase will be at best linear in the number >>> of topologically distinct groups of clients. >>> >>> Another way of thinking about this is that you'll need similar >>> computational resources on your converged RR as you need on >>> distributed set of RRs. If you're replacing 10 RRs with one >>> converged one, you will need something like 10x the computes and >>> memory on that converged box. Some economy of scale may be >>> possible but remember that sometimes you get diseconomies of >>> scale too, such as the step function to upgrade to a larger and >>> more complex box. >>> >>> This doesn't mean that the proposal is infeasible. People may >>> want to implement software for, install and maintain fewer, much >>> larger, boxes. But it does mean that the costs have to be very >>> clearly understood and not hand-waved over. >>> >>> With my individual contributor hat and other clothing items on, I >>> discourage adoption of this draft until the scaling implications >>> are more clearly elucidated. I realize Section 5 touches on this >>> briefly but I think a more rigorous analysis is called for. >>> >>> --John >> > > From ilya@nobulus.com Fri Apr 8 12:46:22 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A053A6957 for ; Fri, 8 Apr 2011 12:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMosFJb06Fnm for ; Fri, 8 Apr 2011 12:46:21 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 173FD3A6975 for ; Fri, 8 Apr 2011 12:46:19 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 1F79F170C3; Fri, 8 Apr 2011 21:48:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oNicGNXKVD24; Fri, 8 Apr 2011 21:48:01 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 94A14170D5; Fri, 8 Apr 2011 21:48:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: <18DC58C5-2C04-4E12-BE18-D93E041CEE2C@juniper.net> Date: Fri, 8 Apr 2011 21:47:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> <18DC58C5-2C04-4E12-BE18-D93E041CEE2C@juniper.net> To: John Scudder , "idr@ietf.org List" X-Mailer: Apple Mail (2.1084) Cc: "raszuk@cisco.com Raszuk" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:46:22 -0000 John, Please see comments inline. On Apr 8, 2011, at 21:01 , John Scudder wrote: > - The upper bound is still O(N). Yes, indeed but only in step that breaks tie on next-hop, not before = (meaning _increase_ total complexity of best path selection is far below = linear when number of prefixes is large like in contemporary Internet). = Only dependance is not on number of clients, but on number of next-hops = (and sometimes on subset of next-hops). Once optimisation employed, = complexity remains constant regardless whether we add or remove clients. = If all policy towards all RR clients is the same, then rather than = depending on number of clients, N is actually number of next-hops. For = every prefix there will be at most N (which is still number of = next-hops) groups of RR clients with unique choice of best next hop. =20 > - AFAICT your implicit assumption is that many routes will tie-break = before the=20 > IGP step is reached. But for such routes, the behavior of a current = RR is the > same as an ORR. Thus if the ORR is interesting, that would seem to = demonstrate=20 > that the expected workload does include many routes that tie-break at = or after=20 > the IGP step. On contrary, I've described only worst-case scenario where for every = prefix selection algorithm proceeds beyond MED consideration. > - This seems to indicate that the optimizations you mention would not = often come=20 > into play for the expected workload. On networks that you've described, where ties are broken before = next-hop, there will be of course little gain but there we don't need = optimised Route Reflection at all. However the networks I had in mind = are those with dense peerings across the globe, where breaking tie on = next-hop will be reached more often than not. > - I'm primarily concerned with the costs inherent in the BGP protocol = here. I=20 > tried to be clear in my previous that I'm willing for sake of = argument to neglect > any IGP related costs. >=20 So did I, considering costs can be retrieved from sources other than = IGP. > Also, please remember that O(N) doesn't mean "is N times higher" it = means "is linearly higher". (That's what I was trying to get at by "... = *something* *like* 10x ...") >=20 Although years after finishing university most of my math skills are in = latent state, I'm aware of big-O notation. Good that we're talking about = the same things. > I don't see how you get to the conclusion that "it looks like there is = better-than-linear scaleability", unless you are talking about the = expected case under a workload that tie-breaks before the IGP step, in = which case I've already argued you don't even need an ORR. >=20 Key is in finding (once per next-hop, not per prefix) for which set of = RRc given next-hop is best, then second-best then i-th-best. This needs = to be done only once for given RR-c topology and not performed during = best path selection at all. Kind regards, iLya From danny@tcb.net Fri Apr 8 14:15:25 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5CD43A6905 for ; Fri, 8 Apr 2011 14:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.353 X-Spam-Level: X-Spam-Status: No, score=-110.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecUqIh+dYk+7 for ; Fri, 8 Apr 2011 14:15:25 -0700 (PDT) Received: from farnsworth.verisignlabs.com (farnsworth.verisignlabs.com [72.13.58.64]) by core3.amsl.com (Postfix) with ESMTP id 3BAB43A6820 for ; Fri, 8 Apr 2011 14:15:25 -0700 (PDT) Received: from monsoon.verisignlabs.com (h87.s239.verisign.com [216.168.239.87]) by farnsworth.verisignlabs.com (Postfix) with ESMTP id 6C7D5A528 for ; Fri, 8 Apr 2011 21:17:10 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (dul1dmcphers-m2.vcorp.ad.vrsn.com [10.131.210.13]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 2CAC5242168 for ; Fri, 8 Apr 2011 17:17:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Danny McPherson In-Reply-To: <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> Date: Fri, 8 Apr 2011 17:17:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <10C49F00-6CB9-4BF3-A476-D167B0879383@tcb.net> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> To: "idr@ietf.org List" X-Mailer: Apple Mail (2.1082) Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 21:15:25 -0000 On Apr 7, 2011, at 5:10 PM, John Scudder wrote: >=20 > With my individual contributor hat and other clothing items on, I = discourage adoption of this draft until the scaling implications are = more clearly elucidated. I realize Section 5 touches on this briefly = but I think a more rigorous analysis is called for. I like this idea - if we intend to apply it ubiquitously and=20 there are folks willing to do it. Some other places application=20 seems prudent: 1) System-wide sub-optimalities introduced by current route=20 reflection implementations in order to minimize local processing=20 overhead (e.g., the RR-dont-reflect-back-to-client function=20 removed in 2796). 2) All the add-path work that's happening.. 3) Securing routing work when it finally finds it's way to IDR. To date, everything IDR does is largely about introducing more state=20 and rate in the network in order to solve _real [relative] problems,=20 I'm pleasantly surprised to see you press so hard against this one=20 based on the scale premise. -danny= From jgs@juniper.net Fri Apr 8 14:33:21 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB1B3A69ED for ; Fri, 8 Apr 2011 14:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuZzIwuwlmfx for ; Fri, 8 Apr 2011 14:33:20 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id E86003A69D1 for ; Fri, 8 Apr 2011 14:33:19 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ9/h+Lcw8T+N/1OT7AWs41X+gEJ7fZI@postini.com; Fri, 08 Apr 2011 14:35:05 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 8 Apr 2011 14:31:02 -0700 From: John Scudder To: "raszuk@cisco.com" Date: Fri, 8 Apr 2011 14:32:45 -0700 Thread-Topic: [Idr] BGP Optimal Route Reflection (BGP-ORR) Thread-Index: Acv2NEIp8nn1N6V3R42jLXDzpnitHw== Message-ID: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <4D9E313A.5070000@cisco.com> <5F07C910-B796-4577-982E-87F9F091438C@juniper.net> <4D9F606E.1080205@cisco.com> In-Reply-To: <4D9F606E.1080205@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 21:33:21 -0000 On Apr 8, 2011, at 3:22 PM, Robert Raszuk wrote: > Except one point below I do agree with your comments. >=20 >> In my reading of both the draft and the conversation to date it seems >> as though there is (what may be) too much optimism about the ability >> to optimize ORR code to perform at equal scale on current hardware. >=20 > It really depends what you define as the "current hardware". >=20 > If by "current hardware" you mean currently deployed route reflectors=20 > which would get new software and they automagically be able to perform N= =20 > times more computations per sec - I think everyone on the list is clear=20 > that this is not the assumptions the draft makes. I meant "hardware currently performing RR functionality in the network". P= erhaps I should have written "equivalent hardware" or "the same hardware". = I trust you get the idea -- what you meant by the above paragraph. I'm not confident this was clear from the draft or previous discussion; I e= xpect this conversation has made it clearer. The response I have in my inb= ox from Ilya seems to indicate there is not agreement on this point, but at= minimum people must be aware it is open to question. > However if by "current hardware" you mean currently available control=20 > plane computing platforms on the market which do have much more=20 > computing power then 10s of current route reflectors for fraction of=20 > current route reflector's cost than I do not see any substantial data=20 > which would prove that such hardware can not easily meet the=20 > computational requirements of the ORR draft in question. That is not what I meant. I trust this is abundantly clear by now. --John= From ilya@nobulus.com Fri Apr 8 14:59:47 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAC493A6A17 for ; Fri, 8 Apr 2011 14:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwDSecfzZnmP for ; Fri, 8 Apr 2011 14:59:47 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 6BAF43A69D4 for ; Fri, 8 Apr 2011 14:59:46 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 323E4173D0; Sat, 9 Apr 2011 00:01:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UxH2btTahk4j; Sat, 9 Apr 2011 00:01:28 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id DB70917177; Sat, 9 Apr 2011 00:01:27 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: Date: Sat, 9 Apr 2011 00:01:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <4D9E313A.5070000@cisco.com> <5F07C910-B796-4577-982E-87F9F091438C@juniper.net> <4D9F606E.1080205@cisco.com> To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: "raszuk@cisco.com" , "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 21:59:48 -0000 On Apr 8, 2011, at 23:32 , John Scudder wrote: >> If by "current hardware" you mean currently deployed route reflectors=20= >> which would get new software and they automagically be able to = perform N=20 >> times more computations per sec - I think everyone on the list is = clear=20 >> that this is not the assumptions the draft makes. >=20 > I meant "hardware currently performing RR functionality in the = network". Perhaps I should have written "equivalent hardware" or "the = same hardware". I trust you get the idea -- what you meant by the above = paragraph. >=20 > I'm not confident this was clear from the draft or previous = discussion; I expect this conversation has made it clearer. The = response I have in my inbox from Ilya seems to indicate there is not = agreement on this point, but at minimum people must be aware it is open = to question. >=20 I have intentionally omitted hardware discussion in my previous response = to address only algorithmic part, but not to express agreement or = disagreement on skipped part. To make my position clear, I do believe = that contemporary (PC) hardware is well capable of running BGP-ORR = functions without requiring much expenses. More elaborative explanation: = if such contemporary hardware is used as a Route Reflector without = BGP-ORR functionality, then it (hardware) will be running at small = fraction of its potential. Deploying X such boxes would cost me X times = more than single box. On the other hand I could just employ unused = potential of single box to run BGP-ORR functions. =46rom this = perspective BGP-ORR does not require X times better hardware than X = boxes running legacy variant of RR. Kind regards, iLya= From raszuk@cisco.com Fri Apr 8 15:31:51 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73EC03A6A3D for ; Fri, 8 Apr 2011 15:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.251 X-Spam-Level: X-Spam-Status: No, score=-10.251 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI0l6P97hr1O for ; Fri, 8 Apr 2011 15:31:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1D5353A6A36 for ; Fri, 8 Apr 2011 15:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=5723; q=dns/txt; s=iport; t=1302302016; x=1303511616; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=D9tX9LD0EW71xsuYco3Xf6NtuhsK2HZGj+sL0nu/nrQ=; b=QLcZmNSw4GS0sS7q9q4t5tI27NFgzCPSlHWTPQCPOWDVHUaLGOxnv8fK pI/aQ02cpwYlKmKRByMNg39lsOSWfUCIuxdlpJYlCA5M5Jsptuqy7CYNw PMyAeGAXH4/7h8HsZKzUafT3AFmNaMuirqeAaU8VVIRGyBCHdB7oxq2w9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAOMn02rRDoH/2dsb2JhbACmGHeIep4IgnMOAZkAhW0EjU6Dag X-IronPort-AV: E=Sophos;i="4.63,326,1299456000"; d="scan'208";a="426669077" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 08 Apr 2011 22:33:35 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p38MXXDU023084; Fri, 8 Apr 2011 22:33:34 GMT Message-ID: <4D9F8D44.3080806@cisco.com> Date: Sat, 09 Apr 2011 00:33:40 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Scudder References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <4D9E313A.5070000@cisco.com> <5F07C910-B796-4577-982E-87F9F091438C@juniper.net> <4D9F606E.1080205@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 22:31:51 -0000 Hi John, I appreciate the fact that you are trying to make sure that people who support it do realize perhaps the need for new RR platform. But in my point of view I give people participating in the IDR enough of credit that they understand the proposal if they are commenting on it. Otherwise it is normal that they would ask questions for clarification then comment on it. But with Danny's point in mind let me stop for a moment on the scaling aspects of things. At no point in the draft there is a claim that all clients or client groups must be supported by single route reflector. Here let me allow to point out that the exact same claim has been made in the past by others that at no point in the network one would need to keep all L3VPN state. If amount of state exceeds the capacity or processing power of any single router (RR or PE) you divide it by introducing another router. So without going further on that example let me point out that if one ORR enabled RR can not serve all groups of clients in the network you divide the load and introduce another ORR enabled RR to server another group of clients. Very simple. And just like Danny I am also very happy to see you so strongly protecting against increase of BGP state and processing cycles even on few route reflectors in the network. I hope the same will happen on other proposals which call for increase of BGP state and processing power not only in few RRs but network wide. Future will likely to prove this very soon. Also you seem to stay really focused on the additional CPU and memory load of the RR. Let me reiterate what Jeff and others have already observed that this in the same time will result in decrease of state of processing of BGP churn on 100s or 1000s of given network's PEs and ASBRs without compromising the optimal exit point. Otherwise EACH such PE or ASBR would have to be equipped with exact same amount of memory and CPU what will be used by such ORR enabled RR to server single group of clients (for example sharing given POP). For me this is pure gain of the factor of number of routers in the POP. Moreover if such PEs or ASBRs are in the IGP hierarchical area they will not be able to determine the optimal exit points of BGP paths with next hops residing in other areas even assuming that such box get's all domain external paths via add-paths to it. That is functional advantage of ORR not available today in hierarchical networks (assuming no next-hop-self and no domain wide /32 leaking). Last but not least it really needs to be highlighted that if the RR is reflecting customized best path for a group of clients not all IGP events in the network will result in best path change to everyone. This again will save CPU cycles of the ASBRs and PEs as they will not need to process BGP churn which does not apply to them. > response I have in my inbox from Ilya seems to indicate there is not > agreement on this point, My reading of Ilya response clearly indicates that he was precisely responding to your questions without repeating the same statements made already on the list by others over and over. Best regards, R. PS. But I must admit one thing .. that if the strategy of repeating the same point of RR scale issue without even considering all scaling aspects network wide is targeted to burn out the co-author of an idea, where such idea has been born from the real needs of the operational community and is proposed to help efficient network operations .. you are slowly succeeding. I do hope that where IDR charter talks about work on "BGP scalability" it does not only mean to accommodate and welcome all proposals which increase BGP scale. I do hope that there is some perhaps small room for proposals which target network wide decrease of BGP state while maintaining or enhancing routing efficiency and both capex and opex costs. > On Apr 8, 2011, at 3:22 PM, Robert Raszuk wrote: >> Except one point below I do agree with your comments. >> >>> In my reading of both the draft and the conversation to date it >>> seems as though there is (what may be) too much optimism about >>> the ability to optimize ORR code to perform at equal scale on >>> current hardware. >> >> It really depends what you define as the "current hardware". >> >> If by "current hardware" you mean currently deployed route >> reflectors which would get new software and they automagically be >> able to perform N times more computations per sec - I think >> everyone on the list is clear that this is not the assumptions the >> draft makes. > > I meant "hardware currently performing RR functionality in the > network". Perhaps I should have written "equivalent hardware" or > "the same hardware". I trust you get the idea -- what you meant by > the above paragraph. > > I'm not confident this was clear from the draft or previous > discussion; I expect this conversation has made it clearer. The > response I have in my inbox from Ilya seems to indicate there is not > agreement on this point, but at minimum people must be aware it is > open to question. > >> However if by "current hardware" you mean currently available >> control plane computing platforms on the market which do have much >> more computing power then 10s of current route reflectors for >> fraction of current route reflector's cost than I do not see any >> substantial data which would prove that such hardware can not >> easily meet the computational requirements of the ORR draft in >> question. > > That is not what I meant. I trust this is abundantly clear by now. > > --John From jgs@juniper.net Fri Apr 8 17:13:07 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C933A69B1 for ; Fri, 8 Apr 2011 17:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXCWnGPuF91V for ; Fri, 8 Apr 2011 17:13:07 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 19ECC3A6905 for ; Fri, 8 Apr 2011 17:13:06 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ+k+/LUY2Vn8o/B3V3qRNmC8CG1mSIy@postini.com; Fri, 08 Apr 2011 17:14:53 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 8 Apr 2011 17:11:18 -0700 From: John Scudder To: "idr@ietf.org List" Date: Fri, 8 Apr 2011 17:13:03 -0700 Thread-Topic: [Idr] BGP Optimal Route Reflection (BGP-ORR) Thread-Index: Acv2SqXLFVsWChSxR2mxFl1c9zdtig== Message-ID: <996E14D1-CA60-48F1-BBDF-D134BDBC76A3@juniper.net> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> In-Reply-To: <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 00:13:07 -0000 Folks, This thread has diverged in some interesting and even surprising ways. I d= on't intend to follow up further over the weekend but I did want to close o= n my original point: On Apr 7, 2011, at 5:10 PM, John Scudder wrote: > With my individual contributor hat and other clothing items on, I discour= age adoption of this draft until the scaling implications are more clearly = elucidated. I realize Section 5 touches on this briefly but I think a more= rigorous analysis is called for. As far as I'm concerned the extensive conversation over the last couple of = days on this topic has shed sufficient light, and I withdraw my objection. --John= From jsw@inconcepts.biz Sat Apr 9 09:16:38 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D8C3A6876 for ; Sat, 9 Apr 2011 09:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncCMR7eUIBBa for ; Sat, 9 Apr 2011 09:16:37 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B69003A69D3 for ; Sat, 9 Apr 2011 09:16:37 -0700 (PDT) Received: by vws12 with SMTP id 12so4130021vws.31 for ; Sat, 09 Apr 2011 09:18:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.4 with SMTP id cu4mr1023759vcb.58.1302365903402; Sat, 09 Apr 2011 09:18:23 -0700 (PDT) Received: by 10.220.182.132 with HTTP; Sat, 9 Apr 2011 09:18:23 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <4D9F8D44.3080806@cisco.com> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <4D9E313A.5070000@cisco.com> <5F07C910-B796-4577-982E-87F9F091438C@juniper.net> <4D9F606E.1080205@cisco.com> <4D9F8D44.3080806@cisco.com> Date: Sat, 9 Apr 2011 12:18:23 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 16:16:38 -0000 On Fri, Apr 8, 2011 at 6:33 PM, Robert Raszuk wrote: > I do hope that where IDR charter talks about work on "BGP scalability" it > does not only mean to accommodate and welcome all proposals which increas= e > BGP scale. I do hope that there is some perhaps small room for proposals > which target network wide decrease of BGP state while maintaining or > enhancing routing efficiency and both capex and opex costs. It should be on our minds that "BGP scalability" means different things to different operators. It is not always a simple matter of the most routes in the least convergence time on the control planes available in the routers. The very concept of route-reflection is designed to allow for shifting work from one node to another as well as reducing total work. Some networks have a greater need to shift work onto nodes where CPU and RAM is plentiful than they do to simply reduce the total amount of work to be done. In the last decade or so, we have seen a remarkable shift from big iron servers and vertically-scaled systems to distributed server farms and horizontally-scaled applications. Networks with large VPN customer-bases have also realized this is possible and indeed necessary as the needs of VPN customers exceed various resource limits (FIB/CPU/RAM) of available routing platforms. We should all recognize that there is more than one way to scale the networ= k. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jakob.heitz@ericsson.com Sun Apr 10 11:15:27 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCF63A698B for ; Sun, 10 Apr 2011 11:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+Lw-edDLjpS for ; Sun, 10 Apr 2011 11:15:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id C7FCF3A6961 for ; Sun, 10 Apr 2011 11:15:26 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3AIFP91027708 for ; Sun, 10 Apr 2011 13:15:26 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 10 Apr 2011 14:15:19 -0400 From: Jakob Heitz To: idr Date: Sun, 10 Apr 2011 14:15:21 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv3qz/eUDbSzbutSO28KB97ZhUmfw== Message-ID: References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> In-Reply-To: <20110324164219.GI11857@diehard.n-r-g.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 18:15:27 -0000 The length field follows the marker. If the first byte of the length field = can be 0xff, it reduces the value of the marker. The value of the marker is= to validate the beginning of a message. This is good both in protocol oper= ation as well as for debugging. To preserve the value of the marker, I propose the maximum message length t= o be 65279 (0xfeff). -- Jakob Heitz.= From raszuk@cisco.com Sun Apr 10 11:23:14 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7513A6961 for ; Sun, 10 Apr 2011 11:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlkbOP3aa5RA for ; Sun, 10 Apr 2011 11:23:13 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 814D43A698B for ; Sun, 10 Apr 2011 11:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=972; q=dns/txt; s=iport; t=1302459793; x=1303669393; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=be15UGAjEgxRYzfDHEiNTWFXQJFd3ty90ai2f8h/Vvg=; b=dxJ+HrrhPmbPYO0IpsPfE8uVVleANsvvmemxop05uiHI/jXU6HZh7Jv7 kscMla180pKDGAJg7lfgy+byhGN0OZ39X2MjMZQ8Vnb6rgRPEbrviDoy0 yTiKaSrfPTfheHVMB6QMSMXZOfOgG/MWfmr59XitI9c+IXptdIhWYE5Ku 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGv0oU2rRDoJ/2dsb2JhbACmHXeIepsHgnMOAZd5hW4EjViDag X-IronPort-AV: E=Sophos;i="4.63,334,1299456000"; d="scan'208";a="334214722" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 10 Apr 2011 18:23:13 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3AINCbG004590; Sun, 10 Apr 2011 18:23:12 GMT Message-ID: <4DA1F590.9080804@cisco.com> Date: Sun, 10 Apr 2011 20:23:12 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jakob Heitz References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 18:23:14 -0000 Hi Jakob, Per RFC4271 length field indicates the total length of the message including the header which consists of the marker, length field itself as well as message type octet. Length: This 2-octet unsigned integer indicates the total length of the message, including the header in octets. Conclusion: Length includes the fixed marker field hence it will not reduce it's size. Many thx, R. > The length field follows the marker. If the first byte of the length > field can be 0xff, it reduces the value of the marker. The value of > the marker is to validate the beginning of a message. This is good > both in protocol operation as well as for debugging. > > To preserve the value of the marker, I propose the maximum message > length to be 65279 (0xfeff). > > -- Jakob Heitz. _______________________________________________ Idr > mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > From jakob.heitz@ericsson.com Sun Apr 10 11:50:23 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572DD3A68EC for ; Sun, 10 Apr 2011 11:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoDJ3Xl9zyod for ; Sun, 10 Apr 2011 11:50:21 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id B20B63A6876 for ; Sun, 10 Apr 2011 11:50:21 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3AIoI9f013251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Apr 2011 13:50:18 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 10 Apr 2011 14:50:17 -0400 From: Jakob Heitz To: "raszuk@cisco.com" Date: Sun, 10 Apr 2011 14:50:21 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv3sCKfWxR91pckQc+SQf7rXPaFIQ== Message-ID: <0568C291-6236-4E65-863E-EB355B5E2D1B@ericsson.com> References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> In-Reply-To: <4DA1F590.9080804@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 18:50:23 -0000 Yeah, I know. Thats not what I meant. You've never debugged a TCP stream before, have you? -- Jakob Heitz. On Apr 10, 2011, at 11:23 AM, "Robert Raszuk" wrote: > Hi Jakob, >=20 > Per RFC4271 length field indicates the total length of the message=20 > including the header which consists of the marker, length field itself=20 > as well as message type octet. >=20 > Length: >=20 > This 2-octet unsigned integer indicates the total length of the > message, including the header in octets. >=20 > Conclusion: >=20 > Length includes the fixed marker field hence it will not reduce it's size= . >=20 > Many thx, > R. >=20 >=20 >=20 >> The length field follows the marker. If the first byte of the length >> field can be 0xff, it reduces the value of the marker. The value of >> the marker is to validate the beginning of a message. This is good >> both in protocol operation as well as for debugging. >>=20 >> To preserve the value of the marker, I propose the maximum message >> length to be 65279 (0xfeff). >>=20 >> -- Jakob Heitz. _______________________________________________ Idr >> mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >>=20 >=20 From jsw@inconcepts.biz Sun Apr 10 11:50:44 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0313A69AD for ; Sun, 10 Apr 2011 11:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.763 X-Spam-Level: X-Spam-Status: No, score=-2.763 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noJbUOKnB12O for ; Sun, 10 Apr 2011 11:50:44 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E99C43A6961 for ; Sun, 10 Apr 2011 11:50:43 -0700 (PDT) Received: by vws12 with SMTP id 12so4619152vws.31 for ; Sun, 10 Apr 2011 11:50:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.69 with SMTP id dt5mr1302602vcb.93.1302461443428; Sun, 10 Apr 2011 11:50:43 -0700 (PDT) Received: by 10.220.182.132 with HTTP; Sun, 10 Apr 2011 11:50:43 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <4DA1F590.9080804@cisco.com> References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> Date: Sun, 10 Apr 2011 14:50:43 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 18:50:45 -0000 >> To preserve the value of the marker, I propose the maximum message >> length to be 65279 (0xfeff). > Length includes the fixed marker field hence it will not reduce it's size= . Where Jakob writes "value" I am certain he means "usefulness" for debugging, as if the marker is a magic string that could be used to easily split up messages in a debug dump. He doesn't mean there is some upper bound on the length of the message caused by the marker field. The marker's intent was actually confused, as you can determine somewhat easily by skimming the references to marker in the relevant RFCs. It could be a magic 16-bit field for detecting "loss of sync" (RFC saying this, not me) or it could be for BGP's own authentication mechanism (again, the specs talking.) In reality, I think it's pretty much useless as there aren't implementations taking advantage of it for authentication, and messages are not encoded in such a way that the value 0xFFFF cannot be present in a message. Since marker actually cannot be used reliably to find message boundaries for operation or debugging, I disagree with Jakob's reasoning. The maximum message length is arbitrary within the bounds of a 16 bit field. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From raszuk@cisco.com Sun Apr 10 11:59:36 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9BE13A6961 for ; Sun, 10 Apr 2011 11:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.547 X-Spam-Level: X-Spam-Status: No, score=-10.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2Mw4YAvgoa1 for ; Sun, 10 Apr 2011 11:59:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9B07C3A6876 for ; Sun, 10 Apr 2011 11:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1627; q=dns/txt; s=iport; t=1302461975; x=1303671575; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Enmtcv9J5wy289YzjLamEzFHsEU5FVXsjgkCgcqoL60=; b=Nahl1j/RJV+knk15UtuOMWJxd5660/jHXvL9a1d6Fz1cah1IUZpSMpYU OKnojXTm7k4fhos7HXNkID4ErHO77AVLaEhqM0QpeZlTNSpTlsdKpJjIh eJzYhGkVySdssMPAUPkmnqYT1KXkzYQ213eipBaYA9FoU/kO2wTVu0MHn 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPv8oU2rRDoH/2dsb2JhbACmHXeIepsugnMOAZd4hW4EjViDag X-IronPort-AV: E=Sophos;i="4.63,334,1299456000"; d="scan'208";a="427107057" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 10 Apr 2011 18:59:35 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3AIxXg1028545; Sun, 10 Apr 2011 18:59:34 GMT Message-ID: <4DA1FE17.3060706@cisco.com> Date: Sun, 10 Apr 2011 20:59:35 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jakob Heitz References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <0568C291-6236-4E65-863E-EB355B5E2D1B@ericsson.com> In-Reply-To: <0568C291-6236-4E65-863E-EB355B5E2D1B@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 18:59:36 -0000 > You've never debugged a TCP stream before, have you? Indeed. I am not that fast. I always capture it first then debug the captured file. Finding marker demarkations is quite easy even if first octet length field is 0xFF. You just match on 16 octets of all 1s. I really see no problem even if the 17th octet will also be all 1s. Cheers. R. > Yeah, I know. Thats not what I meant. > > You've never debugged a TCP stream before, have you? > > -- > Jakob Heitz. > > > On Apr 10, 2011, at 11:23 AM, "Robert Raszuk" wrote: > >> Hi Jakob, >> >> Per RFC4271 length field indicates the total length of the message >> including the header which consists of the marker, length field itself >> as well as message type octet. >> >> Length: >> >> This 2-octet unsigned integer indicates the total length of the >> message, including the header in octets. >> >> Conclusion: >> >> Length includes the fixed marker field hence it will not reduce it's size. >> >> Many thx, >> R. >> >> >> >>> The length field follows the marker. If the first byte of the length >>> field can be 0xff, it reduces the value of the marker. The value of >>> the marker is to validate the beginning of a message. This is good >>> both in protocol operation as well as for debugging. >>> >>> To preserve the value of the marker, I propose the maximum message >>> length to be 65279 (0xfeff). >>> >>> -- Jakob Heitz. _______________________________________________ Idr >>> mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >>> >> > From jakob.heitz@ericsson.com Sun Apr 10 12:00:08 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DE73A69CC for ; Sun, 10 Apr 2011 12:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiVRdAGbDgAs for ; Sun, 10 Apr 2011 12:00:06 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 492993A69C6 for ; Sun, 10 Apr 2011 12:00:04 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3AJ03rl028308; Sun, 10 Apr 2011 14:00:04 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 10 Apr 2011 14:59:57 -0400 From: Jakob Heitz To: Jeff Wheeler Date: Sun, 10 Apr 2011 15:00:01 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv3sXxs8q5PTSKzSOSLcMa48CQzIg== Message-ID: <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 19:00:08 -0000 I don't use the marker to sync the TCP stream. I use the length field. I do= use the marker to verify. -- Jakob Heitz. On Apr 10, 2011, at 11:50 AM, "Jeff Wheeler" wrote: >>> To preserve the value of the marker, I propose the maximum message >>> length to be 65279 (0xfeff). >> Length includes the fixed marker field hence it will not reduce it's siz= e. >=20 > Where Jakob writes "value" I am certain he means "usefulness" for > debugging, as if the marker is a magic string that could be used to > easily split up messages in a debug dump. He doesn't mean there is > some upper bound on the length of the message caused by the marker > field. >=20 > The marker's intent was actually confused, as you can determine > somewhat easily by skimming the references to marker in the relevant > RFCs. It could be a magic 16-bit field for detecting "loss of sync" > (RFC saying this, not me) or it could be for BGP's own authentication > mechanism (again, the specs talking.) In reality, I think it's pretty > much useless as there aren't implementations taking advantage of it > for authentication, and messages are not encoded in such a way that > the value 0xFFFF cannot be present in a message. >=20 > Since marker actually cannot be used reliably to find message > boundaries for operation or debugging, I disagree with Jakob's > reasoning. The maximum message length is arbitrary within the bounds > of a 16 bit field. >=20 > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ilya@nobulus.com Sun Apr 10 12:31:13 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358853A6954 for ; Sun, 10 Apr 2011 12:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CtJmmdFWPeF for ; Sun, 10 Apr 2011 12:30:40 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 04D9C3A6961 for ; Sun, 10 Apr 2011 12:30:39 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 3AD6D17177; Sun, 10 Apr 2011 21:30:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DLrEM88hfWsO; Sun, 10 Apr 2011 21:30:36 +0200 (CEST) Received: from c3b41986.dsl.de.easynet.net (C3B41986.dsl.de.easynet.net [195.180.25.134]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 410541711F; Sun, 10 Apr 2011 21:30:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> Date: Sun, 10 Apr 2011 21:30:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> To: Jakob Heitz X-Mailer: Apple Mail (2.1084) Cc: IETF IDR Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 19:31:13 -0000 On Apr 10, 2011, at 21:00 , Jakob Heitz wrote: > I don't use the marker to sync the TCP stream. I use the length field. = I do use the marker to verify. >=20 are you talking about situation where layer(s) above TCP lost message = boundary and you're trying to find it again using length and marker? /iLya From jakob.heitz@ericsson.com Sun Apr 10 12:47:17 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09C353A695D for ; Sun, 10 Apr 2011 12:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eigLoA-4u1MO for ; Sun, 10 Apr 2011 12:47:16 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 58D3A3A6955 for ; Sun, 10 Apr 2011 12:47:16 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3AJlEgG029032; Sun, 10 Apr 2011 14:47:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 10 Apr 2011 15:47:09 -0400 From: Jakob Heitz To: Ilya Varlashkin Date: Sun, 10 Apr 2011 15:47:12 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv3uBO0JGFRFuzwRtij+AJ8f19ROQ== Message-ID: <9B4F8301-FA0A-4A78-81DA-2E31A4419F82@ericsson.com> References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IDR Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 19:47:17 -0000 Yes, like that. I use the length field to find the message boundary and use= the marker to verify it. Verifying things helps to avoid bugs. -- Jakob Heitz. On Apr 10, 2011, at 12:30 PM, "Ilya Varlashkin" wrote: > On Apr 10, 2011, at 21:00 , Jakob Heitz wrote: >=20 >> I don't use the marker to sync the TCP stream. I use the length field. I= do use the marker to verify. >>=20 >=20 > are you talking about situation where layer(s) above TCP lost message bou= ndary and you're trying to find it again using length and marker? >=20 > /iLya >=20 From jsw@inconcepts.biz Sun Apr 10 13:01:54 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9939E3A6959 for ; Sun, 10 Apr 2011 13:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBsg2464rgJw for ; Sun, 10 Apr 2011 13:01:53 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id D1F093A6955 for ; Sun, 10 Apr 2011 13:01:52 -0700 (PDT) Received: by vws12 with SMTP id 12so4642949vws.31 for ; Sun, 10 Apr 2011 13:01:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.125.9 with SMTP id w9mr1241837vcr.198.1302465712039; Sun, 10 Apr 2011 13:01:52 -0700 (PDT) Received: by 10.220.182.132 with HTTP; Sun, 10 Apr 2011 13:01:51 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> Date: Sun, 10 Apr 2011 16:01:51 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 20:01:54 -0000 On Sun, Apr 10, 2011 at 3:00 PM, Jakob Heitz wro= te: > I don't use the marker to sync the TCP stream. I use the length field. I = do use the marker to verify. I understand what you meant in your earlier post. The debugging method you describe is unreliable since the message encoding does not ensure that the same bit-string would not be present within a message. Consider a message length mis-calculation that lands the message parser at the start of an inner-message sent by the neighbor as a debugging mechanism, or which lands you within a prefix, router ID, community, or other field which can have arbitrary value. Even a 16-bit CRC field in place of the marker would be superior (yet still not totally "reliable") for the debugging method you describe, but that isn't what we have. Changing the message bit encoding would allow for your method to become reliable by protecting the magic from collision within the message data, but I doubt if anyone would think that to be reasonable in terms of cost/benefit. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jakob.heitz@ericsson.com Sun Apr 10 14:56:56 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A763A69DD for ; Sun, 10 Apr 2011 14:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjirgFM8bvet for ; Sun, 10 Apr 2011 14:56:51 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 890CC3A69CC for ; Sun, 10 Apr 2011 14:56:50 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3ALunXi031179; Sun, 10 Apr 2011 16:56:50 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 10 Apr 2011 17:56:43 -0400 From: Jakob Heitz To: Jeff Wheeler Date: Sun, 10 Apr 2011 17:56:37 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv3yi0/wTyCpew8TNaVw0eFeN+qHg== Message-ID: References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 21:56:56 -0000 Please understand the word "verify" -- Jakob Heitz. 510-566-2901 On Apr 10, 2011, at 1:02 PM, "Jeff Wheeler" wrote: > On Sun, Apr 10, 2011 at 3:00 PM, Jakob Heitz w= rote: >> I don't use the marker to sync the TCP stream. I use the length field. I= do use the marker to verify. >=20 > I understand what you meant in your earlier post. The debugging > method you describe is unreliable since the message encoding does not > ensure that the same bit-string would not be present within a message. > Consider a message length mis-calculation that lands the message > parser at the start of an inner-message sent by the neighbor as a > debugging mechanism, or which lands you within a prefix, router ID, > community, or other field which can have arbitrary value. >=20 > Even a 16-bit CRC field in place of the marker would be superior (yet > still not totally "reliable") for the debugging method you describe, > but that isn't what we have. Changing the message bit encoding would > allow for your method to become reliable by protecting the magic from > collision within the message data, but I doubt if anyone would think > that to be reasonable in terms of cost/benefit. >=20 > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jsw@inconcepts.biz Sun Apr 10 17:06:19 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C40E3A6A07 for ; Sun, 10 Apr 2011 17:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-0P6rKHHaFD for ; Sun, 10 Apr 2011 17:06:18 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 6249F3A69B9 for ; Sun, 10 Apr 2011 17:06:18 -0700 (PDT) Received: by iye19 with SMTP id 19so6352877iye.31 for ; Sun, 10 Apr 2011 17:06:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.181.137 with SMTP id by9mr4780756ibb.60.1302480377924; Sun, 10 Apr 2011 17:06:17 -0700 (PDT) Received: by 10.231.252.86 with HTTP; Sun, 10 Apr 2011 17:06:17 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> Date: Sun, 10 Apr 2011 20:06:17 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 00:06:19 -0000 On Sun, Apr 10, 2011 at 5:56 PM, Jakob Heitz wro= te: > Please understand the word "verify" Your method doesn't "verify" that the parser is beginning at start of a message. It can only detect some error conditions, and in others, it will produce a false positive. If you go back and consider your own idea to encapsulate whole BGP messages within outer-messages for remote-neighbor diagnostic purposes, you should immediately understand why this is the case -- even if you have not yet considered the possibility of an erroneous message length causing the parser to start at an unlucky offset within an unlucky message payload. What you are asking for is the length field not be allowed to be the same two-octet value as the marker, assuming the marker is a constant, for detecting "message length off by +1 or +2" errors. There are certainly other "off by N" cases where this will produce false positives, depending on the message payload. It is not guaranteed to detect "off by -1 or -2" either. It should be understood that this would only aid in diagnosing a limited set of error circumstances. It's really giving you a little bit more context for "guessing," not "verification," as it can and sometimes will produce the wrong result. IMO your suggestion is not without merit, but it works sometimes, not all the time. There is no way to reliably recover "stream sync" in the BGP protocol, if the sender is sending incorrect message lengths or truncated message payload. To say "verify" in the context of ensuring you are parsing from the start of a message implies this, and that is simply not correct, even diagnostically. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jakob.heitz@ericsson.com Sun Apr 10 19:23:07 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66B83A6A46 for ; Sun, 10 Apr 2011 19:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H8kop92W9Qv for ; Sun, 10 Apr 2011 19:23:06 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 9F4DD3A6A30 for ; Sun, 10 Apr 2011 19:23:06 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3B2N5Jk004830; Sun, 10 Apr 2011 21:23:06 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 10 Apr 2011 22:23:00 -0400 From: Jakob Heitz To: Jeff Wheeler , "idr@ietf.org" Date: Sun, 10 Apr 2011 22:22:59 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv33E1poFXxkfytSPaAvf9GDT/9hAAEioNA Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F81C4C4@EUSAACMS0701.eamcs.ericsson.se> References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 02:23:07 -0000 Verify: If verification fails, you know it's bad. If it passes, you have a better chance it's good. Not 100%. This has value. It helps to make code robust. It's like, you provide a photo ID when you pay with a credit card. If the photo isn't you, you fail. If the photo resembles you, you might still have forged it or disguised yourself. Photo IDs are used anyway. -- Jakob Heitz. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Jeff Wheeler > Sent: Sunday, April 10, 2011 5:06 PM > To: idr@ietf.org > Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 >=20 > On Sun, Apr 10, 2011 at 5:56 PM, Jakob Heitz=20 > wrote: > > Please understand the word "verify" >=20 > Your method doesn't "verify" that the parser is beginning at start of > a message. It can only detect some error conditions, and in others, > it will produce a false positive. If you go back and consider your > own idea to encapsulate whole BGP messages within outer-messages for > remote-neighbor diagnostic purposes, you should immediately understand > why this is the case -- even if you have not yet considered the > possibility of an erroneous message length causing the parser to start > at an unlucky offset within an unlucky message payload. >=20 > What you are asking for is the length field not be allowed to be the > same two-octet value as the marker, assuming the marker is a constant, > for detecting "message length off by +1 or +2" errors. There are > certainly other "off by N" cases where this will produce false > positives, depending on the message payload. It is not guaranteed to > detect "off by -1 or -2" either. >=20 > It should be understood that this would only aid in diagnosing a > limited set of error circumstances. It's really giving you a little > bit more context for "guessing," not "verification," as it can and > sometimes will produce the wrong result. IMO your suggestion is not > without merit, but it works sometimes, not all the time. >=20 > There is no way to reliably recover "stream sync" in the BGP protocol, > if the sender is sending incorrect message lengths or truncated > message payload. To say "verify" in the context of ensuring you are > parsing from the start of a message implies this, and that is simply > not correct, even diagnostically. >=20 > --=20 > Jeff S Wheeler > Sr Network Operator=A0 /=A0 Innovative Network Concepts > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From paul@jakma.org Mon Apr 11 05:40:56 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E6828C0F9 for ; Mon, 11 Apr 2011 05:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7pslmx5dB4c for ; Mon, 11 Apr 2011 05:40:55 -0700 (PDT) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by core3.amsl.com (Postfix) with ESMTP id B7E2628C0F6 for ; Mon, 11 Apr 2011 05:40:54 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk [130.209.244.4]) (authenticated bits=0) by hibernia.jakma.org (8.14.4/8.14.3) with ESMTP id p3BCeJaI001409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Apr 2011 13:40:23 +0100 Date: Mon, 11 Apr 2011 13:40:14 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: John Scudder In-Reply-To: <18DC58C5-2C04-4E12-BE18-D93E041CEE2C@juniper.net> Message-ID: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> <18DC58C5-2C04-4E12-BE18-D93E041CEE2C@juniper.net> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "raszuk@cisco.com" , "idr@ietf.org List" Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Paul Jakma , Inter-Domain Routing List List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 12:40:56 -0000 On Fri, 8 Apr 2011, John Scudder wrote: > After giving your message some thought it seems to me that you are > pointing out that there is scope for optimization such that the > expected cost under some workloads will be less than O(N) in the > number of topologically distinct groups. Granted, but please note > several things: > - The upper bound is still O(N). > In closing let me repeat my remark to Robert: My concern is that > those who are supporting the proposal's adoption should understand > that we are talking about replacing N smaller boxes with one box > containing O(N) times the compute resources. No free lunch. It may be worse than that. You have N boxes, each doing O(N) route-selection work. So in total that's O(N^2) worth machines, which this proposal (IIUC) intends to centralise somewhat. There already have been RR systems deployed at large IXes which do client-perspective route selection, and the O(N^2) scaling is a big problem for them, both for memory and CPU. So, not to say there isn't value in this, but just don't expect to get much out of it in terms of the client:RR ratio. regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: "To vacillate or not to vacillate, that is the question ... or is it?" From ilya@nobulus.com Mon Apr 11 06:32:26 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EA83A6B15 for ; Mon, 11 Apr 2011 06:32: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=-2.599, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh7oyu4dNDkx for ; Mon, 11 Apr 2011 06:32:26 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 641C43A6A18 for ; Mon, 11 Apr 2011 06:32:25 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id F085A170CD; Mon, 11 Apr 2011 15:32:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g4xXHQjLr3Sv; Mon, 11 Apr 2011 15:32:22 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:e415:2480:7ac8:75c7]) by nobulus.com (Postfix) with ESMTPA id 65D2017121; Mon, 11 Apr 2011 15:32:20 +0200 (CEST) Message-ID: <70B86CF264BD43979010BFF95B34A350@hnivarlas1> From: "iLya" To: "Paul Jakma" , References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> <18DC58C5-2C04-4E12-BE18-D93E041CEE2C@juniper.net> In-Reply-To: Date: Mon, 11 Apr 2011 15:32:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: raszuk@cisco.com Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 13:32:26 -0000 -------------------------------------------------- From: "Paul Jakma" Sent: Monday, April 11, 2011 2:40 PM To: "John Scudder" Cc: "Ilya Varlashkin" ; ; Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) >> In closing let me repeat my remark to Robert: My concern is that those >> who are supporting the proposal's adoption should understand that we are >> talking about replacing N smaller boxes with one box containing O(N) >> times the compute resources. No free lunch. > > It may be worse than that. You have N boxes, each doing O(N) > route-selection work. So in total that's O(N^2) worth machines, which this > proposal (IIUC) intends to centralise somewhat. There already have been RR > systems deployed at large IXes which do client-perspective route > selection, and the O(N^2) scaling is a big problem for them, both for > memory and CPU. > ok, if N in this thread is used as number of clients, let me call total number of possible next-hops as K. If an UPDATE contains all K next-hops, then every client is guaranteed to have one of them as best so we need only K iterations (not N). If an UPDATE contains only (K-M) next-hops, then it's guaranteed that each of them will be no worse than (M+1)-best for any client. With graph of next-hop preferences we can find group of clients "interested in given next-hop under given circumstances" in only few iterations so we can both select best-hop for each and prepare UPDATE message regardless of number of clients. Of course you still need to iterate through all sockets to send messages out (either user-land, or kernel-land), but you'd do so in current RR just the same. It's fair to mention that if number of clients is small, then falling back on iteration through clients rather than next-hops may be more efficient (I say may because I haven't yet evaluated optimisation possibilities on that side). But if you have only handful of exits from an area with 100 clients, then next-hop-based optimisation makes BGP-ORR work not that difficuly. > So, not to say there isn't value in this, but just don't expect to get > much out of it in terms of the client:RR ratio. > In fact quite opposite - more clients, more gain. Also, let's not forget that with BGP-ORR we efectively scale control-plane and forwarding-plane independently. I can buy high-throughput box with prehistoric computational capabilities and a number-cruncher both for reasonable money, without BGP-ORR I need to get high-throughput-number-cruncher at much higher cost. Kind regards, iLya From paul@jakma.org Mon Apr 11 07:53:17 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC69C3A6A4A for ; Mon, 11 Apr 2011 07:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENlRBTNjD60z for ; Mon, 11 Apr 2011 07:53:17 -0700 (PDT) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by core3.amsl.com (Postfix) with ESMTP id 932273A69FF for ; Mon, 11 Apr 2011 07:53:16 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk [130.209.244.4]) (authenticated bits=0) by hibernia.jakma.org (8.14.4/8.14.3) with ESMTP id p3BEqi0P003114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Apr 2011 15:52:48 +0100 Date: Mon, 11 Apr 2011 15:52:43 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: iLya In-Reply-To: <70B86CF264BD43979010BFF95B34A350@hnivarlas1> Message-ID: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> <18DC58C5-2C04-4E12-BE18-D93E041CEE2C@juniper.net> <70B86CF264BD43979010BFF95B34A350@hnivarlas1> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Robert Raszuk , Inter-Domain Routing List Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Paul Jakma , Inter-Domain Routing List List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 14:53:17 -0000 On Mon, 11 Apr 2011, iLya wrote: > ok, if N in this thread is used as number of clients, let me call > total number of possible next-hops as K. If an UPDATE contains all > K next-hops, then every client is guaranteed to have one of them as > best so we need only K iterations (not N). Ah, ok. Though, note that K is independent of N - it may even be the same as or much greater than it. > If an UPDATE contains only (K-M) next-hops, then it's guaranteed > that each of them will be no worse than (M+1)-best for any client. > With graph of next-hop preferences we can find group of clients > "interested in given next-hop under given circumstances" in only > few iterations so we can both select best-hop for each and prepare > UPDATE message regardless of number of clients. You're still doing that work for each of the N clients, in order to know their preference to each of the K nexthops - even if it's looking up their preference in a pre-existing graph. So that's O(NK), which is O(X^2), for some value of X >= both N and K (this is assuming the route selection process is linear). If N and K are similar in magnitude then NK is fairly closely bounded by X^2 obviously. Now, at least one of the proposals in the draft is to compute the shortest path for each client (i.e. construct the graph of next-hop preferences which you mention), in which case the per-client route-selection work will be /higher/ than linear. All-pairs shortest path is O(V^3), where V >= K+N. If K+N << V it might be better to run Dijkstra N times, which is O(N*(E+VlogV). If V is of similar magnitude to N+K, then O(VE+V^2logV) is a tight-ish upper-bound, which is in between V^2 and V^3. So you're looking at Omega(X^2), O(X^3) complexity potentially. You can of course cache the SPF results, trading compute time for RAM, for as long as the underlying network remains stable. You /may/ be able to group some clients together - but that's not going to make much impact on how NK-pairs shortest-path scales, unless you restrict the scope to fairly trivial topologies. Note that grouping clients may itself scale worse than O(N). The IXes I know of aren't trying to do per-client SPF. However they're doing eBGP-per-client-selection and every client is different so there's little to no homogeneity of selection that can be exploited & and over which to amortise the costs, as there might be in the iBGP case, as you point out. Exactly how much scope there is in practice for such optimisation, I don't know. Optimal RR could scale better or perhaps worse than the IX cases I know about. > forget that with BGP-ORR we efectively scale control-plane and > forwarding-plane independently. I can buy high-throughput box with > prehistoric computational capabilities and a number-cruncher both > for reasonable money, without BGP-ORR I need to get > high-throughput-number-cruncher at much higher cost. That'd be nice, yes. I don't disagree that this draft could be helpful, even if scaling limits the achievable client:RR ratio. I just wanted to caution against having too high expectations of that ratio. regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: This wasn't just plain terrible, this was fancy terrible. This was terrible with raisins in it. -- Dorothy Parker From ilya@nobulus.com Mon Apr 11 08:56:46 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5522A3A6B26 for ; Mon, 11 Apr 2011 08:56:46 -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=-2.599, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amRBvKZ5+OZL for ; Mon, 11 Apr 2011 08:56:45 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id C44C23A6A72 for ; Mon, 11 Apr 2011 08:56:44 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 67646170F9; Mon, 11 Apr 2011 17:56:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FlXtii1cUZhX; Mon, 11 Apr 2011 17:56:40 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:e415:2480:7ac8:75c7]) by nobulus.com (Postfix) with ESMTPA id 93EEB170CD; Mon, 11 Apr 2011 17:56:38 +0200 (CEST) Message-ID: From: "iLya" To: "Paul Jakma" , "Inter-Domain Routing List" References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> <18DC58C5-2C04-4E12-BE18-D93E041CEE2C@juniper.net> <70B86CF264BD43979010BFF95B34A350@hnivarlas1> In-Reply-To: Date: Mon, 11 Apr 2011 17:56:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: Robert Raszuk Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 15:56:46 -0000 -------------------------------------------------- >> If an UPDATE contains only (K-M) next-hops, then it's guaranteed that >> each of them will be no worse than (M+1)-best for any client. With graph >> of next-hop preferences we can find group of clients "interested in given >> next-hop under given circumstances" in only few iterations so we can both >> select best-hop for each and prepare UPDATE message regardless of number >> of clients. > > You're still doing that work for each of the N clients, in order to know > their preference to each of the K nexthops - even if it's You do this only once, not for every UPDATE message. As long as number of clients is far less than number of routes being exchanged, that's negligible work. > looking up their preference in a pre-existing graph. So that's O(NK), > which is O(X^2), for some value of X >= both N and K (this is assuming the > route selection process is linear). If N and K are similar in magnitude > then NK is fairly closely bounded by X^2 obviously. > In practice N=K case would happen only when every client is also potential exit point, like in flat networks. There are further optimisations possible depending on nature of that "flatness". E.g. in Opt-C you could leverage the fact that most of "final next-hops" will be reachable via relatively small subset of ABR/ASBR, effectively reducing K significantly. In simple IPv4 net you can also separate customer routes and external routes and apply different style of optimisation. > Now, at least one of the proposals in the draft is to compute the shortest > path for each client (i.e. construct the graph of next-hop preferences > which you mention), in which case the per-client route-selection work will > be /higher/ than linear. All-pairs shortest path is O(V^3), where V >= > K+N. If K+N << V it might be better to run Dijkstra N times, which is > O(N*(E+VlogV). If V is of similar magnitude to N+K, then O(VE+V^2logV) is > a tight-ish upper-bound, which is in between V^2 and V^3. > Strictly speaking we don't really need to know all-pairs SPF, only from any client to any exit point (so no K+N here). And as above network topology knowledge may aid optimisation - if path to all exits lies through small set of hub points (e.g. P-routers), then preference calculations can be split in two (from client to hub and from hub to exit), which may significantly reduce amount of calculations that needs to be done. > So you're looking at Omega(X^2), O(X^3) complexity potentially. > Only in maxed-out densely interconnected network, which is hardly description of majority real-world networks. > You can of course cache the SPF results, trading compute time for RAM, for > as long as the underlying network remains stable. You /may/ be able to > group some clients together - but that's not going to make much impact on > how NK-pairs shortest-path scales, unless you restrict the scope to fairly > trivial topologies. Note that grouping clients may itself scale worse than > O(N). > If we're talking about update-groups dictated by different outgoing policies (with serialisation optimisation in mind), then you could pass prefixes through policies either before considering next-hops or in parallel and merge the results, so again you're not dependant on number of clients. You will no longer have static (config-time) update-groups but you get dynamic group as a side effect of best-path + policy calculations. The only thing that changes with ORR is that where you had G1 static update-groups before, you will have somewhere between G1 and K*G1 update groups (actually, number of next-hops preferred by all clients for given prefix) with ORR. > The IXes I know of aren't trying to do per-client SPF. However they're > doing eBGP-per-client-selection and every client is different so there's > little to no homogeneity of selection that can be exploited & and over > which to amortise the costs, as there might be in the iBGP case, as you > point out. > I'm not sure comparisson with IXes is fair here because at IXes you usually don't compare cost to next-hop. If you do (e.g. geographically distributed IX architecture and you want to take RTT into account), then BGP-ORR is relevant only to the part where next-hop cost comes into play and in exactly the same way as in case of iBGP (with policy optimisation described above). > Exactly how much scope there is in practice for such optimisation, I don't > know. Optimal RR could scale better or perhaps worse than the IX cases I > know about. > Next-hop-based-path-selection and applying policies can be done in (pseudo-)parallel, in which case each of them is as good or as bad independently. >> forget that with BGP-ORR we efectively scale control-plane and >> forwarding-plane independently. I can buy high-throughput box with >> prehistoric computational capabilities and a number-cruncher both for >> reasonable money, without BGP-ORR I need to get >> high-throughput-number-cruncher at much higher cost. > > That'd be nice, yes. I don't disagree that this draft could be helpful, > even if scaling limits the achievable client:RR ratio. I just wanted to > caution against having too high expectations of that ratio. > Good, we're progressing :-) Kind regards, iLya From paul@jakma.org Mon Apr 11 10:06:55 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D85363A6938 for ; Mon, 11 Apr 2011 10:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD0qG9zhr-Uc for ; Mon, 11 Apr 2011 10:06:55 -0700 (PDT) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by core3.amsl.com (Postfix) with ESMTP id 9B6453A68DC for ; Mon, 11 Apr 2011 10:06:54 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk [130.209.244.4]) (authenticated bits=0) by hibernia.jakma.org (8.14.4/8.14.3) with ESMTP id p3BH6KlI005111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Apr 2011 18:06:24 +0100 Date: Mon, 11 Apr 2011 18:06:19 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: iLya In-Reply-To: Message-ID: References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> <18DC58C5-2C04-4E12-BE18-D93E041CEE2C@juniper.net> <70B86CF264BD43979010BFF95B34A350@hnivarlas1> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Robert Raszuk , Inter-Domain Routing List Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 17:06:56 -0000 On Mon, 11 Apr 2011, iLya wrote: > You do this only once, not for every UPDATE message. As long as > number of clients is far less than number of routes being > exchanged, that's negligible work. Couple of things: a) I did say later that you could trade some space for CPU b) It doesn't matter if you only do it every now and then if, when you must do it, the system then takes an unacceptably long amount of time to complete the task. c) I do not see how it is guaranteed that BGP UPDATE messages will come in much faster than IGP changes. It may be /often/ true, but it's far from guaranteed to be true, so you can't rely on it for worst-case big-Oh analysis. > In practice N=K case would happen only when every client is also > potential exit point, like in flat networks. There are further > optimisations possible depending on nature of that "flatness". E.g. > in Opt-C you could leverage the fact that most of "final next-hops" > will be reachable via relatively small subset of ABR/ASBR, > effectively reducing K significantly. In simple IPv4 net you can > also separate customer routes and external routes and apply > different style of optimisation. Things like finding hubs in graphs tends not to be entirely trivial though. It may range from O(V^3) kind of hard (feasible to a point, but far from ideal scaling) if you want to judge by, say, the relative number of shortest paths in the network that go through each node; to actually NP-hard (exact solutions for various kinds of graph optimisation problems). > Strictly speaking we don't really need to know all-pairs SPF, only > from any client to any exit point (so no K+N here). Doesn't matter, if we call the exit-point P, even if each K -> P lookup is O(1), that's still K operations that must be done. You could do it in stages perhaps, doing the K K->P lookups first and then the PN per-client work, for O(K + PN). But you're still at Omega(N^2) or Omega(P^2), depending on how P and N compare to each other. Omega meaning lower-bound, i.e. the SPF overhead is still to be applied on top of that: > And as above network topology knowledge may aid optimisation - if > path to all exits lies through small set of hub points (e.g. > P-routers), then preference calculations can be split in two (from > client to hub and from hub to exit), which may significantly reduce > amount of calculations that needs to be done. If you can do that, generally, in less than O(V^3), your name potentially could go down in the algorithm text books. In less than O(V^2) and fame would be guaranteed I suspect.. ;) Anyway... I support the adoption of the draft. regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: Hi! I'm Larry. This is my brother Bob, and this is my other brother Jimbo. We thought you might like to know the names of your assailants. From ilya@nobulus.com Mon Apr 11 11:05:06 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A443A28C0CF for ; Mon, 11 Apr 2011 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSSFT7BZAB8V for ; Mon, 11 Apr 2011 11:05:05 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 374A63A69A0 for ; Mon, 11 Apr 2011 11:05:02 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 75285170C3; Mon, 11 Apr 2011 20:05:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1glD+ANKS3lj; Mon, 11 Apr 2011 20:04:59 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id E86E7170BC; Mon, 11 Apr 2011 20:04:58 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ilya Varlashkin In-Reply-To: Date: Mon, 11 Apr 2011 20:04:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <268FDF21-1486-4B9F-BBF2-3905C88781F1@nobulus.com> References: <4D9482E7.5010905@cisco.com> <13205C286662DE4387D9AF3AC30EF456D340B41C31@EMBX01-WF.jnpr.net> <4D9CE4D3.9060401@cisco.com> <245D70EA-E9B8-4E78-B977-C875CD8053DB@juniper.net> <38296B4D-8BA6-4F53-AF61-78091BF28FDB@nobulus.com> <18DC58C5-2C04-4E12-BE18-D93E041CEE2C@juniper.net> <70B86CF264BD43979010BFF95B34A350@hnivarlas1> To: Paul Jakma , Inter-Domain Routing List X-Mailer: Apple Mail (2.1084) Subject: Re: [Idr] BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:05:06 -0000 On Apr 11, 2011, at 19:06 , Paul Jakma wrote: > c) I do not see how it is guaranteed that BGP UPDATE messages will > come in much faster than IGP changes. It may be /often/ true, > but it's far from guaranteed to be true, so you can't rely on it > for worst-case big-Oh analysis. >=20 Assumption is that your network is more stable than The Internet, so you = don't have as many IGP events as BGP updates. >> Strictly speaking we don't really need to know all-pairs SPF, only = from any client to any exit point (so no K+N here). >=20 > Doesn't matter, if we call the exit-point P, even if each K -> P = lookup is O(1), that's still K operations that must be done. >=20 Considering that K used to be number of exit points the above is a bit = confusing. If you mean K is number of clients (used to be N) and P = number of exit points. Assuming you want to fall back to Dijkstra, then = just reverse metrics (if they're asymmetric, NOP otherwise) and run P = iterations of Dijkstra (from next-hop back to the client). > Anyway... >=20 > I support the adoption of the draft. >=20 Thank you! Kind regards, iLya From randy@psg.com Tue Apr 12 06:07:10 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8815EE0705 for ; Tue, 12 Apr 2011 06:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWZEeI+hRZbK for ; Tue, 12 Apr 2011 06:07:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 1014AE0690 for ; Tue, 12 Apr 2011 06:07:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q9dJA-00022x-QK; Tue, 12 Apr 2011 13:07:04 +0000 Date: Tue, 12 Apr 2011 06:07:11 -0700 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 13:07:10 -0000 > I don't use the marker to sync the TCP stream. I use the length > field. I do use the marker to verify. this would all be simpler if bgp used a reliable transport such as tcp randy From jsw@inconcepts.biz Tue Apr 12 09:11:58 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B7100E083C for ; Tue, 12 Apr 2011 09:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCd85jC46Sz3 for ; Tue, 12 Apr 2011 09:11:58 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id DE8A2E083B for ; Tue, 12 Apr 2011 09:11:57 -0700 (PDT) Received: by vxg33 with SMTP id 33so6198185vxg.31 for ; Tue, 12 Apr 2011 09:11:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.193.69 with SMTP id dt5mr1960360vcb.93.1302624476649; Tue, 12 Apr 2011 09:07:56 -0700 (PDT) Received: by 10.220.182.132 with HTTP; Tue, 12 Apr 2011 09:07:56 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> Date: Tue, 12 Apr 2011 12:07:56 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 16:11:58 -0000 On Tue, Apr 12, 2011 at 9:07 AM, Randy Bush wrote: >> I don't use the marker to sync the TCP stream. I use the length >> field. I do use the marker to verify. > > this would all be simpler if bgp used a reliable transport such as tcp If the BGP implementation on one side of a session makes an error in calculating the length of a message, or truncates a message which should be sent, "stream sync" is lost. These posts have all been about the upper-bound of the message length field's affect on the ability to debug this situation. If you haven't done much programming with [ length + data | length + data ] type transactions over TCP, I understand how you could be confused about this. Everyone knows the message stream is transported over TCP. No one is suggesting any attempt to try to improve upon the already satisfactory reliability of the session transport. To make this simple, let's say the marker is always "Z," and the current message length can be 0-9A-H. Data inside the message can be any number or letter. Right now, this is basically how BGP works; I can send you: Z5HELLOZ5OOPSZ4OKAYZ5WORLD and you can diagnostically detect "off by 1" message lengths received from the neighbor, because your parser will always be looking at the length of the next message, which must be preceded by a Z, and may not itself be a Z. If the maximum message length is allowed to be 65535 (or really, greater than 65535-256) it is essentially possible for the message length itself to be "Z," so you could not detect "off by 1" in some cases, such as: Z5OOPSZZSUPERCALIFRAGILISTICEXPIALIDOCIOUS Why? Because the parser, in dealing with the above messages, would think the second message had length S followed by data UPERCALI... and believe the third letter Z was actually a marker, when in fact the second one is the marker and the third Z is the length of the second message. As I have posted before, I believe Jakob's suggestion has merit but it's difficult to understand why if you do not have any implementation experience. It's worth wrapping your head around before you form an opinion. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jakob.heitz@ericsson.com Tue Apr 12 09:45:58 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 67807E0837 for ; Tue, 12 Apr 2011 09:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=2.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hBIs2XlUtyW for ; Tue, 12 Apr 2011 09:45:57 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id CFA16E072E for ; Tue, 12 Apr 2011 09:45:57 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3CGjlo5019490; Tue, 12 Apr 2011 11:45:49 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 12 Apr 2011 12:45:43 -0400 From: Jakob Heitz To: Randy Bush Date: Tue, 12 Apr 2011 12:45:45 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv5MRAoHd+cE2FCQ+mMyVP+nJimqQ== Message-ID: References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 16:45:58 -0000 On Apr 12, 2011, at 6:07 AM, "Randy Bush" wrote: >> I don't use the marker to sync the TCP stream. I use the length >> field. I do use the marker to verify. >=20 > this would all be simpler if bgp used a reliable transport such as tcp I think you meant SCTP. What's stopping you from running yours on SCTP? >=20 > randy -- Jakob Heitz. From randy@psg.com Tue Apr 12 12:41:00 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1AE9EE0824 for ; Tue, 12 Apr 2011 12:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qudu+g7uDF+l for ; Tue, 12 Apr 2011 12:40:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id BBBDDE08E1 for ; Tue, 12 Apr 2011 12:40:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q9jSG-0003mX-7Y; Tue, 12 Apr 2011 19:40:52 +0000 Date: Tue, 12 Apr 2011 12:41:00 -0700 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 19:41:00 -0000 >>> I don't use the marker to sync the TCP stream. I use the length >>> field. I do use the marker to verify. >> this would all be simpler if bgp used a reliable transport such as tcp > I think you meant SCTP. i did not. i meant precisely what i wrote. From raszuk@cisco.com Tue Apr 12 13:03:41 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A21DDE0879 for ; Tue, 12 Apr 2011 13:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MKWHGUKKtew for ; Tue, 12 Apr 2011 13:03:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 8310EE0870 for ; Tue, 12 Apr 2011 13:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1537; q=dns/txt; s=iport; t=1302638620; x=1303848220; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0XGApbao8XASBbHHsPPq1GEE6mqBjj1H7vtR57Sb69w=; b=FD+vNVnEQLwWYIWEpeaDf8pG3YWn/dmAmkdZsrOoPVwDhubnjY8vRGB5 UFRglKzr+I805v8eYkS6wUOwp/kWqrpES7rc6BHBmNm/CPby/BzkbUsPI b5Ix4UPPm7e34XmS30hW28C3yyYIwISiKsBCuLGaIM9B/8HpQFOeINzme M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABWvpE2rRDoH/2dsb2JhbACmAXemV4JzDgGZfoVuBI1ig24 X-IronPort-AV: E=Sophos;i="4.64,198,1301875200"; d="scan'208";a="335732833" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2011 20:03:39 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3CK3cTN004087; Tue, 12 Apr 2011 20:03:38 GMT Message-ID: <4DA4B01D.7020803@cisco.com> Date: Tue, 12 Apr 2011 22:03:41 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Randy Bush References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:03:41 -0000 Hi Randy/all, I think the main question here to ask is do we really need an ability to detect message boundaries at BGP level or not. Historically when any BGP message was bad (errors of any sort etc ...) we dropped the session and restarted. Life was good. Now there is more and more proposals to break this original design as the price seems too high to impact 1000s users with one attribute error. With this in mind what Jakob and Jeff are saying does make sense. In fact I think it will make sense even more when we see someone to propose not to drop the session under the cases if BGP update msg boundaries were lost. Those are BGP level errors .. not transport errors like your reply may have had suggested. So we either never allow first length octet to be 0xFF or make sure there is some spacing of few octets of all zeros between BGP messages. Then parsing on N x 0x00 + 16 x 0xFF would have a chance to determine the BGP message boundary. As a side note the replay of message would not contain the spacing hence it would not be misinterpreted by any parsing routines. Rgs, R. >>>> I don't use the marker to sync the TCP stream. I use the length >>>> field. I do use the marker to verify. >>> this would all be simpler if bgp used a reliable transport such as tcp >> I think you meant SCTP. > > i did not. i meant precisely what i wrote. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From keyupate@cisco.com Tue Apr 12 13:30:29 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1B299E092C for ; Tue, 12 Apr 2011 13:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.901 X-Spam-Level: X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jTzZrUoPfwt for ; Tue, 12 Apr 2011 13:30:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 25798E090C for ; Tue, 12 Apr 2011 13:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=2247; q=dns/txt; s=iport; t=1302640228; x=1303849828; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=ZlwUDwjSZY1LFchS0V29cnhusSk/SMfcrNpDBfjI1l0=; b=U+BMaZt8m/3a8u2YRRafSrRCP/laJ5H0MEndFJcVScqoP8BttSecoKK2 tuZH7UzSCJDIXJXocUsdzjkeMhezQro2iKhPYSHREcSJ28Mycudro+qDu GYKwy9O3miNP56fhn0LWFSIW/0dLilfKjrRk5fPbr6qRPDP5uWIoEPCxz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEa1pE2rRDoI/2dsb2JhbACmAXeIep1qnQaFbgSFW4gHg3U X-IronPort-AV: E=Sophos;i="4.64,199,1301875200"; d="scan'208";a="679948562" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 12 Apr 2011 20:30:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3CKURWc014007; Tue, 12 Apr 2011 20:30:27 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 13:30:27 -0700 Received: from 10.21.86.9 ([10.21.86.9]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 Apr 2011 20:30:26 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 12 Apr 2011 13:29:52 -0700 From: Keyur Patel To: , Randy Bush Message-ID: Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv5UGBjnzwDRmVDEeC1tgAbY71bnA== In-Reply-To: <4DA4B01D.7020803@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Apr 2011 20:30:27.0453 (UTC) FILETIME=[7584D2D0:01CBF950] Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:30:29 -0000 Robert, BGP message length errors are hard to recover from particularly if these errors are due to some form of corruption. One never knows what else is messed up once such a corruption happens. If you ever want to solve such cases you probably want to consider soft-notify like mechanisms although they don't solve all cases. Reserving first octet of length field is not sufficient as it doesn't detect all the cases. Regards, Keyur On 4/12/11 1:03 PM, "Robert Raszuk" wrote: > Hi Randy/all, > > I think the main question here to ask is do we really need an ability to > detect message boundaries at BGP level or not. > > Historically when any BGP message was bad (errors of any sort etc ...) > we dropped the session and restarted. Life was good. > > Now there is more and more proposals to break this original design as > the price seems too high to impact 1000s users with one attribute error. > > With this in mind what Jakob and Jeff are saying does make sense. In > fact I think it will make sense even more when we see someone to propose > not to drop the session under the cases if BGP update msg boundaries > were lost. Those are BGP level errors .. not transport errors like your > reply may have had suggested. > > So we either never allow first length octet to be 0xFF or make sure > there is some spacing of few octets of all zeros between BGP messages. > Then parsing on N x 0x00 + 16 x 0xFF would have a chance to determine > the BGP message boundary. As a side note the replay of message would not > contain the spacing hence it would not be misinterpreted by any parsing > routines. > > Rgs, > R. > > >>>>> I don't use the marker to sync the TCP stream. I use the length >>>>> field. I do use the marker to verify. >>>> this would all be simpler if bgp used a reliable transport such as tcp >>> I think you meant SCTP. >> >> i did not. i meant precisely what i wrote. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Tue Apr 12 13:31:01 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 49A5CE0931 for ; Tue, 12 Apr 2011 13:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrbjqaWtisBJ for ; Tue, 12 Apr 2011 13:30:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 2B289E0916 for ; Tue, 12 Apr 2011 13:30:49 -0700 (PDT) Received: from [166.205.143.146] (helo=[10.46.204.199]) by psg.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9kEX-00043T-Rg; Tue, 12 Apr 2011 20:30:46 +0000 References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> <4DA4B01D.7020803@cisco.com> In-Reply-To: <4DA4B01D.7020803@cisco.com> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7294894A-FB22-47EA-8F74-13FF14D3DD16@psg.com> X-Mailer: iPhone Mail (8G4) From: Randy Bush Date: Tue, 12 Apr 2011 13:30:40 -0700 To: Robert Raszuk Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:31:01 -0000 Damn shame we can't use reliable transport and a length field randy, on iPhone On Apr 12, 2011, at 13:03, Robert Raszuk wrote: > Hi Randy/all, >=20 > I think the main question here to ask is do we really need an ability to d= etect message boundaries at BGP level or not. >=20 > Historically when any BGP message was bad (errors of any sort etc ...) we d= ropped the session and restarted. Life was good. >=20 > Now there is more and more proposals to break this original design as the p= rice seems too high to impact 1000s users with one attribute error. >=20 > With this in mind what Jakob and Jeff are saying does make sense. In fact I= think it will make sense even more when we see someone to propose not to dr= op the session under the cases if BGP update msg boundaries were lost. Those= are BGP level errors .. not transport errors like your reply may have had s= uggested. >=20 > So we either never allow first length octet to be 0xFF or make sure there i= s some spacing of few octets of all zeros between BGP messages. Then parsing= on N x 0x00 + 16 x 0xFF would have a chance to determine the BGP message bo= undary. As a side note the replay of message would not contain the spacing h= ence it would not be misinterpreted by any parsing routines. >=20 > Rgs, > R. >=20 >=20 >>>>> I don't use the marker to sync the TCP stream. I use the length >>>>> field. I do use the marker to verify. >>>> this would all be simpler if bgp used a reliable transport such as tcp >>> I think you meant SCTP. >>=20 >> i did not. i meant precisely what i wrote. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >>=20 >=20 From raszuk@cisco.com Tue Apr 12 13:37:28 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9CAF3E08DE for ; Tue, 12 Apr 2011 13:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbHMLhzczEps for ; Tue, 12 Apr 2011 13:37:27 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 7F02BE08B1 for ; Tue, 12 Apr 2011 13:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2154; q=dns/txt; s=iport; t=1302640647; x=1303850247; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wgjAYaAMrv4i5+Peg26tWmFoS7d60gJwmcZTk5ZnyC8=; b=gsdE4Nf41qAIhR7/XY9kLK5Lq+R1+mhi2tSRWxKw4VyURGS5VM9JDel/ e0qlAB8jQC5uG8bBPxsgCp/7cexz1K4x0Ec1GLwhIeDxAsHFKX6ZMicqR dn4D8B2e6j7Aods2wCds8i6MwFDZC9Z6OcAazeABcqsLcIIQWVai+0U4J M=; X-IronPort-AV: E=Sophos;i="4.64,199,1301875200"; d="scan'208";a="428532010" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 12 Apr 2011 20:37:27 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3CKbPUg021417; Tue, 12 Apr 2011 20:37:25 GMT Message-ID: <4DA4B809.6040809@cisco.com> Date: Tue, 12 Apr 2011 22:37:29 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Keyur Patel References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:37:28 -0000 Hi Keyur, > Reserving first octet of length field is not sufficient as it doesn't > detect all the cases. Indeed .. hence my suggestion of extra zeros spacing between messages. Then length field could be of any value. What do you and others think about it ? The alternative would be to always drop the session/inject soft-notify etc ... if message boundaries can not be determined. Cheers, R. > Robert, > > BGP message length errors are hard to recover from particularly if these > errors are due to some form of corruption. One never knows what else is > messed up once such a corruption happens. If you ever want to solve such > cases you probably want to consider soft-notify like mechanisms although > they don't solve all cases. > > Reserving first octet of length field is not sufficient as it doesn't detect > all the cases. > > Regards, > Keyur > > On 4/12/11 1:03 PM, "Robert Raszuk" wrote: > >> Hi Randy/all, >> >> I think the main question here to ask is do we really need an ability to >> detect message boundaries at BGP level or not. >> >> Historically when any BGP message was bad (errors of any sort etc ...) >> we dropped the session and restarted. Life was good. >> >> Now there is more and more proposals to break this original design as >> the price seems too high to impact 1000s users with one attribute error. >> >> With this in mind what Jakob and Jeff are saying does make sense. In >> fact I think it will make sense even more when we see someone to propose >> not to drop the session under the cases if BGP update msg boundaries >> were lost. Those are BGP level errors .. not transport errors like your >> reply may have had suggested. >> >> So we either never allow first length octet to be 0xFF or make sure >> there is some spacing of few octets of all zeros between BGP messages. >> Then parsing on N x 0x00 + 16 x 0xFF would have a chance to determine >> the BGP message boundary. As a side note the replay of message would not >> contain the spacing hence it would not be misinterpreted by any parsing >> routines. >> >> Rgs, >> R. From keyupate@cisco.com Tue Apr 12 14:15:15 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 306FCE0968 for ; Tue, 12 Apr 2011 14:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.25 X-Spam-Level: X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RUVWUUeOCZ6 for ; Tue, 12 Apr 2011 14:15:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 36C2BE0960 for ; Tue, 12 Apr 2011 14:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=2465; q=dns/txt; s=iport; t=1302642914; x=1303852514; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Q8ZuGtougpxa5NaA73sxquy5ZEFmIAmxfUXwTloDOR0=; b=ApZYtTLe5F7hIKz4+NcxOVlauIPrqdTa2foibcmHh3r5riG+Eo0Uvwr9 slUPfMQb43kOSsu63YvtRhRtnbw4/G7yVxu2hBs/wgZKwm6JzZ0RGq89S UsG0tECYI/bB/Ho8NVjPwNX2ZY9OmERJnhAsCpNBbYCBW7XQ/P7s4hauS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQHAHDApE2rRDoI/2dsb2JhbACYW40pd4h6nX6dD4VuBIVbiAeDdQ X-IronPort-AV: E=Sophos;i="4.64,199,1301875200"; d="scan'208";a="335780909" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2011 21:15:13 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3CLFDnl025950; Tue, 12 Apr 2011 21:15:13 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 14:15:13 -0700 Received: from 10.21.86.9 ([10.21.86.9]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 Apr 2011 21:15:12 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 12 Apr 2011 14:14:38 -0700 From: Keyur Patel To: Message-ID: Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv5VqFe4Df1IGVJEeC1tgAbY71bnA== In-Reply-To: <4DA4B809.6040809@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Apr 2011 21:15:13.0455 (UTC) FILETIME=[B68033F0:01CBF956] Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:15:15 -0000 Hi Robert, Sure. IMHO, we should NOT be limiting length field for this purpose. Anything else probably should be handled as a separate draft. Regards, Keyur On 4/12/11 1:37 PM, "Robert Raszuk" wrote: > Hi Keyur, > >> Reserving first octet of length field is not sufficient as it doesn't >> detect all the cases. > > Indeed .. hence my suggestion of extra zeros spacing between messages. > Then length field could be of any value. What do you and others think > about it ? > > The alternative would be to always drop the session/inject soft-notify > etc ... if message boundaries can not be determined. > > Cheers, > R. > > >> Robert, >> >> BGP message length errors are hard to recover from particularly if these >> errors are due to some form of corruption. One never knows what else is >> messed up once such a corruption happens. If you ever want to solve such >> cases you probably want to consider soft-notify like mechanisms although >> they don't solve all cases. >> >> Reserving first octet of length field is not sufficient as it doesn't detect >> all the cases. >> >> Regards, >> Keyur >> >> On 4/12/11 1:03 PM, "Robert Raszuk" wrote: >> >>> Hi Randy/all, >>> >>> I think the main question here to ask is do we really need an ability to >>> detect message boundaries at BGP level or not. >>> >>> Historically when any BGP message was bad (errors of any sort etc ...) >>> we dropped the session and restarted. Life was good. >>> >>> Now there is more and more proposals to break this original design as >>> the price seems too high to impact 1000s users with one attribute error. >>> >>> With this in mind what Jakob and Jeff are saying does make sense. In >>> fact I think it will make sense even more when we see someone to propose >>> not to drop the session under the cases if BGP update msg boundaries >>> were lost. Those are BGP level errors .. not transport errors like your >>> reply may have had suggested. >>> >>> So we either never allow first length octet to be 0xFF or make sure >>> there is some spacing of few octets of all zeros between BGP messages. >>> Then parsing on N x 0x00 + 16 x 0xFF would have a chance to determine >>> the BGP message boundary. As a side note the replay of message would not >>> contain the spacing hence it would not be misinterpreted by any parsing >>> routines. >>> >>> Rgs, >>> R. From ilya@nobulus.com Tue Apr 12 14:41:02 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 24CAEE097F for ; Tue, 12 Apr 2011 14:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olA45Zar+OT7 for ; Tue, 12 Apr 2011 14:41:01 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfc.amsl.com (Postfix) with ESMTP id 75FB4E0809 for ; Tue, 12 Apr 2011 14:41:01 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id DF55B1742A; Tue, 12 Apr 2011 23:40:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a0GGlcIam4SP; Tue, 12 Apr 2011 23:40:58 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 9A3161742B; Tue, 12 Apr 2011 23:40:57 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: <4DA4B809.6040809@cisco.com> Date: Tue, 12 Apr 2011 23:39:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DA4B809.6040809@cisco.com> To: raszuk@cisco.com X-Mailer: Apple Mail (2.1084) Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:41:02 -0000 On Apr 12, 2011, at 22:37 , Robert Raszuk wrote: > Hi Keyur, >=20 > > Reserving first octet of length field is not sufficient as it = doesn't > > detect all the cases. >=20 > Indeed .. hence my suggestion of extra zeros spacing between messages. = Then length field could be of any value. What do you and others think = about it ? >=20 As an alternative to non-FF octet following the marker, we could add = some padding attribute (provided we use MP-BGP style Attr 14/15 for = conveying NLRI) that would be last attribute in an UPDATE message and = contain sufficient number of zeroes. Ironically this will be similar to = decreasing max value of length, but may be more helpful in recovering = lost stream sync. So if stream sync is common issue, then one way or = another effective max message size will be decreased. Whether to use = length field for that purpose or adding padding, people more close to = the code should say what's more efficient/useful. =46rom protocol = clarity perspective length field should not be cannibalized (thinking of = analogy with Type/Length in Ethernet header). > The alternative would be to always drop the session/inject soft-notify = etc ... if message boundaries can not be determined. >=20 Yet another alternative - send 5 KEEPALIVES one after another :-) N.B.: = In every joke there is a part which is a joke. Cheers, iLya From raszuk@cisco.com Tue Apr 12 15:12:40 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4E152E0828 for ; Tue, 12 Apr 2011 15:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTIvoTqUZsWO for ; Tue, 12 Apr 2011 15:12:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 9F91EE079B for ; Tue, 12 Apr 2011 15:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1388; q=dns/txt; s=iport; t=1302646330; x=1303855930; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VHU7mgk20uhFEL8skILROhSZkvxBE7ckBoJLmuq3X/g=; b=VHaKw+gCbcYww5Wjyunhc6ngDBn3TWU+Di6HNhHpKJAOIboZEfDOtVw6 uwpTJWDOG6Qz8igjYyv8rX6KJS+OfyjIbGVkGf7njRRuFhmxmaf0dkbX9 0u92je8jYlFLUI3YJsk2vP6JddWMb6es8pRNR/kVDVAvzYAiRQ2XrT6GU E=; X-IronPort-AV: E=Sophos;i="4.64,200,1301875200"; d="scan'208";a="428589465" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-1.cisco.com with ESMTP; 12 Apr 2011 22:12:09 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3CMC7IQ010509; Tue, 12 Apr 2011 22:12:08 GMT Message-ID: <4DA4CE3B.6000105@cisco.com> Date: Wed, 13 Apr 2011 00:12:11 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ilya Varlashkin References: <4DA4B809.6040809@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 22:12:40 -0000 Hi Ilya, >> Indeed .. hence my suggestion of extra zeros spacing between >> messages. Then length field could be of any value. What do you and >> others think about it ? > > As an alternative to non-FF octet following the marker, we could add > some padding attribute (provided we use MP-BGP style Attr 14/15 for > conveying NLRI) that would be last attribute in an UPDATE message and > contain sufficient number of zeroes. The entire trick here is that such spacing should not be within the update message boundaries as if it would all bets are off. >> The alternative would be to always drop the session/inject >> soft-notify etc ... if message boundaries can not be determined. >> > Yet another alternative - send 5 KEEPALIVES one after another :-) > N.B.: In every joke there is a part which is a joke. That is in fact not that much of a joke ! The inter message spacing I had in mind was just to be a new BGP message called ZERO Msg. It would be of fixed size and consist of only N octets of all zeros (Anti-Marker). But before we go there I think folks on the list need to really express if BGP message boundary parsing at the BGP level is really required. Otherwise checking even 16 octets of all 1s followed by the msg length should be sufficient especially as an extra safeguard regardless of what the 17th octet contains. Cheers, R. From curtis@occnc.com Tue Apr 12 16:46:09 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 691D9E07AF for ; Tue, 12 Apr 2011 16:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wxpmYQFFl-1 for ; Tue, 12 Apr 2011 16:46:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id D1D72E067B for ; Tue, 12 Apr 2011 16:46:07 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3CNk6hs072601; Tue, 12 Apr 2011 19:46:06 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104122346.p3CNk6hs072601@harbor.orleans.occnc.com> To: Jeff Wheeler From: Curtis Villamizar In-reply-to: Your message of "Tue, 12 Apr 2011 12:07:56 EDT." Date: Tue, 12 Apr 2011 19:46:06 -0400 Sender: curtis@occnc.com Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 23:46:09 -0000 In message Jeff Wheeler writes: > > On Tue, Apr 12, 2011 at 9:07 AM, Randy Bush wrote: > >> I don't use the marker to sync the TCP stream. I use the length > >> field. I do use the marker to verify. > > > > this would all be simpler if bgp used a reliable transport such as tcp > > If the BGP implementation on one side of a session makes an error in > calculating the length of a message, or truncates a message which > should be sent, "stream sync" is lost. These posts have all been > about the upper-bound of the message length field's affect on the > ability to debug this situation. Getting a TLV protocol right is not rocket science. I think everyone uses the length to figure out where the next packet should start and then checks for the marker as you've described. Have BGP implementation really become that bad lately? > If you haven't done much programming with [ length + data | length + > data ] type transactions over TCP, I understand how you could be > confused about this. Everyone knows the message stream is transported > over TCP. No one is suggesting any attempt to try to improve upon the > already satisfactory reliability of the session transport. [... example snipped ...] btw - I don't think Randy is at all confused about this. Terse sarcasm doesn't always get through email as intended (maybe we need a new MIME type text/sarcasm - oh - more multipart messages, never mind) Perhaps it would be best to 1) remove the possibility of unidirectional extended message capability described in the draft and 2) bound the size of normal messages such that an entire message can easily fit into a NOTIFICATION message (ie 65K - 256). Reinventing HDLC in BGP (or PPP byte stuffing) seems like a bad idea. An implementation that can't count bytes and build a TLV right deserves a CEASE (and a long hold down). Curtis From curtis@occnc.com Tue Apr 12 17:05:52 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5C824E0951 for ; Tue, 12 Apr 2011 17:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4N0eXJo2Zi0 for ; Tue, 12 Apr 2011 17:05:51 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id CCCC4E08F6 for ; Tue, 12 Apr 2011 17:05:38 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3D05art073485; Tue, 12 Apr 2011 20:05:36 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104130005.p3D05art073485@harbor.orleans.occnc.com> To: raszuk@cisco.com From: Curtis Villamizar In-reply-to: Your message of "Tue, 12 Apr 2011 22:37:29 +0200." <4DA4B809.6040809@cisco.com> Date: Tue, 12 Apr 2011 20:05:36 -0400 Sender: curtis@occnc.com Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 00:05:52 -0000 In message <4DA4B809.6040809@cisco.com> Robert Raszuk writes: > > Hi Keyur, > > > Reserving first octet of length field is not sufficient as it doesn't > > detect all the cases. > > Indeed .. hence my suggestion of extra zeros spacing between messages. > Then length field could be of any value. What do you and others think > about it ? > > The alternative would be to always drop the session/inject soft-notify > etc ... if message boundaries can not be determined. > > Cheers, > R. If you really wanted it to work you would need to reinvent PPP byte stuffing for BGP. And *no* I don't want to go there. Curtis > > Robert, > > > > BGP message length errors are hard to recover from particularly if these > > errors are due to some form of corruption. One never knows what else is > > messed up once such a corruption happens. If you ever want to solve such > > cases you probably want to consider soft-notify like mechanisms although > > they don't solve all cases. > > > > Reserving first octet of length field is not sufficient as it doesn't detect > > all the cases. > > > > Regards, > > Keyur > > > > On 4/12/11 1:03 PM, "Robert Raszuk" wrote: > > > >> Hi Randy/all, > >> > >> I think the main question here to ask is do we really need an ability to > >> detect message boundaries at BGP level or not. > >> > >> Historically when any BGP message was bad (errors of any sort etc ...) > >> we dropped the session and restarted. Life was good. > >> > >> Now there is more and more proposals to break this original design as > >> the price seems too high to impact 1000s users with one attribute error. > >> > >> With this in mind what Jakob and Jeff are saying does make sense. In > >> fact I think it will make sense even more when we see someone to propose > >> not to drop the session under the cases if BGP update msg boundaries > >> were lost. Those are BGP level errors .. not transport errors like your > >> reply may have had suggested. > >> > >> So we either never allow first length octet to be 0xFF or make sure > >> there is some spacing of few octets of all zeros between BGP messages. > >> Then parsing on N x 0x00 + 16 x 0xFF would have a chance to determine > >> the BGP message boundary. As a side note the replay of message would not > >> contain the spacing hence it would not be misinterpreted by any parsing > >> routines. > >> > >> Rgs, > >> R. From shane@castlepoint.net Tue Apr 12 18:51:53 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BF0C0E06C4 for ; Tue, 12 Apr 2011 18:51:53 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub-uN1L+JpLB for ; Tue, 12 Apr 2011 18:51:53 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfc.amsl.com (Postfix) with ESMTP id 00EBDE0679 for ; Tue, 12 Apr 2011 18:51:52 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 2FF5E268037; Tue, 12 Apr 2011 19:51:52 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 12 Apr 2011 19:51:52 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=62176; syn-fingerprint=65535:56:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <7294894A-FB22-47EA-8F74-13FF14D3DD16@psg.com> Date: Tue, 12 Apr 2011 19:51:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9DEC27F3-407A-4C71-A718-61DA6E5063AE@castlepoint.net> References: <4D8904EA.8040106@cisco.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <4DA1F590.9080804@cisco.com> <2A2191F7-ECD8-4D8C-82B2-4281D35EE1CE@ericsson.com> <4DA4B01D.7020803@cisco.com> <7294894A-FB22-47EA-8F74-13FF14D3DD16@psg.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: Robert Raszuk , "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 01:51:53 -0000 On Apr 12, 2011, at 2:30 PM, Randy Bush wrote: > Damn shame we can't use reliable transport and a length field ... and, TCP-MD5 on top of that. -shane > randy, on iPhone >=20 > On Apr 12, 2011, at 13:03, Robert Raszuk wrote: >=20 >> Hi Randy/all, >>=20 >> I think the main question here to ask is do we really need an ability = to detect message boundaries at BGP level or not. >>=20 >> Historically when any BGP message was bad (errors of any sort etc = ...) we dropped the session and restarted. Life was good. >>=20 >> Now there is more and more proposals to break this original design as = the price seems too high to impact 1000s users with one attribute error. >>=20 >> With this in mind what Jakob and Jeff are saying does make sense. In = fact I think it will make sense even more when we see someone to propose = not to drop the session under the cases if BGP update msg boundaries = were lost. Those are BGP level errors .. not transport errors like your = reply may have had suggested. >>=20 >> So we either never allow first length octet to be 0xFF or make sure = there is some spacing of few octets of all zeros between BGP messages. = Then parsing on N x 0x00 + 16 x 0xFF would have a chance to determine = the BGP message boundary. As a side note the replay of message would not = contain the spacing hence it would not be misinterpreted by any parsing = routines. >>=20 >> Rgs, >> R. >>=20 >>=20 >>>>>> I don't use the marker to sync the TCP stream. I use the length >>>>>> field. I do use the marker to verify. >>>>> this would all be simpler if bgp used a reliable transport such as = tcp >>>> I think you meant SCTP. >>>=20 >>> i did not. i meant precisely what i wrote. >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>>=20 >>=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Tue Apr 12 19:58:04 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4EC71E066A for ; Tue, 12 Apr 2011 19:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6THlyzwnIvoc for ; Tue, 12 Apr 2011 19:58:03 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfc.amsl.com (Postfix) with ESMTP id 73EE4E0683 for ; Tue, 12 Apr 2011 19:58:03 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTaUROiE+xVo6Qq+UQBGYWNYoy1BEQ5T3@postini.com; Tue, 12 Apr 2011 19:58:03 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 12 Apr 2011 19:55:14 -0700 From: John Scudder To: "idr@ietf.org List" Date: Tue, 12 Apr 2011 19:57:06 -0700 Thread-Topic: WGLC for draft-ietf-idr-fsm-subcode-01 Thread-Index: Acv5hjYAAhesbnp2RhaIBlVBjN0Lmg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] WGLC for draft-ietf-idr-fsm-subcode-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 02:58:04 -0000 Folks, This is to start an IDR working group last call for draft-ietf-idr-fsm-subc= ode-01. Please send your comments by April 27. Thanks, --John= From randy@psg.com Wed Apr 13 03:41:01 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C21AAE06BE for ; Wed, 13 Apr 2011 03:41:01 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSVETU6Cw02b for ; Wed, 13 Apr 2011 03:41:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 18F69E06B1 for ; Wed, 13 Apr 2011 03:41:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q9xVL-0007iW-5h; Wed, 13 Apr 2011 10:40:59 +0000 Date: Wed, 13 Apr 2011 19:41:10 +0900 Message-ID: From: Randy Bush To: Curtis Villamizar In-Reply-To: <201104122346.p3CNk6hs072601@harbor.orleans.occnc.com> References: <201104122346.p3CNk6hs072601@harbor.orleans.occnc.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:41:01 -0000 > Getting a TLV protocol right is not rocket science. no, but understanding it seems to be fwiw, i do not have serious problems with the capability being bi-directional. my co-authors may. randy From randy@psg.com Wed Apr 13 03:44:43 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 750C8E06CA for ; Wed, 13 Apr 2011 03:44:43 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMuSmZby1Twu for ; Wed, 13 Apr 2011 03:44:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id E0ECDE06C2 for ; Wed, 13 Apr 2011 03:44:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q9xYw-0007jt-4X; Wed, 13 Apr 2011 10:44:42 +0000 Date: Wed, 13 Apr 2011 19:44:53 +0900 Message-ID: From: Randy Bush To: Curtis Villamizar In-Reply-To: <201104130005.p3D05art073485@harbor.orleans.occnc.com> References: <4DA4B809.6040809@cisco.com> <201104130005.p3D05art073485@harbor.orleans.occnc.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:44:43 -0000 >> The alternative would be to always drop the session/inject >> soft-notify etc ... if message boundaries can not be determined. > If you really wanted it to work you would need to reinvent PPP byte > stuffing for BGP. And *no* I don't want to go there. those who want to put start/end-record flags in the stream should be forced to run and debug slip for a month. randy From jakob.heitz@ericsson.com Wed Apr 13 10:29:35 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 49B4EE0789 for ; Wed, 13 Apr 2011 10:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=1.633, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPoRCjy37Ibh for ; Wed, 13 Apr 2011 10:29:34 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id AEA83E07A0 for ; Wed, 13 Apr 2011 10:29:34 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3DHTSZM031335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Apr 2011 12:29:34 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([147.117.20.156]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 13 Apr 2011 13:29:25 -0400 From: Jakob Heitz To: Randy Bush , "idr@ietf.org" Date: Wed, 13 Apr 2011 13:29:22 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: AcvpDz+gEP0HO3eDS7We/H1kLtcVRgQ8Ohaw Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F87B284@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7C01@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:29:35 -0000 I think you're the one throwing numbers, because you have no clue how much you need. Show me the 65535 long BGP message. -- Jakob Heitz. > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com]=20 > Sent: Tuesday, March 22, 2011 9:03 PM > To: Jakob Heitz > Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 >=20 > > Sorry Randy, I didn't get your point. >=20 > well, a typo probably did not help >=20 > >>> How about some numbers: > >>> maximm message size =3D 65000 > >>> maximum update message size =3D 64000 > >>>=20 > >>> It won't hurt anyone to have it a little short of 65535=20 > and it gives > >>> us a little playroom for the "what if" cases. > >>=20 > >> throwing kitty litter over your off by onw errors is a giggle. > >> trying to cover up an off by 1000 error had me laughing for five > >> minutes. >=20 > s/onw/one/ >=20 > you're just throwing numbers because you do not really know what you > need. you are reversing the solution. there should be no what if > cases. >=20 > randy > = From ben@niven-jenkins.co.uk Wed Apr 13 10:37:06 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BFF34E0845; Wed, 13 Apr 2011 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTB2fn0HVM8T; Wed, 13 Apr 2011 10:37:06 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfc.amsl.com (Postfix) with ESMTP id 415D3E083C; Wed, 13 Apr 2011 10:37:06 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-108-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QA403-0008Qd-8g; Wed, 13 Apr 2011 18:37:07 +0100 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2011 18:37:04 +0100 Message-Id: To: l3vpn@ietf.org, idr@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:37:06 -0000 L3VPNers & IDRers, This e-mail is the start of a joint L3VPN & IDR WG Last Call for = draft-ietf-l3vpn-ibgp-02. Feedback should be provided to the mailing list(s) and/or the authors. The Last Call ends midnight PDT 27th April 2011. You can view the draft here: http://tools.ietf.org/id/draft-ietf-l3vpn-ibgp-02.txt Thanks Ben (on behalf of the L3VPN & IDR chairs)= From randy@psg.com Wed Apr 13 11:25:53 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EB70DE0682 for ; Wed, 13 Apr 2011 11:25:53 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh6JRiEd71N4 for ; Wed, 13 Apr 2011 11:25:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 4543AE0665 for ; Wed, 13 Apr 2011 11:25:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QA4lC-0009TQ-Eo; Wed, 13 Apr 2011 18:25:50 +0000 Date: Thu, 14 Apr 2011 03:26:02 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F87B284@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7C01@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21390E3F87B284@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 18:25:54 -0000 > I think you're the one throwing numbers, because you > have no clue how much you need. > > Show me the 65535 long BGP message. check out the bgpsec work in sidr wg. randy --- Q: Because it reverses the logical flow of conversation. A: Why is top posting frowned upon? > > -- > Jakob Heitz. > > > -----Original Message----- > > From: Randy Bush [mailto:randy@psg.com] > > Sent: Tuesday, March 22, 2011 9:03 PM > > To: Jakob Heitz > > Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 > > > > > Sorry Randy, I didn't get your point. > > > > well, a typo probably did not help > > > > >>> How about some numbers: > > >>> maximm message size = 65000 > > >>> maximum update message size = 64000 > > >>> > > >>> It won't hurt anyone to have it a little short of 65535 > > and it gives > > >>> us a little playroom for the "what if" cases. > > >> > > >> throwing kitty litter over your off by onw errors is a giggle. > > >> trying to cover up an off by 1000 error had me laughing for five > > >> minutes. > > > > s/onw/one/ > > > > you're just throwing numbers because you do not really know what you > > need. you are reversing the solution. there should be no what if > > cases. > > > > randy > > From jakob.heitz@ericsson.com Wed Apr 13 11:46:05 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BC193E06E2 for ; Wed, 13 Apr 2011 11:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.129 X-Spam-Level: X-Spam-Status: No, score=-5.129 tagged_above=-999 required=5 tests=[AWL=1.470, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6rZi9YXBhYQ for ; Wed, 13 Apr 2011 11:46:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 1DCAAE06AC for ; Wed, 13 Apr 2011 11:46:04 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3DIjQPc018407; Wed, 13 Apr 2011 13:46:05 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([147.117.20.156]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 13 Apr 2011 14:46:01 -0400 From: Jakob Heitz To: Randy Bush Date: Wed, 13 Apr 2011 14:45:58 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv6CDxGqNNr4ahRRxKQWCi7j+EL6wAAZ5yQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F87B33E@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7C01@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21390E3F87B284@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 18:46:05 -0000 I see a 256 byte signature added at each AS and a single NLRI in each update. How many AS's do you want to pass through? -- Jakob Heitz. =20 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com]=20 > Sent: Wednesday, April 13, 2011 11:26 AM > To: Jakob Heitz > Cc: idr@ietf.org > Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 >=20 > > I think you're the one throwing numbers, because you > > have no clue how much you need. > >=20 > > Show me the 65535 long BGP message. >=20 > check out the bgpsec work in sidr wg. >=20 >=20 > randy > --- > Q: Because it reverses the logical flow of conversation. > A: Why is top posting frowned upon? >=20 >=20 > >=20 > > -- > > Jakob Heitz. > >=20 > > > -----Original Message----- > > > From: Randy Bush [mailto:randy@psg.com]=20 > > > Sent: Tuesday, March 22, 2011 9:03 PM > > > To: Jakob Heitz > > > Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 > > >=20 > > > > Sorry Randy, I didn't get your point. > > >=20 > > > well, a typo probably did not help > > >=20 > > > >>> How about some numbers: > > > >>> maximm message size =3D 65000 > > > >>> maximum update message size =3D 64000 > > > >>>=20 > > > >>> It won't hurt anyone to have it a little short of 65535=20 > > > and it gives > > > >>> us a little playroom for the "what if" cases. > > > >>=20 > > > >> throwing kitty litter over your off by onw errors is a giggle. > > > >> trying to cover up an off by 1000 error had me=20 > laughing for five > > > >> minutes. > > >=20 > > > s/onw/one/ > > >=20 > > > you're just throwing numbers because you do not really=20 > know what you > > > need. you are reversing the solution. there should be no what if > > > cases. > > >=20 > > > randy > > >=20 > = From curtis@occnc.com Wed Apr 13 12:28:15 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 08673E06AC for ; Wed, 13 Apr 2011 12:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fko+gJ54zWS5 for ; Wed, 13 Apr 2011 12:28:13 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id CC123E07C8 for ; Wed, 13 Apr 2011 12:28:13 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3DJSCM8018945; Wed, 13 Apr 2011 15:28:12 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104131928.p3DJSCM8018945@harbor.orleans.occnc.com> To: Randy Bush From: Curtis Villamizar In-reply-to: Your message of "Wed, 13 Apr 2011 19:41:10 +0900." Date: Wed, 13 Apr 2011 15:28:12 -0400 Sender: curtis@occnc.com Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:28:15 -0000 In message Randy Bush writes: > > > Getting a TLV protocol right is not rocket science. > > no, but understanding it seems to be > > fwiw, i do not have serious problems with the capability being > bi-directional. my co-authors may. > > randy What I meant by bi-directional is both sides have to be able and willing to receive extended-messages for either side to send them. That way an entire packet can always be sent in the reverse direction when indicating that something was wrong with it. Curtis From keyupate@cisco.com Wed Apr 13 12:32:33 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D97AAE0731 for ; Wed, 13 Apr 2011 12:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.333 X-Spam-Level: X-Spam-Status: No, score=-9.333 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSvA5yyLmOm4 for ; Wed, 13 Apr 2011 12:32:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id C8E84E065C for ; Wed, 13 Apr 2011 12:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=1086; q=dns/txt; s=iport; t=1302723152; x=1303932752; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=JkJMzbmnccv1O5Lx8OlQvWgPiic9240NXo+FJ1ewL7w=; b=cSEJB14SyedfRfoBu7+TkGRY4UB2tz3XLX68hMsixac74f2g2chRdvfl 1mcL/Y0lmg6opCCylWebmpyckG9pImoPQ2jJslvuUIt3dG1piV9T5VYth boy+DIGuHun1I8M43hubWONAodLwHd1TVTOgL9c7ktbN2tnhT1RVHSNYF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkGAJP5pU2rRDoH/2dsb2JhbACmGAJ3iG+dMJx8hW4EhVqIDoN2hW4 X-IronPort-AV: E=Sophos;i="4.64,205,1301875200"; d="scan'208";a="336509093" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 13 Apr 2011 19:32:31 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3DJWVLt022017; Wed, 13 Apr 2011 19:32:31 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 12:32:31 -0700 Received: from 128.107.114.47 ([128.107.114.47]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.32]) with Microsoft Exchange Server HTTP-DAV ; Wed, 13 Apr 2011 19:32:30 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 13 Apr 2011 12:31:57 -0700 From: Keyur Patel To: , Randy Bush Message-ID: Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv6EXOJsihuQmYEEeCGfQAbY71bnA== In-Reply-To: <201104131928.p3DJSCM8018945@harbor.orleans.occnc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Apr 2011 19:32:31.0389 (UTC) FILETIME=[88094CD0:01CBFA11] Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:32:34 -0000 Curtis, On 4/13/11 12:28 PM, "Curtis Villamizar" wrote: > > In message > Randy Bush writes: >> >>> Getting a TLV protocol right is not rocket science. >> >> no, but understanding it seems to be >> >> fwiw, i do not have serious problems with the capability being >> bi-directional. my co-authors may. >> >> randy > > > What I meant by bi-directional is both sides have to be able and > willing to receive extended-messages for either side to send them. > That way an entire packet can always be sent in the reverse direction > when indicating that something was wrong with it. If a BGP sending speaker sees a need to receive complete encapsulated packet, it can always send original packet with size less than 65K. You don't need capability to be *bi-directional*. There are cases where asymmetric capability may be needed. Regards, Keyur > > Curtis > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From curtis@occnc.com Wed Apr 13 12:36:19 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 01F74E07FF for ; Wed, 13 Apr 2011 12:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8mNHxsBUmzP for ; Wed, 13 Apr 2011 12:36:18 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 25847E07F9 for ; Wed, 13 Apr 2011 12:36:18 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3DJaFeF019088; Wed, 13 Apr 2011 15:36:15 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104131936.p3DJaFeF019088@harbor.orleans.occnc.com> To: Jakob Heitz From: Curtis Villamizar In-reply-to: Your message of "Wed, 13 Apr 2011 13:29:22 EDT." <7309FCBCAE981B43ABBE69B31C8D21390E3F87B284@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 13 Apr 2011 15:36:15 -0400 Sender: curtis@occnc.com Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:36:19 -0000 In message <7309FCBCAE981B43ABBE69B31C8D21390E3F87B284@EUSAACMS0701.eamcs.ericsson.se> Jakob Heitz writes: > > > I think you're the one throwing numbers, because you > have no clue how much you need. > > Show me the 65535 long BGP message. > > -- > Jakob Heitz. Ignoring SIDR for the moment. If I remember this right, a 4K BGP update holds over 500 prefixes. I can remember way back in the early BGP4 days when there were plenty of times where the 4K BGP update filled and a new update had to be created. That code was well exercises 15 years ago. I seriously doubt we are doing a great job aggregating and there are no more AS announcing more than 500 prefixes with the same AS_PATH and other attributes. Add to that the many uses of MP-BGP and SIDR and packets can get quite big. Certainly larger than 4K. Curtis > > -----Original Message----- > > From: Randy Bush [mailto:randy@psg.com] > > Sent: Tuesday, March 22, 2011 9:03 PM > > To: Jakob Heitz > > Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 > > > > > Sorry Randy, I didn't get your point. > > > > well, a typo probably did not help > > > > >>> How about some numbers: > > >>> maximm message size = 65000 > > >>> maximum update message size = 64000 > > >>> > > >>> It won't hurt anyone to have it a little short of 65535 > > and it gives > > >>> us a little playroom for the "what if" cases. > > >> > > >> throwing kitty litter over your off by onw errors is a giggle. > > >> trying to cover up an off by 1000 error had me laughing for five > > >> minutes. > > > > s/onw/one/ > > > > you're just throwing numbers because you do not really know what you > > need. you are reversing the solution. there should be no what if > > cases. > > > > randy From randy@psg.com Wed Apr 13 12:36:26 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2B3FEE0816 for ; Wed, 13 Apr 2011 12:36:26 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A28CZlbW9hMR for ; Wed, 13 Apr 2011 12:36:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 98137E07F9 for ; Wed, 13 Apr 2011 12:36:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QA5rR-0009kN-Sr; Wed, 13 Apr 2011 19:36:22 +0000 Date: Thu, 14 Apr 2011 04:36:34 +0900 Message-ID: From: Randy Bush To: Curtis Villamizar In-Reply-To: <201104131928.p3DJSCM8018945@harbor.orleans.occnc.com> References: <201104131928.p3DJSCM8018945@harbor.orleans.occnc.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:36:26 -0000 >> fwiw, i do not have serious problems with the capability being >> bi-directional. my co-authors may. > What I meant by bi-directional was pretty obvious > That way an entire packet can always be sent in the reverse direction > when indicating that something was wrong with it. i do not care what is sent. all these payload issues are a layer above pdu size. but i will admit to great amusement at wanting to transport a full error frame of an erroneous full error frame reporting a full error frame and so on ad infinitum. randy From curtis@occnc.com Wed Apr 13 20:34:20 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D739E07AF for ; Wed, 13 Apr 2011 20:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3OzZVViBVoH for ; Wed, 13 Apr 2011 20:34:20 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id D65F9E0691 for ; Wed, 13 Apr 2011 20:34:19 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3E3YHTA025359; Wed, 13 Apr 2011 23:34:17 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104140334.p3E3YHTA025359@harbor.orleans.occnc.com> To: Keyur Patel From: Curtis Villamizar In-reply-to: Your message of "Wed, 13 Apr 2011 12:31:57 PDT." Date: Wed, 13 Apr 2011 23:34:17 -0400 Sender: curtis@occnc.com Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 03:34:20 -0000 In message Keyur Patel writes: > > Curtis, > > > On 4/13/11 12:28 PM, "Curtis Villamizar" wrote: > > > > > In message > > Randy Bush writes: > >> > >>> Getting a TLV protocol right is not rocket science. > >> > >> no, but understanding it seems to be > >> > >> fwiw, i do not have serious problems with the capability being > >> bi-directional. my co-authors may. > >> > >> randy > > > > > > What I meant by bi-directional is both sides have to be able and > > willing to receive extended-messages for either side to send them. > > That way an entire packet can always be sent in the reverse direction > > when indicating that something was wrong with it. > > If a BGP sending speaker sees a need to receive complete encapsulated > packet, it can always send original packet with size less than > 65K. You don't need capability to be *bi-directional*. There are cases > where asymmetric capability may be needed. And what are those cases? > Regards, > Keyur > > > > > Curtis From keyupate@cisco.com Wed Apr 13 20:44:44 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3C093E07E5 for ; Wed, 13 Apr 2011 20:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrsB0aJnbTH8 for ; Wed, 13 Apr 2011 20:44:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 62862E07E4 for ; Wed, 13 Apr 2011 20:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=1362; q=dns/txt; s=iport; t=1302752683; x=1303962283; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=n3+yFVGL2tVE19DXPNiZUqIuaPA2OpAoNZuBiAFHZbc=; b=MC78HpPMsCqKnQVRsu0UWrSSpu1Hw0MyBfKPnsWS3JIx0u1zfU9lP0dc JsVxKFqIj3ESiR+XLhYjEmogxk0p4F//CxgNyL3OTK1O5PQXvef2nPacM hIXgNmSiBiwGq7I0aS2/0CvOMqbo6heoSvrVNjfcPWNle6pQtLiYAuhFl 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowIAK5spk2rRDoH/2dsb2JhbACYcI00d4hvnBOdD4VuBIVaiA+Ddw X-IronPort-AV: E=Sophos;i="4.64,209,1301875200"; d="scan'208";a="680882550" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2011 03:44:42 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3E3igdn027324; Thu, 14 Apr 2011 03:44:42 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 20:44:42 -0700 Received: from 10.21.119.84 ([10.21.119.84]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Thu, 14 Apr 2011 03:44:42 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 13 Apr 2011 20:44:06 -0700 From: Keyur Patel To: Message-ID: Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv6VjQxcqM48mZJEeCGfQAbY71bnA== In-Reply-To: <201104140334.p3E3YHTA025359@harbor.orleans.occnc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Apr 2011 03:44:42.0623 (UTC) FILETIME=[4A0600F0:01CBFA56] Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 03:44:44 -0000 On 4/13/11 8:34 PM, "Curtis Villamizar" wrote: > > In message > Keyur Patel writes: >> >> Curtis, >> >> >> On 4/13/11 12:28 PM, "Curtis Villamizar" wrote: >> >>> >>> In message >>> Randy Bush writes: >>>> >>>>> Getting a TLV protocol right is not rocket science. >>>> >>>> no, but understanding it seems to be >>>> >>>> fwiw, i do not have serious problems with the capability being >>>> bi-directional. my co-authors may. >>>> >>>> randy >>> >>> >>> What I meant by bi-directional is both sides have to be able and >>> willing to receive extended-messages for either side to send them. >>> That way an entire packet can always be sent in the reverse direction >>> when indicating that something was wrong with it. >> >> If a BGP sending speaker sees a need to receive complete encapsulated >> packet, it can always send original packet with size less than >> 65K. You don't need capability to be *bi-directional*. There are cases >> where asymmetric capability may be needed. > > And what are those cases? SIDR requirement being the prime one. Any other applications that require BGP to send longer length messages. Regards, Keyur > >> Regards, >> Keyur >> >>> >>> Curtis From curtis@occnc.com Wed Apr 13 21:59:09 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E40A4E0818 for ; Wed, 13 Apr 2011 21:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03ex3UkRwLVO for ; Wed, 13 Apr 2011 21:59:09 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 07055E07FF for ; Wed, 13 Apr 2011 21:59:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3E4x6qr030769; Thu, 14 Apr 2011 00:59:06 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> To: Keyur Patel From: Curtis Villamizar In-reply-to: Your message of "Wed, 13 Apr 2011 20:44:06 PDT." Date: Thu, 14 Apr 2011 00:59:06 -0400 Sender: curtis@occnc.com Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 04:59:10 -0000 In message Keyur Patel writes: > > On 4/13/11 8:34 PM, "Curtis Villamizar" wrote: > > > > > In message > > Keyur Patel writes: > >> > >> Curtis, > >> > >> > >> On 4/13/11 12:28 PM, "Curtis Villamizar" wrote: > >> > >>> > >>> In message > >>> Randy Bush writes: > >>>> > >>>>> Getting a TLV protocol right is not rocket science. > >>>> > >>>> no, but understanding it seems to be > >>>> > >>>> fwiw, i do not have serious problems with the capability being > >>>> bi-directional. my co-authors may. > >>>> > >>>> randy > >>> > >>> > >>> What I meant by bi-directional is both sides have to be able and > >>> willing to receive extended-messages for either side to send them. > >>> That way an entire packet can always be sent in the reverse direction > >>> when indicating that something was wrong with it. > >> > >> If a BGP sending speaker sees a need to receive complete encapsulated > >> packet, it can always send original packet with size less than > >> 65K. You don't need capability to be *bi-directional*. There are cases > >> where asymmetric capability may be needed. > > > > And what are those cases? > > SIDR requirement being the prime one. Any other applications that require > BGP to send longer length messages. You still haven't indicated why any usage of BGP would need the long message capability to be uni-directional. Please explain why the other direction cannot send extended messages. > Regards, > Keyur > > > >> Regards, > >> Keyur > >> > >>> > >>> Curtis From randy@psg.com Wed Apr 13 22:05:55 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A4740E0815 for ; Wed, 13 Apr 2011 22:05:55 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avzBw1rr5A8I for ; Wed, 13 Apr 2011 22:05:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id BD2A6E07FF for ; Wed, 13 Apr 2011 22:05:47 -0700 (PDT) Received: from u722166.xgsnu3.imtp.tachikawa.mopera.net ([1.67.222.166]) by psg.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QAEkT-0000RK-K4; Thu, 14 Apr 2011 05:05:46 +0000 References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> User-Agent: K-9 Mail for Android In-Reply-To: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Randy Bush Date: Thu, 14 Apr 2011 14:04:54 +0900 To: Curtis Villamizar ,Keyur Patel Message-ID: <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:05:55 -0000 Allow simplex edge site bgpsec router not to need large receive buffers -- sent from android, so terse From raszuk@cisco.com Wed Apr 13 23:28:50 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B9AD5E0680 for ; Wed, 13 Apr 2011 23:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoDGwVIm40bX for ; Wed, 13 Apr 2011 23:28:49 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 93E9CE0670 for ; Wed, 13 Apr 2011 23:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=317; q=dns/txt; s=iport; t=1302762529; x=1303972129; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=+bEJKF3kt5r6VUChYm3OgPXJlsQmzKWaWJ1qGYzXRUM=; b=EQ1a8UV+MbaSq15q6GuiX2OTU1E1jo2O4nEKngm3IXVF4LPiysIPkVOH SOCzta5rwioYCldNik5W7SbkZH3Xo/+OPO//zpZzg40vwBCbrEApUdtV+ VCXE6kgj73pT5krJQzQlZWlAsT++0pcetCcR7to2EUtJK/a9zrESBjv7y I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQJABSTpk2rRDoI/2dsb2JhbACYcI0yd4hvmyuCcw4BmXKFbgSNb4Nz X-IronPort-AV: E=Sophos;i="4.64,209,1301875200"; d="scan'208";a="336918914" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2011 06:28:48 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3E6SlHT020284 for ; Thu, 14 Apr 2011 06:28:48 GMT Message-ID: <4DA69424.3080202@cisco.com> Date: Thu, 14 Apr 2011 08:28:52 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: idr@ietf.org References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> In-Reply-To: <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 06:28:50 -0000 > Allow simplex edge site bgpsec router not to need large receive buffers So the "simplex edge site bgpsec router" will be capable of sending large messages and not be able to receive them ? IMHO it is always a bad idea to maintain different defaults for routing protocols on a per platform basis. R. From cjeker@diehard.n-r-g.com Wed Apr 13 23:36:57 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 47038E07A3 for ; Wed, 13 Apr 2011 23:36:57 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2gxcjrWis-O for ; Wed, 13 Apr 2011 23:36:56 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by ietfc.amsl.com (Postfix) with ESMTP id 4208AE0687 for ; Wed, 13 Apr 2011 23:36:56 -0700 (PDT) Received: (qmail 13954 invoked by uid 1001); 14 Apr 2011 06:36:52 -0000 Date: Thu, 14 Apr 2011 08:36:52 +0200 From: Claudio Jeker To: idr@ietf.org Message-ID: <20110414063652.GK29933@diehard.n-r-g.com> References: <201104140334.p3E3YHTA025359@harbor.orleans.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 06:36:57 -0000 On Wed, Apr 13, 2011 at 08:44:06PM -0700, Keyur Patel wrote: > > > > On 4/13/11 8:34 PM, "Curtis Villamizar" wrote: > > > > > In message > > Keyur Patel writes: > >> > >> Curtis, > >> > >> > >> On 4/13/11 12:28 PM, "Curtis Villamizar" wrote: > >> > >>> > >>> In message > >>> Randy Bush writes: > >>>> > >>>>> Getting a TLV protocol right is not rocket science. > >>>> > >>>> no, but understanding it seems to be > >>>> > >>>> fwiw, i do not have serious problems with the capability being > >>>> bi-directional. my co-authors may. > >>>> > >>>> randy > >>> > >>> > >>> What I meant by bi-directional is both sides have to be able and > >>> willing to receive extended-messages for either side to send them. > >>> That way an entire packet can always be sent in the reverse direction > >>> when indicating that something was wrong with it. > >> > >> If a BGP sending speaker sees a need to receive complete encapsulated > >> packet, it can always send original packet with size less than > >> 65K. You don't need capability to be *bi-directional*. There are cases > >> where asymmetric capability may be needed. > > > > And what are those cases? > > SIDR requirement being the prime one. Any other applications that require > BGP to send longer length messages. > BGP MPLS VPN in some setups hit limits if the list of export-targets become huge. In the end a 4k message can only hold around 500 ext. communities. Now if this is a valid reason for larger messages is beyond me. Plus I'm waiting for the first person to prepend his AS 990 times :) -- :wq Claudio From heas@shrubbery.net Wed Apr 13 23:49:45 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15B77E0850 for ; Wed, 13 Apr 2011 23:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy8IJpgmcXkf for ; Wed, 13 Apr 2011 23:49:44 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfc.amsl.com (Postfix) with ESMTP id 84F65E0670 for ; Wed, 13 Apr 2011 23:49:44 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id D67C324B5E9; Thu, 14 Apr 2011 06:56:48 +0000 (UTC) Date: Thu, 14 Apr 2011 06:56:48 +0000 From: john heasley To: Robert Raszuk Message-ID: <20110414065648.GB8492@shrubbery.net> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA69424.3080202@cisco.com> 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.20 (2009-06-14) Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 06:49:45 -0000 Thu, Apr 14, 2011 at 08:28:52AM +0200, Robert Raszuk: > > >Allow simplex edge site bgpsec router not to need large receive buffers > > So the "simplex edge site bgpsec router" will be capable of sending > large messages and not be able to receive them ? yes, but if cares to receive "full errors", it restricts itself to the peer's limit. > IMHO it is always a bad idea to maintain different defaults for > routing protocols on a per platform basis. yes, this is silly. it appears to be engineering around limitations of a specific piece of hardware. From raszuk@cisco.com Thu Apr 14 00:12:57 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D5D8BE0839 for ; Thu, 14 Apr 2011 00:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQIsNhOEYDYp for ; Thu, 14 Apr 2011 00:12:57 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 05644E0675 for ; Thu, 14 Apr 2011 00:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1261; q=dns/txt; s=iport; t=1302765177; x=1303974777; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BA84HXeWNXoG5UDuDQrgK/Zz95OuAyHgBUBUcX11onM=; b=BjlfznRG0DIUsF73z1wU/RduBuk4PjKuZ0p81ATZqjxNdbp18SnmHhss cwHm2v6Ccf/jfnmOyXXtKiGTZc8lWCVuFhsvqV98I/tXbS2qDroilaKIO ZRkeb7eBJuGZ7bBv6z+hLRLfE65hrBWb7Q5EBCdwgigau5fKzNvwsjeqq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALCdpk2rRDoH/2dsb2JhbACmIneIb5segnMOAZl3hW4EjW+Dcw X-IronPort-AV: E=Sophos;i="4.64,209,1301875200"; d="scan'208";a="336947324" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2011 07:12:56 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3E7CtWi026395; Thu, 14 Apr 2011 07:12:55 GMT Message-ID: <4DA69E7C.5040205@cisco.com> Date: Thu, 14 Apr 2011 09:13:00 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: john heasley References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> In-Reply-To: <20110414065648.GB8492@shrubbery.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 07:12:58 -0000 Hi John, >>> Allow simplex edge site bgpsec router not to need large receive buffers >> >> So the "simplex edge site bgpsec router" will be capable of sending >> large messages and not be able to receive them ? > > yes, but if cares to receive "full errors", it restricts itself to the > peer's limit. Let's put the "full errors" case aside. The assumed topology here is: simplex edge CE ----- ebgp ----- PE of ISP So CE can send messages > 4K and can not receive such from PE. My question was what would be in this simplex CE generated BGP message to require it to be > 4K ? This seems to be a reason to keep asymmetry in place which just like Curtis I am trying to better understand. >> IMHO it is always a bad idea to maintain different defaults for >> routing protocols on a per platform basis. > > yes, this is silly. it appears to be engineering around limitations of a > specific piece of hardware. As a matter of fact those are imaginary limitations to start with. I am yet to see a platform which can run BGP and which would have any issue to transiently handle 65K vs 4K messages. RP receive buffers are carved out of RP DRAM and those today are measured in gigabytes for BGP systems. Cheers, R. From randy@psg.com Thu Apr 14 01:14:55 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6FCA0E0732 for ; Thu, 14 Apr 2011 01:14:55 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFBAl70pic9c for ; Thu, 14 Apr 2011 01:14:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id DFED4E0694 for ; Thu, 14 Apr 2011 01:14:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAHhU-000DAk-OK; Thu, 14 Apr 2011 08:14:53 +0000 Date: Thu, 14 Apr 2011 17:15:07 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4DA69424.3080202@cisco.com> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 08:14:55 -0000 >> Allow simplex edge site bgpsec router not to need large receive >> buffers > So the "simplex edge site bgpsec router" will be capable of sending > large messages and not be able to receive them ? yep. which is why it is referred to as a simplex relationship > IMHO it is always a bad idea to maintain different defaults for > routing protocols on a per platform basis. who said per-platform? randy From randy@psg.com Thu Apr 14 01:16:26 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 31A09E07F0 for ; Thu, 14 Apr 2011 01:16:26 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXwHQm6KzPB0 for ; Thu, 14 Apr 2011 01:16:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id B0560E0694 for ; Thu, 14 Apr 2011 01:16:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAHiy-000DBJ-EG; Thu, 14 Apr 2011 08:16:25 +0000 Date: Thu, 14 Apr 2011 17:16:38 +0900 Message-ID: From: Randy Bush To: john heasley In-Reply-To: <20110414065648.GB8492@shrubbery.net> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 08:16:26 -0000 >> IMHO it is always a bad idea to maintain different defaults for >> routing protocols on a per platform basis. > > yes, this is silly. it appears to be engineering around limitations > of a specific piece of hardware. no. it is telling the edge site, your paying customer, that they can secure their prefix without upgrading hardware. randy From randy@psg.com Thu Apr 14 01:17:43 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7433E0874 for ; Thu, 14 Apr 2011 01:17:43 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA65qbVsZiKn for ; Thu, 14 Apr 2011 01:17:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 9377EE07F0 for ; Thu, 14 Apr 2011 01:17:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAHkD-000DBl-9Q; Thu, 14 Apr 2011 08:17:42 +0000 Date: Thu, 14 Apr 2011 17:17:56 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4DA69E7C.5040205@cisco.com> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA69E7C.5040205@cisco.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 08:17:43 -0000 > RP receive buffers are carved out of RP DRAM and those today are > measured in gigabytes for BGP systems. perhaps you should look into what the edge enterprises have bought from your company. randy From cjeker@diehard.n-r-g.com Thu Apr 14 01:37:03 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7C40AE0879 for ; Thu, 14 Apr 2011 01:37:03 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcTKOf6ceoeI for ; Thu, 14 Apr 2011 01:37:02 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by ietfc.amsl.com (Postfix) with ESMTP id 97226E0747 for ; Thu, 14 Apr 2011 01:37:02 -0700 (PDT) Received: (qmail 24741 invoked by uid 1001); 14 Apr 2011 08:37:00 -0000 Date: Thu, 14 Apr 2011 10:37:00 +0200 From: Claudio Jeker To: Randy Bush Message-ID: <20110414083700.GA3014@diehard.n-r-g.com> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA69E7C.5040205@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Robert Raszuk , idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 08:37:03 -0000 On Thu, Apr 14, 2011 at 05:17:56PM +0900, Randy Bush wrote: > > RP receive buffers are carved out of RP DRAM and those today are > > measured in gigabytes for BGP systems. > > perhaps you should look into what the edge enterprises have bought from > your company. > If they run BGP on the edge and don't have even 1M of memory left to handle 10 65k buffers then they should reconsider their HW decision. Sorry but a BGP router with so little free memory where using bigger receive and send buffer causes memory starvation will not survive the winter and most probably not even the next few weeks. If edge customers want to secure their prefix they need to update the route OS and with that they can get fat BGP messages for free. I see no reason to make something that could be so simple complex just for the heck of it. -- :wq Claudio From randy@psg.com Thu Apr 14 01:48:29 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7021AE067E for ; Thu, 14 Apr 2011 01:48:29 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5FajGkRN4yC for ; Thu, 14 Apr 2011 01:48:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id D69DFE066A for ; Thu, 14 Apr 2011 01:48:28 -0700 (PDT) Received: from u722166.xgsnu3.imtp.tachikawa.mopera.net ([1.67.222.166]) by psg.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QAIDy-0009pw-5A; Thu, 14 Apr 2011 08:48:27 +0000 References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA69E7C.5040205@cisco.com> <20110414083700.GA3014@diehard.n-r-g.com> User-Agent: K-9 Mail for Android In-Reply-To: <20110414083700.GA3014@diehard.n-r-g.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Randy Bush Date: Thu, 14 Apr 2011 17:47:35 +0900 To: Claudio Jeker Message-ID: Cc: Robert Raszuk , idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 08:48:29 -0000 Claudio Jeker wrote: >On Thu, Apr 14, 2011 at 05:17:56PM +0900, Randy Bush wrote: >> > RP receive buffers are carved out of RP DRAM and those today are >> > measured in gigabytes for BGP systems. >> >> perhaps you should look into what the edge enterprises have bought >from >> your company. >> > >If they run BGP on the edge and don't have even 1M of memory left to >handle 10 65k buffers then they should reconsider their HW decision. >Sorry but a BGP router with so little free memory where using bigger >receive and send buffer causes memory starvation will not survive the >winter and most probably not even the next few weeks. > >If edge customers want to secure their prefix they need to update the >route OS and with that they can get fat BGP messages for free. I see no >reason to make something that could be so simple complex just for the >heck >of it. > >-- >:wq Claudio As I said, I am not strongly against symmetric. I am trying to explain one place where it would be useful. As an operator, I do not like to tell the customer they need to buy more hardware to use my service. Money goes to wrong place :) -- sent from android, so terse From xuxh@huawei.com Thu Apr 14 02:57:02 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 88927E06A5 for ; Thu, 14 Apr 2011 02:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skxumsth0epo for ; Thu, 14 Apr 2011 02:57:01 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 72BCBE06A0 for ; Thu, 14 Apr 2011 02:57:01 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM00C9QZMAI8@szxga05-in.huawei.com> for idr@ietf.org; Thu, 14 Apr 2011 17:56:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM00NR4ZM93M@szxga05-in.huawei.com> for idr@ietf.org; Thu, 14 Apr 2011 17:56:34 +0800 (CST) Received: from x41208c ([10.110.98.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJM004I0ZM9ZV@szxml04-in.huawei.com> for idr@ietf.org; Thu, 14 Apr 2011 17:56:33 +0800 (CST) Date: Thu, 14 Apr 2011 18:05:04 +0800 From: Xu Xiaohu To: idr@ietf.org Message-id: <004801cbfa8b$6d3f6360$60626e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acv1pDybf4GWxtrWRK2CBTxtUvJ4XwE5vGWg Subject: [Idr] fwd: About loop avoidance when using BGP best external X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 09:57:02 -0000 Hi all, Sorry, I mistakenly sent this email to L2VPN. It should be here. Best wishes, Xiaohu -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Xu Xiaohu [mailto:xuxh@huawei.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C28=C8=D5 12:20 =CA=D5=BC=FE=C8=CB: 'raszuk@cisco.com' =B3=AD=CB=CD: 'l2vpn@ietf.org' =D6=F7=CC=E2: About loop avoidance when using BGP best external -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of=20 > Robert Raszuk > Sent: Sunday, April 03, 2011 2:26 AM > To: Jakob Heitz > Cc: idr > Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does=20 > PE revert back to standard label? >=20 > Hi Jakob, >=20 > > I think the draft needs to state that a received native IP packet is = > > NEVER sent using the repair label. Specifically, if the IP path to=20 > > the CE is broken, a packet received as a native IP packet shoul be=20 > > sent to the PE next hop using the regular label, not the repair=20 > > label. The repair label should only be used for packets received=20 > > from MPLS. >=20 > The draft already states this: >=20 > In a BGP free core, where traffic is tunneled between edge routers > and edge routers assign labels to prefixes, BGP speakers advertise > reachability information about prefixes and associate a local = label > with each prefix such as L3VPN [9], 6PE [10], and Softwire [8]. >=20 > But thinking further I do not see perhaps anything wrong on attaching=20 > this attribute to unicast IPv4 and IPv6 AFIs where ASBRs and network=20 > between them are MPLS enabled. >=20 > In fact if we would explicitly permit this in=20 > draft-bashandy-idr-bgp-repair-label it will automatically address the=20 > problem as described in draft-xu-idr-best-external-loop-avoidance. Hi Robert, Sorry that I just notice this email mentioning my draft (draft-xu-idr-best-external-loop-avoidance). IMO, the repair-label draft (draft-bashandy-idr-bgp-repair-label) and my draft have many differences as listed below (here I just refer the L3VPN = CE multi-homing scenario): 1. Different target scenarios: The repair-label draft targets the scenario where the best route for the local CE site on each multi-homing PE router is pointed to the CE = router, while my draft targets the scenario of best external. =20 2. Different achievements: The repair-label draft only solves the problem of transient loop in case = the CE router is down (anyway, the CE destination is unreachable at this = time). While my draft not only solves the transient loop problem, but also = speeds up the convergence in case the best external route is still available.=20 3. Different approaches: The repair-label draft requires some changes to the BGP protocol while = my draft doesn=A1=AFt require any change to the BGP protocol. =A1=A1=A1=A1 Best wishes, Xiaohu =A1=A1=A1=A1 > Thx, > R. >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Thu Apr 14 04:13:21 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AEF55E06C1; Thu, 14 Apr 2011 04:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0O9FaImVt24; Thu, 14 Apr 2011 04:13:21 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id CE551E0670; Thu, 14 Apr 2011 04:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=814; q=dns/txt; s=iport; t=1302779600; x=1303989200; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/SX7B5+Hzp2lNe+kP5Kb8s+TIuvKgLPgqFxE0I6/B/c=; b=djE6Rf6VQAVTNbLrYcb4rRiYtJINIds/wlEYrKc5tFnfy0/37fqzHr3V OsluiB2BcM3QhQfb+f8bYiiM3IFBTFu/AXoMuvI5bTSBIOoLtSodX1QE6 EEZEHOGoqg7rCQRhKM49wX2XUoKuA6x2o+bbCJfZyIShJLITEO6hVym2G 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloKAGrWpk2rRDoI/2dsb2JhbAClaXeBBh6HS5wKgnMOAZl0hW4EjW+Dcw X-IronPort-AV: E=Sophos;i="4.64,210,1301875200"; d="scan'208";a="681114379" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2011 11:13:20 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3EBDIjT002837; Thu, 14 Apr 2011 11:13:19 GMT Message-ID: <4DA6D6C8.2040304@cisco.com> Date: Thu, 14 Apr 2011 13:13:12 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: idr@ietf.org, sidr@ietf.org References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: john heasley Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 11:13:21 -0000 > no. it is telling the edge site, your paying customer, that they can > secure their prefix without upgrading hardware. Can anyone in IDR or SIDR demystify for us here what securing BGP really requires (certificates, signatures, attestations you name it) if to secure a single prefix originated by customer site requires more then 4K of BGP message size ? We already know that update packing is gone and that there is going to be single NLRI per update. OK or NOK but a different debate for different time. But if securing 1 prefix really requires more then 4K of data attached to it I think we should question the entire approach rather then waist time to argue about draft-ymbk-bgp-extended-messages. Well unless this secure BGP is the only reason for this draft ;-). Thx, R. From raszuk@cisco.com Thu Apr 14 05:07:38 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BD858E0713 for ; Thu, 14 Apr 2011 05:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0xupXd-PFAn for ; Thu, 14 Apr 2011 05:07:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 195ABE06E6 for ; Thu, 14 Apr 2011 05:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=944; q=dns/txt; s=iport; t=1302782858; x=1303992458; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VNIrfEuO1v+q39ZCoMWfrQJ10v0qXydRD6QhquuGDhk=; b=baUg7mDixKPN642p6bQScCyvhqvq/X4ofHLAmqTt8hh7DHaMA2tbU3YC VY2MeF/SwPgfAlPkuU/1cVG32T0MAOPbZVGlNh8YjvSnft+Qu5xkdZaxM mm0KtghEUw9mZvvdsI1gGQbvuTgsB6b8AE37Z3mLP+G1ydQrSWK7SAKbE o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAXjpk2rRDoG/2dsb2JhbACldXeIb5t2gnMOAZl1hW4EjW+Dcw X-IronPort-AV: E=Sophos;i="4.64,211,1301875200"; d="scan'208";a="429814468" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 14 Apr 2011 12:07:37 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3EC7a4I027868; Thu, 14 Apr 2011 12:07:36 GMT Message-ID: <4DA6E382.3030807@cisco.com> Date: Thu, 14 Apr 2011 14:07:30 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Randy Bush References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA69E7C.5040205@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:07:38 -0000 I would not reply if I wouldn't verify first. And all routers even those which have no BGP support do support RFC1323. That means that their receive buffers not only support 65,535 bytes messages, but with described in this RFC new TCP option the max message size can be increased to 1,073,741,823 bytes If you want to read more or see a list of platforms please google for "tcpwslfn.html" Example from little 1801 in my home office: SIMPLEX_EDGE(config)#ip tcp window-size ? <68-1073741823> Window size Conclusion: Edge enterprises do not need to purchase any new hardware to support draft-ymbk-bgp-extended-messages if only new software will be available for their platform. R. >> RP receive buffers are carved out of RP DRAM and those today are >> measured in gigabytes for BGP systems. > > perhaps you should look into what the edge enterprises have bought from > your company. > > randy > From keyupate@cisco.com Thu Apr 14 07:24:24 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 07467E089C for ; Thu, 14 Apr 2011 07:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.253 X-Spam-Level: X-Spam-Status: No, score=-10.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDcKDp4dfZlc for ; Thu, 14 Apr 2011 07:24:23 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 16DC5E070B for ; Thu, 14 Apr 2011 07:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=1507; q=dns/txt; s=iport; t=1302791063; x=1304000663; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=euoB+AtvMl91WKI763TFw6PLpzowv0QVwL+LKl5wxTI=; b=kM/vDFKWkgROpPnwRVgSN5aQ1vjrqb7jieyrtWcGRBer6kQEiwT8c20+ ZSrrSOuOFSpnMy1ZrTzWjPluM0W0HUFEODkGdgN8J5Ex6+PLzMentqWNv nBuqsvzQHpCEq/cCn3l/FTt+Wyz7nTbTryt16WP3hlOfCfjiIGTkb3Hd+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYHAGQCp02rRDoG/2dsb2JhbACYOY09d6UBnQGFbgSFWogVg3o X-IronPort-AV: E=Sophos;i="4.64,211,1301875200"; d="scan'208";a="337288176" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2011 14:24:22 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3EEOLD3005027; Thu, 14 Apr 2011 14:24:22 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 07:24:22 -0700 Received: from 10.21.91.242 ([10.21.91.242]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 14 Apr 2011 14:24:21 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 14 Apr 2011 07:23:45 -0700 From: Keyur Patel To: Message-ID: Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv6r4/czpawpGaiEeCGfQAbY71bnA== In-Reply-To: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Apr 2011 14:24:22.0227 (UTC) FILETIME=[A60CD230:01CBFAAF] Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:24:24 -0000 Curtis, >>>>> >>>>> What I meant by bi-directional is both sides have to be able and >>>>> willing to receive extended-messages for either side to send them. >>>>> That way an entire packet can always be sent in the reverse direction >>>>> when indicating that something was wrong with it. >>>> >>>> If a BGP sending speaker sees a need to receive complete encapsulated >>>> packet, it can always send original packet with size less than >>>> 65K. You don't need capability to be *bi-directional*. There are cases >>>> where asymmetric capability may be needed. >>> >>> And what are those cases? >> >> SIDR requirement being the prime one. Any other applications that require >> BGP to send longer length messages. > > You still haven't indicated why any usage of BGP would need the long > message capability to be uni-directional. > > Please explain why the other direction cannot send extended messages. Typically, most implementations terminate BGP sessions upon *receiving* messages longer than current 4096 octets. This is a receiving side behavior (Sending side speaker would automatically build another message beyond 4096 octets). The draft aims to relax this part and hence the capability being asymmetric (specifically targeting the receiving side behavior). Its not that other direction "cannot send extended messages". Its more like other direction does NOT need to enable this capability unless required. Hope that clarifies. Regards, Keyur From shane@castlepoint.net Thu Apr 14 08:13:02 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 62330E0737 for ; Thu, 14 Apr 2011 08:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Fl-OC1kjelc for ; Thu, 14 Apr 2011 08:13:01 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfc.amsl.com (Postfix) with ESMTP id 73E38E06D7 for ; Thu, 14 Apr 2011 08:13:01 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id AB6F5268037; Thu, 14 Apr 2011 09:13:00 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for idr@ietf.org; Thu, 14 Apr 2011 09:13:00 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=59217; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Shane Amante In-Reply-To: <1C015943-E564-4E39-B30F-D4060EB40D9E@ericsson.com> Date: Thu, 14 Apr 2011 09:12:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D94823E.9070806@cisco.com> <1C015943-E564-4E39-B30F-D4060EB40D9E@ericsson.com> To: idr@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [Idr] Dissemination of Flow Specification Rules for IPv6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:13:02 -0000 +1 -shane On Mar 31, 2011, at 7:35 AM, Jeff Tantsura wrote: > +1 >=20 > Regards, > Jeff >=20 > On Mar 31, 2011, at 15:32, "Robert Raszuk" wrote: >=20 >>=20 >> Authors of "Dissemination of Flow Specification Rules for IPv6" draft=20= >> document would like to propose the adoption of this work as the IDR = WG item. >>=20 >> Ref: >> http://tools.ietf.org/html/draft-raszuk-idr-flow-spec-v6-01 >>=20 >> Rgs, >> R. Raszuk >> B. Pithawala >> D. McPherson >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From keyupate@cisco.com Thu Apr 14 09:15:03 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D1B3BE07DD for ; Thu, 14 Apr 2011 09:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.31 X-Spam-Level: X-Spam-Status: No, score=-10.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0PJYzUC96kf for ; Thu, 14 Apr 2011 09:15:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 1BDC7E07B5 for ; Thu, 14 Apr 2011 09:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=590; q=dns/txt; s=iport; t=1302797702; x=1304007302; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=bW8xThuDCrK6NPifuUTclw4BQf54sxIypBSFgczR3VA=; b=e9nfXKY3zpfKVgCRd+vXVGyLb1GyPqWLBnQRqRY/V0e/L2s93tEo0Su1 uFMm2YpL/g8FiPt0iTkeDN8URsrmdhAenT8DKh5iazPMQsD+2yQdePxG3 qdzbiiByKNDNVo3Hffw8IvEQDw1dAeJko0FJ2PmB8lgde/R/5JjjsKcFW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALkcp02rRDoG/2dsb2JhbACldneIb5tPnQOFbgSFWogVg3o X-IronPort-AV: E=Sophos;i="4.64,212,1301875200"; d="scan'208";a="681404507" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2011 16:15:01 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3EGF1aI028992; Thu, 14 Apr 2011 16:15:01 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 09:15:01 -0700 Received: from 10.33.12.64 ([10.33.12.64]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Thu, 14 Apr 2011 16:15:00 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 14 Apr 2011 09:14:26 -0700 From: Keyur Patel To: Jie Dong , "idr@ietf.org" Message-ID: Thread-Topic: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" Thread-Index: AQHL77veohlgKlPj5Eu+rRghEYxDvZRdnpQL In-Reply-To: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Apr 2011 16:15:01.0502 (UTC) FILETIME=[1B5DC9E0:01CBFABF] Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:15:04 -0000 Support. Keyur On 3/31/11 8:54 AM, "Jie Dong" wrote: > Dear all, > > Authors of "IPv6 AF Extensions for Route Target Distribution" would like to > propose to adopt this draft as IDR WG document. > > The draft could be found at: > http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01 > > > Best regards, > Keyur Patel > Robert Raszuk > Martine Djernaes > Jie Dong > Mach Chen > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From bvenkata@cisco.com Thu Apr 14 09:26:51 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 30829E08CD for ; Thu, 14 Apr 2011 09:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTFrQjyI84Fj for ; Thu, 14 Apr 2011 09:26:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 640DAE08CA for ; Thu, 14 Apr 2011 09:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bvenkata@cisco.com; l=735; q=dns/txt; s=iport; t=1302798410; x=1304008010; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ZwLLT6ccFsL+AHuPPdqZbnCxSDbVhHbTu7oT2psLqQs=; b=HQUZv6rztAUvB/+Eje1WzdqrNMzU61BAj3C+b1KdKssiX6Zj7V2cnA7y fHytNmyxhRqbbT1B1cku56nz3LG39sr3FuIQzYYhl68IOLaJhD5vaPNdv JpFLqqUHvOZLdoLQuk2e1QLzClK3PACUghKsNZlRG8n4O3PI0iGEZ1sAc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAAEgp02Q/khRgWdsb2JhbACXeY19FAEBFiYlpEKcf4VuBIVYjBE X-IronPort-AV: E=Sophos;i="4.64,212,1301875200"; d="scan'208";a="83611982" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2011 16:26:47 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3EGQga3022226; Thu, 14 Apr 2011 16:26:47 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 21:55:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2011 21:55:52 +0530 Message-ID: In-Reply-To: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] WG adoption of "IPv6 AF Extensions for Route TargetDistribution" Thread-Index: AQHL77veohlgKlPj5Eu+rRghEYxDvZRdoZ+g References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> From: "Balaji Pitta Venkatachalapathy (bvenkata)" To: "Jie Dong" , X-OriginalArrivalTime: 14 Apr 2011 16:25:54.0993 (UTC) FILETIME=[A0E09A10:01CBFAC0] Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route TargetDistribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:26:51 -0000 support Balaji -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jie Dong Sent: Thursday, March 31, 2011 8:54 AM To: idr@ietf.org Subject: [Idr] WG adoption of "IPv6 AF Extensions for Route TargetDistribution" Dear all,=20 Authors of "IPv6 AF Extensions for Route Target Distribution" would like to propose to adopt this draft as IDR WG document. The draft could be found at:=20 http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01 Best regards, Keyur Patel Robert Raszuk Martine Djernaes Jie Dong Mach Chen _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From danny@tcb.net Thu Apr 14 11:16:41 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EDBE1E0823 for ; Thu, 14 Apr 2011 11:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.448 X-Spam-Level: X-Spam-Status: No, score=-110.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx4ExD5PuXZS for ; Thu, 14 Apr 2011 11:16:41 -0700 (PDT) Received: from farnsworth.verisignlabs.com (farnsworth.verisignlabs.com [72.13.58.64]) by ietfc.amsl.com (Postfix) with ESMTP id 7D069E080D for ; Thu, 14 Apr 2011 11:16:41 -0700 (PDT) Received: from monsoon.verisignlabs.com (h87.s239.verisign.com [216.168.239.87]) by farnsworth.verisignlabs.com (Postfix) with ESMTP id 608CC90B2 for ; Thu, 14 Apr 2011 18:16:41 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (unknown [10.131.210.13]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 433F32420BA for ; Thu, 14 Apr 2011 14:16:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Danny McPherson In-Reply-To: Date: Thu, 14 Apr 2011 14:16:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66B56F3C-85DD-46E5-A344-E929F13FC454@tcb.net> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> To: "idr@ietf.org List" X-Mailer: Apple Mail (2.1084) Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 18:16:42 -0000 On Apr 14, 2011, at 4:16 AM, Randy Bush wrote: >=20 > no. it is telling the edge site, your paying customer, that they can > secure their prefix without upgrading hardware. Hrmmm... Can someone explain to me what an "edge site" is in the=20 context of BGP and protocol interactions,? danny@pork% grep -i "edge" rfc4271.txt=20 2. Acknowledgements ................................................6 2. Acknowledgements We would like to specially acknowledge numerous contributions by We would like to specially acknowledge Andrew Lange for his help in acknowledgement, and sequencing. BGP listens on TCP port 179. The because once an IP packet arrives at the edge of a group of Acknowledgement And for those not paying attention, the new SIDR Charter essentially = gives them the authority to "enhance" BGP, so long as it's co-WG last = called in IDR (even though the new charter doesn't even provide that = guidance). So if you're not subscribed (and care).... -danny From seyilmaz@cisco.com Thu Apr 14 11:34:27 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 30DF6E0900 for ; Thu, 14 Apr 2011 11:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9C2P+PqjElF for ; Thu, 14 Apr 2011 11:34:26 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 6EEBEE08AC for ; Thu, 14 Apr 2011 11:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=seyilmaz@cisco.com; l=741; q=dns/txt; s=iport; t=1302806066; x=1304015666; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Bul/alXrIwAhNoPJ44/3CKpEGA8MHpUAA4TdgVT0oMc=; b=M2ecS+rCF4FkUhhRPjJ/ECe9ZoLZsMi7RnxmQGYAeTOBGfMZg/hwpHcK BmPi5Y1h/JeZMoPsNIca1Xh7b/j5f/aE8/tBn2tatM1Mb5g9/WFabyaYl m0NcgBJpehYRejDVnMrMUdxi0agIABxPNzPev/8Mv0b/6baWcXV9VeI5R U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAE9p02rRDoI/2dsb2JhbACleXeIb5wenH+FbgSFWowP X-IronPort-AV: E=Sophos;i="4.64,212,1301875200"; d="scan'208";a="337545022" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2011 18:34:24 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3EIYOlR012723; Thu, 14 Apr 2011 18:34:24 GMT Received: from xmb-sjc-232.amer.cisco.com ([128.107.191.41]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 11:34:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2011 11:34:21 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" Thread-Index: AQHL77veohlgKlPj5Eu+rRghEYxDvZRdnpQLgAAm4iA= References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> From: "Selma Yilmaz (seyilmaz)" To: "Jie Dong" , X-OriginalArrivalTime: 14 Apr 2011 18:34:24.0667 (UTC) FILETIME=[94337EB0:01CBFAD2] Subject: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 18:34:27 -0000 Support Selma Yilmaz On 3/31/11 8:54 AM, "Jie Dong" wrote: > Dear all,=20 >=20 > Authors of "IPv6 AF Extensions for Route Target Distribution" would like to > propose to adopt this draft as IDR WG document. >=20 > The draft could be found at: > http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01 >=20 >=20 > Best regards, > Keyur Patel > Robert Raszuk > Martine Djernaes > Jie Dong > Mach Chen >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Thu Apr 14 17:58:59 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4EE49E06BC for ; Thu, 14 Apr 2011 17:58:59 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xHQI4Zf-H4s for ; Thu, 14 Apr 2011 17:58:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id BBCB5E065C for ; Thu, 14 Apr 2011 17:58:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAXJt-00084K-3W for idr@ietf.org; Fri, 15 Apr 2011 00:55:33 +0000 Date: Fri, 15 Apr 2011 09:59:15 +0900 Message-ID: From: Randy Bush To: idr@ietf.org References: <20110415005809.E1BBBE06BC@ietfc.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 00:58:59 -0000 A new version of I-D, draft-ymbk-bgp-extended-messages-02.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Filename: draft-ymbk-bgp-extended-messages Revision: 02 Title: Extended Message support for BGP Creation_date: 2011-04-15 WG ID: Independent Submission Number_of_pages: 5 Abstract: The current 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 draft provides an extension for BGP to extend its current message size for BGP messages from 4096 octets to 65535 octets. The IETF Secretariat. From xuxh@huawei.com Thu Apr 14 18:42:09 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70A32E0715 for ; Thu, 14 Apr 2011 18:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.905 X-Spam-Level: X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[AWL=1.695, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKRv7DewuSfa for ; Thu, 14 Apr 2011 18:42:08 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 2FBABE077F for ; Thu, 14 Apr 2011 18:41:53 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO006U87DQTH@szxga05-in.huawei.com> for idr@ietf.org; Fri, 15 Apr 2011 09:41:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO00DUR7DQTS@szxga05-in.huawei.com> for idr@ietf.org; Fri, 15 Apr 2011 09:41:50 +0800 (CST) Received: from x41208c ([10.110.98.96]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJO0004W7DPL4@szxml06-in.huawei.com> for idr@ietf.org; Fri, 15 Apr 2011 09:41:50 +0800 (CST) Date: Fri, 15 Apr 2011 09:50:21 +0800 From: Xu Xiaohu In-reply-to: To: 'Jie Dong' , idr@ietf.org Message-id: <000f01cbfb0f$7b2fc300$60626e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AQHL77veohlgKlPj5Eu+rRghEYxDvZRdnpQLgACgrLA= Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 01:42:09 -0000 Support. Xiaohu > On 3/31/11 8:54 AM, "Jie Dong" wrote: > > > Dear all, > > > > Authors of "IPv6 AF Extensions for Route Target Distribution" would like to > > propose to adopt this draft as IDR WG document. > > > > The draft could be found at: > > http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01 > > > > > > Best regards, > > Keyur Patel > > Robert Raszuk > > Martine Djernaes > > Jie Dong > > Mach Chen > > > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From mach.chen@huawei.com Thu Apr 14 20:04:45 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 519CBE07E2 for ; Thu, 14 Apr 2011 20:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.323 X-Spam-Level: X-Spam-Status: No, score=-6.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfIV2mjCE8xP for ; Thu, 14 Apr 2011 20:04:44 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 8CC0CE07BD for ; Thu, 14 Apr 2011 20:04:44 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO00F21B5QSV@szxga04-in.huawei.com> for idr@ietf.org; Fri, 15 Apr 2011 11:03:26 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJO00EEXB5QHR@szxga04-in.huawei.com> for idr@ietf.org; Fri, 15 Apr 2011 11:03:26 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Apr 2011 11:03:11 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.205]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 15 Apr 2011 11:03:21 +0800 Date: Fri, 15 Apr 2011 03:02:59 +0000 From: Mach Chen In-reply-to: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> X-Originating-IP: [10.110.98.37] To: Jie Dong , "idr@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" Thread-index: AQHL77veohlgKlPj5Eu+rRghEYxDvZReU7vQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 03:04:45 -0000 Support! Best regards, Mach > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jie > Dong > Sent: Thursday, March 31, 2011 11:54 PM > To: idr@ietf.org > Subject: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" > > Dear all, > > Authors of "IPv6 AF Extensions for Route Target Distribution" would like to > propose to adopt this draft as IDR WG document. > > The draft could be found at: > http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01 > > > Best regards, > Keyur Patel > Robert Raszuk > Martine Djernaes > Jie Dong > Mach Chen > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Thu Apr 14 20:42:58 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 24FC8E06A6 for ; Thu, 14 Apr 2011 20:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.263 X-Spam-Level: X-Spam-Status: No, score=-5.263 tagged_above=-999 required=5 tests=[AWL=1.336, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtTxjY0hyUrv for ; Thu, 14 Apr 2011 20:42:57 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 8831FE0677 for ; Thu, 14 Apr 2011 20:42:57 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3F3gubo001836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Apr 2011 22:42:56 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 14 Apr 2011 23:42:55 -0400 From: Jakob Heitz To: "idr@ietf.org" Date: Thu, 14 Apr 2011 23:42:53 -0400 Thread-Topic: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" Thread-Index: AQHL77veohlgKlPj5Eu+rRghEYxDvZReXtKg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F87BBF4@EUSAACMS0701.eamcs.ericsson.se> References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 03:42:58 -0000 support -- Jakob Heitz. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Jie Dong > Sent: Thursday, March 31, 2011 8:54 AM > To: idr@ietf.org > Subject: [Idr] WG adoption of "IPv6 AF Extensions for Route=20 > Target Distribution" >=20 > Dear all,=20 >=20 > Authors of "IPv6 AF Extensions for Route Target Distribution"=20 > would like to propose to adopt this draft as IDR WG document. >=20 > The draft could be found at:=20 > http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01 >=20 >=20 > Best regards, > Keyur Patel > Robert Raszuk > Martine Djernaes > Jie Dong > Mach Chen >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From heas@shrubbery.net Thu Apr 14 22:42:58 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 335C9E0715 for ; Thu, 14 Apr 2011 22:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhy1XqBrcCPN for ; Thu, 14 Apr 2011 22:42:57 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E570E065C for ; Thu, 14 Apr 2011 22:42:47 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id CD02D24B5E9; Fri, 15 Apr 2011 05:50:00 +0000 (UTC) Date: Fri, 15 Apr 2011 05:50:00 +0000 From: john heasley To: Randy Bush Message-ID: <20110415055000.GK2749@shrubbery.net> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.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.20 (2009-06-14) Cc: Robert Raszuk , idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 05:42:58 -0000 Thu, Apr 14, 2011 at 05:15:07PM +0900, Randy Bush: > > IMHO it is always a bad idea to maintain different defaults for > > routing protocols on a per platform basis. > > who said per-platform? i believe he is implying that a platform [limitation] is the most likely reason for the non-congruent message size capability. besides a major design flaw, why would any bgp speaker not be capable of handling a 65k msg? From randy@psg.com Thu Apr 14 23:03:37 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26C37E065C for ; Thu, 14 Apr 2011 23:03:37 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMf8nAfI5-qD for ; Thu, 14 Apr 2011 23:03:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id A955DE06FC for ; Thu, 14 Apr 2011 23:03:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAc4f-00093H-Km; Fri, 15 Apr 2011 06:00:10 +0000 Date: Fri, 15 Apr 2011 15:03:52 +0900 Message-ID: From: Randy Bush To: john heasley In-Reply-To: <20110415055000.GK2749@shrubbery.net> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110415055000.GK2749@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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Robert Raszuk , idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 06:03:37 -0000 > besides a major design flaw, why would any bgp speaker not be capable > of handling a 65k msg? when ram is one of the most frequent causes of having to spend more money to upgrade routers, i tend toward conservative. randy From cjeker@diehard.n-r-g.com Fri Apr 15 00:24:39 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 29099E0686 for ; Fri, 15 Apr 2011 00:24: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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FLdSB6Zcovl for ; Fri, 15 Apr 2011 00:24:38 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by ietfc.amsl.com (Postfix) with ESMTP id 6990DE0693 for ; Fri, 15 Apr 2011 00:24:38 -0700 (PDT) Received: (qmail 32359 invoked by uid 1001); 15 Apr 2011 07:24:33 -0000 Date: Fri, 15 Apr 2011 09:24:33 +0200 From: Claudio Jeker To: idr@ietf.org Message-ID: <20110415072433.GG3014@diehard.n-r-g.com> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110415055000.GK2749@shrubbery.net> 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) Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:24:39 -0000 On Fri, Apr 15, 2011 at 03:03:52PM +0900, Randy Bush wrote: > > besides a major design flaw, why would any bgp speaker not be capable > > of handling a 65k msg? > > when ram is one of the most frequent causes of having to spend more > money to upgrade routers, i tend toward conservative. > The long term cost of a bad RFC are magnitudes bigger than the cost of upgrading those routers that you try to save (and which will be replaced soon because of some other limit they hit). -- :wq Claudio From stephane.litkowski@orange-ftgroup.com Fri Apr 15 02:06:40 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1DC43E07A4 for ; Fri, 15 Apr 2011 02:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.208 X-Spam-Level: X-Spam-Status: No, score=-0.208 tagged_above=-999 required=5 tests=[AWL=2.040, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly16JJhldvWg for ; Fri, 15 Apr 2011 02:06:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfc.amsl.com (Postfix) with ESMTP id 3EFC9E079F for ; Fri, 15 Apr 2011 02:06:38 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 4677F3B434B; Fri, 15 Apr 2011 11:06:37 +0200 (CEST) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 19EF438406B; Fri, 15 Apr 2011 11:06:37 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Apr 2011 11:06:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Apr 2011 11:06:36 +0200 Message-ID: <23910_1302858397_4DA80A9D_23910_556077_1_4FC3556A36EE3646A09DAA60429F5335063664B6@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" Thread-Index: AQHL77veohlgKlPj5Eu+rRghEYxDvZRdnpQLgAEat9A= References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> From: To: "Jie Dong" , X-OriginalArrivalTime: 15 Apr 2011 09:06:37.0890 (UTC) FILETIME=[6D3B9A20:01CBFB4C] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.15.83314 Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:06:40 -0000 Support On 3/31/11 8:54 AM, "Jie Dong" wrote: > Dear all, >=20 > Authors of "IPv6 AF Extensions for Route Target Distribution" would=20 > like to propose to adopt this draft as IDR WG document. >=20 > The draft could be found at: > http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01 >=20 >=20 > Best regards, > Keyur Patel > Robert Raszuk > Martine Djernaes > Jie Dong > Mach Chen >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From christian.jacquenet@orange-ftgroup.com Fri Apr 15 02:09:41 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6BAE4E07D0 for ; Fri, 15 Apr 2011 02:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0FT6EisnT+p for ; Fri, 15 Apr 2011 02:09:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfc.amsl.com (Postfix) with ESMTP id 8AD8DE06D6 for ; Fri, 15 Apr 2011 02:09:40 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 276481B84DA for ; Fri, 15 Apr 2011 11:09:40 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id F3BD5384069 for ; Fri, 15 Apr 2011 11:09:39 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 15 Apr 2011 11:09:40 +0200 From: To: "idr@ietf.org" Date: Fri, 15 Apr 2011 11:09:38 +0200 Thread-Topic: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" Thread-Index: AQHL77veohlgKlPj5Eu+rRghEYxDvZRdnpQLgAEat9CAAADC4A== Message-ID: <23910_1302858580_4DA80B54_23910_556369_1_983A1D8DA0DA5F4EB747BF34CBEE5CD14AE413E77D@PUEXCB1C.nanterre.francetelecom.fr> References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> <23910_1302858397_4DA80A9D_23910_556077_1_4FC3556A36EE3646A09DAA60429F5335063664B6@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <23910_1302858397_4DA80A9D_23910_556077_1_4FC3556A36EE3646A09DAA60429F5335063664B6@PUEXCBL0.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.15.83314 Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:09:41 -0000 Dear all, I also support the adoption of this draft as an idr WG document. Cheers, Christian.=20 On 3/31/11 8:54 AM, "Jie Dong" wrote: > Dear all, >=20 > Authors of "IPv6 AF Extensions for Route Target Distribution" would=20 > like to propose to adopt this draft as IDR WG document. >=20 > The draft could be found at: > http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01 >=20 >=20 > Best regards, > Keyur Patel > Robert Raszuk > Martine Djernaes > Jie Dong > Mach Chen >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre pro= tegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message et t= ous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named r= ecipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From paul@jakma.org Fri Apr 15 03:11:51 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7932CE067E for ; Fri, 15 Apr 2011 03:11:51 -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=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JJfOUHYbz8T for ; Fri, 15 Apr 2011 03:11:49 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 391E8E0676 for ; Fri, 15 Apr 2011 03:11:49 -0700 (PDT) Received: by wyb29 with SMTP id 29so2366147wyb.31 for ; Fri, 15 Apr 2011 03:11:48 -0700 (PDT) Received: by 10.216.81.69 with SMTP id l47mr7344020wee.78.1302862308584; Fri, 15 Apr 2011 03:11:48 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk [130.209.244.4]) by mx.google.com with ESMTPS id a50sm1220175wer.18.2011.04.15.03.11.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2011 03:11:48 -0700 (PDT) Date: Fri, 15 Apr 2011 11:11:46 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Randy Bush In-Reply-To: Message-ID: References: <20110415005809.E1BBBE06BC@ietfc.amsl.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 10:11:51 -0000 Hi, I have 2 comments, one specifically about this draft and another one that's more general about error-handling for over-size messages (may or may not be appropriate for consideration in your draft). 1. If we're going to fix the length, could we do something to ensure that for each specific BGP message type that it's length, excluding any encapsulation of other BGP message types, Lt is << L the BGP message length field, so that we can be reasonably confident that even with multiple encapsulations of messages we're not going to overflow L. E.g. if L is to be 64k-1, then could we also specify that UPDATE messages should continue to be restricted to 4k? Or if UPDATE must be at least 64k, could we have a negotiated mode change for the message header to allow for a larger, e.g. MBZ bit + 31 bit, length field? Given BGP allows packing in UPDATEs, it really might make things simpler to encourage BGP speakers to keep UPDATEs significantly smaller than the max size whenever possible at least, in a stronger way than the current text. 2. What are we going to do about the overflow cases? What should BGP do if a speaker deliberately sends an UPDATE out that is stuffed to be /near/ the maximum size, such that a speaker further along will, through normal BGP operation (AS_PATH addition, e.g.) cause the UPDATE to overflow the message size? We could have a variable length length field I guess. ;) regards, --paulj On Fri, 15 Apr 2011, Randy Bush wrote: > A new version of I-D, draft-ymbk-bgp-extended-messages-02.txt has been > successfully submitted by Randy Bush and posted to the IETF repository. > > Filename: draft-ymbk-bgp-extended-messages > Revision: 02 > Title: Extended Message support for BGP > Creation_date: 2011-04-15 > WG ID: Independent Submission > Number_of_pages: 5 > > Abstract: > The current 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 > draft provides an extension for BGP to extend its current message > size for BGP messages from 4096 octets to 65535 octets. > > > > The IETF Secretariat. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: Deprive a mirror of its silver and even the Czar won't see his face. From jsw@inconcepts.biz Fri Apr 15 06:51:15 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 83F30E06A7 for ; Fri, 15 Apr 2011 06:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUdpJPFTH5Gi for ; Fri, 15 Apr 2011 06:51:15 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id EF605E069A for ; Fri, 15 Apr 2011 06:51:14 -0700 (PDT) Received: by vxg33 with SMTP id 33so2627805vxg.31 for ; Fri, 15 Apr 2011 06:51:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.146 with SMTP id dc18mr3105362vdb.11.1302875415782; Fri, 15 Apr 2011 06:50:15 -0700 (PDT) Received: by 10.220.177.11 with HTTP; Fri, 15 Apr 2011 06:50:15 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110415055000.GK2749@shrubbery.net> Date: Fri, 15 Apr 2011 09:50:15 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:51:15 -0000 On Fri, Apr 15, 2011 at 2:03 AM, Randy Bush wrote: >> besides a major design flaw, why would any bgp speaker not be capable >> of handling a 65k msg? > > when ram is one of the most frequent causes of having to spend more > money to upgrade routers, i tend toward conservative. Frankly, Randy, this is either an unbelievably ignorant statement, or an empty argument posted to waste readers' time. If a router doesn't have 64KB of memory to buffer an incoming message, its resource constraints are certainly such that it has no memory for additional code required to implement new features, or to store new state information, resulting from any extensions to BGP. I would love to see the practical example of a BGP router which operates correctly today, can be extended to support new extensions, yet will malfunction if its message buffer must be increased from 4KB to 64KB. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From raszuk@cisco.com Fri Apr 15 07:43:18 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 44067E06BA for ; Fri, 15 Apr 2011 07:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32v4wdZVmMOF for ; Fri, 15 Apr 2011 07:43:09 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 99832E06A7 for ; Fri, 15 Apr 2011 07:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1263; q=dns/txt; s=iport; t=1302878589; x=1304088189; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=UQhrDrJs4Gsx7kJy4VzchFxLgRgK5TDo9CKubncrwLo=; b=HEp0w/VD54YwjomSQ80T0uQra7lIW0jy3xlA3XhXi/gUrB/XIW66uR4p KD9hiRsYc6a0v3+g220UlUp/XuTF9PgVPxEBYwu514lPat7n283BzeZPO OzeT0mLOwH+ifI2WlqsC1O5DtJtC2c911lse1muSjoKRM2Hs/0pfZhTzg s=; X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="682209496" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2011 14:43:09 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3FEh7b7026076; Fri, 15 Apr 2011 14:43:07 GMT Message-ID: <4DA85973.6000106@cisco.com> Date: Fri, 15 Apr 2011 16:42:59 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "shares@ndzh.com" , John Scudder Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , Burjiz Pithawala , Danny McPherson Subject: [Idr] [SUMMARY] Fwd: Dissemination of Flow Specification Rules for IPv6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 14:43:18 -0000 Dear IDR WG chairs, After over two weeks of WG call for adoption of "Dissemination of Flow Specification Rules for IPv6" draft here is the summary of the feedback received: Support: jeff.tantsura@ericsson.com jhaas@pfrc.org wim.henderickx@alcatel-lucent.com bashandy@cisco.com ilya@nobulus.com tom@someaddress.net hritter@cisco.com danny@tcb.net Torunn.Narvestad@telenor.com christian.jacquenet@orange-ftgroup.com shane@castlepoint.net No support: None. If I accidentally missed any vote please kindly let me know and the above list will be updated. Therefor the authors of the draft would like to ask chairs for the recommendation on next step for this document. Rgs, R. Raszuk B. Pithawala D. McPherson -------- Original Message -------- Subject: Dissemination of Flow Specification Rules for IPv6 Date: Thu, 31 Mar 2011 15:31:42 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com To: idr@ietf.org List Authors of "Dissemination of Flow Specification Rules for IPv6" draft document would like to propose the adoption of this work as the IDR WG item. Ref: http://tools.ietf.org/html/draft-raszuk-idr-flow-spec-v6-01 Rgs, R. Raszuk B. Pithawala D. McPherson From raszuk@cisco.com Fri Apr 15 07:43:21 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0799CE0745 for ; Fri, 15 Apr 2011 07:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nl9kTi25vQR3 for ; Fri, 15 Apr 2011 07:43:16 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 0BA2CE066A for ; Fri, 15 Apr 2011 07:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1295; q=dns/txt; s=iport; t=1302878596; x=1304088196; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=j1xvVeSblXnrqbYAfcIdsBPTxUISxSdjb/LLJui5W2A=; b=YA4lMdlm2/eOKWAYCZgDa3PN2j8xPESdWqe3p/HmbZzenixznEF7DEXE gixPxNT2u4DCTc08UNdeLTxHlUMS3SUqzpSpgesGcF9bpddNzGsP7A4rN 6SPIhKJOsO8Yb7tu5wp5kPOVUAgSEBTW5HLpGUHrNNhD1rCKVwpvr9XnQ Y=; X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="430950417" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2011 14:43:15 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3FEhCWQ027106; Fri, 15 Apr 2011 14:43:13 GMT Message-ID: <4DA8597A.50402@cisco.com> Date: Fri, 15 Apr 2011 16:43:06 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "shares@ndzh.com" , John Scudder Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , DECRAENE Bruno RD-CORE-ISS , =?ISO-8859-1?Q?Erik_=C5man?= Subject: [Idr] [SUMMARY] Fwd: BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 14:43:21 -0000 Dear IDR WG chairs, After over two weeks of WG call for adoption of "BGP Optimal Route Reflection" draft here is the summary of the feedback received: Support: stephane.litkowski@orange-ftgroup.com rjs@rob.sh ub@cs.uni-bonn.de marka888@gmail.com paul@jakma.org danny@tcb.net ilya@nobulus.com bruno.decraene@orange-ftgroup.com jsw@inconcepts.biz shane@castlepoint.net russ@cisco.com Partial support: hannes@juniper.net Withdrawn objections: jgs@juniper.net No support: rbonica@juniper.net If I accidentally missed any vote please kindly let me know and the above list will be updated. Therefor the authors of the draft would like to ask chairs for the recommendation on next step for this document. Rgs, R. Raszuk C. Cassar E. Aman B. Decraene -------- Original Message -------- Subject: BGP Optimal Route Reflection (BGP-ORR) Date: Thu, 31 Mar 2011 15:34:31 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com To: idr@ietf.org List Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document would like to propose the adoption of this work as the IDR WG item. Ref: http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 Rgs, R. Raszuk C. Cassar E. Aman B. Decraene From raszuk@cisco.com Fri Apr 15 08:59:03 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 13EB6E087C; Fri, 15 Apr 2011 08:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqHBk16bZnvj; Fri, 15 Apr 2011 08:58:58 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 92DF8E06A9; Fri, 15 Apr 2011 08:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2519; q=dns/txt; s=iport; t=1302883138; x=1304092738; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9+6RUeu4zkJKCrJ0heNWbIYqVKzf44O4XsUuE5MmUOs=; b=LtTQajISoDSDdYR3E73kbwgbGRU68wnjKyt9IQgcssXCA93B1O7fTC8f z7U8iO3DxeK618t5OIrOknat3+USGmUFuW258nvmW55vP8faILZDOx8gx BM7oPzYh+O4CbKQsFt5iDsbPpq9JrwqfMEeWX6V6k4gqE1Nb4fRpYg4J5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGpqqE2rRDoH/2dsb2JhbACmBHeIb55tgnQOAZl7hW4EjXiDdA X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="431018974" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2011 15:58:57 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3FFwt1g030278; Fri, 15 Apr 2011 15:58:56 GMT Message-ID: <4DA86B39.8090008@cisco.com> Date: Fri, 15 Apr 2011 17:58:49 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Stephen Kent References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA6D6C8.2040304@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: john heasley , idr@ietf.org, sidr@ietf.org Subject: Re: [Idr] [sidr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:59:03 -0000 Hi Stephen, This is really great explanation. I did try to find this in some papers and your slides but I could not. So it confirms that even if we use "worse case" BGP update advertised by customer to provider (1 hop only case) it will fit within 4K limit easily. Of course for any subsequent advertisement we need increase the message size and this is where the draft-ymbk-bgp-extended-messages addresses the issue. One sentence in your reply is still not clear: > If on users RSA, each signature would be at least 1K bytes, and might > be 2K bytes, depending on the key length size chosen. So, a 20-hop > path could yield a 20-40K set of sigs, independent of the other path > security data. - What is the maximum key length possible and how big would be the RSA signature with such key length ? - What are the other path security data and what their size might be min-max. Many thx again, R. > At 1:13 PM +0200 4/14/11, Robert Raszuk wrote: >>> no. it is telling the edge site, your paying customer, that they >>> can secure their prefix without upgrading hardware. >> >> Can anyone in IDR or SIDR demystify for us here what securing BGP >> really requires (certificates, signatures, attestations you name >> it) if to secure a single prefix originated by customer site >> requires more then 4K of BGP message size ? > > BGPSEC calls for each AS hop along a path to sign AS path info. > Although the average path length is a bit less than 4 hops, there are > some very long paths that appear in FIBs, e.g., over 20 hops. The > desire to increase the max UPADTE size (from the current 4K limit) is > intended to accommodate very long paths. The principle contributor to > the size increase is the digital signature. If on users RSA, each > signature would be at least 1K bytes, and might be 2K bytes, > depending on the key length size chosen. So, a 20-hop path could > yield a 20-40K set of sigs, independent of the other path security > data. > > The good news is that many long paths contain repeated AS#s, which > could be collapsed into a single signature. But, that optimization > has not yet been explored. Also, if we were to use DSA or ECDSA as a > signature algorithm, instead of RSA, the signature size could drop to > 128 or 256 bytes, from 1-2K, a savings of a factor of 4-8. Still, a > 20-hop path, with no repeats, might not fit in a 4K UPDATE, with all > of the other secruity data. > > Hope that explanation helps. > > Steve > From rajiva@cisco.com Fri Apr 15 09:00:24 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A18D7E070B for ; Fri, 15 Apr 2011 09:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWIai0ztA9XN for ; Fri, 15 Apr 2011 09:00:20 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id BACFBE069F for ; Fri, 15 Apr 2011 09:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2033; q=dns/txt; s=iport; t=1302883219; x=1304092819; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=wsuG4FjLkwj9/pMivqJbhk/9GJCV0vyHJnsB4kAff5I=; b=GAXQ4sA3g+YFoA8KNHj7AHzd4Mkh07dc5whKWqDgzZDkAvtQYbhyP1Oo 8fokMl17i50Yvx1DUvXtgkqMm11OYFAlwlgkhI3oLL55TCyaqftw1n796 N/duCsjPaV3crSQ8ZxuHxracb7Iubj2I3LQiENLDCAE71LyUU9ICZWdjo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwBAFprqE2tJV2b/2dsb2JhbACYBY1/d6dMnH6FbgSFYIwTg0Y X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="338435818" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 16:00:07 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3FG07Jd022354; Fri, 15 Apr 2011 16:00:07 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 11:00:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Apr 2011 11:00:04 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C04B2FA98@XMB-RCD-111.cisco.com> In-Reply-To: <4DA8597A.50402@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] [SUMMARY] Fwd: BGP Optimal Route Reflection (BGP-ORR) Thread-Index: Acv7e4xDjoT9+tkPR+Ck2/oTyhYpwgACpTEQ References: <4DA8597A.50402@cisco.com> From: "Rajiv Asati (rajiva)" To: "Robert Raszuk (raszuk)" , , "John Scudder" X-OriginalArrivalTime: 15 Apr 2011 16:00:06.0589 (UTC) FILETIME=[305EA6D0:01CBFB86] Cc: idr@ietf.org, =?iso-8859-1?Q?Erik_=C5man?= , DECRAENE Bruno RD-CORE-ISS Subject: Re: [Idr] [SUMMARY] Fwd: BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:00:24 -0000 +1 to adopt.=20 Cheers, Rajiv ~~~ June 8, 2011 is the "World IPv6 Day" (http://isoc.org/wp/worldipv6day/) > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Robert Raszuk (raszuk) > Sent: Friday, April 15, 2011 10:43 AM > To: shares@ndzh.com; John Scudder > Cc: idr@ietf.org List; DECRAENE Bruno RD-CORE-ISS; Erik =C5man > Subject: [Idr] [SUMMARY] Fwd: BGP Optimal Route Reflection (BGP-ORR) >=20 > Dear IDR WG chairs, >=20 > After over two weeks of WG call for adoption of "BGP Optimal Route > Reflection" draft here is the summary of the feedback received: >=20 > Support: >=20 > stephane.litkowski@orange-ftgroup.com > rjs@rob.sh > ub@cs.uni-bonn.de > marka888@gmail.com > paul@jakma.org > danny@tcb.net > ilya@nobulus.com > bruno.decraene@orange-ftgroup.com > jsw@inconcepts.biz > shane@castlepoint.net > russ@cisco.com >=20 > Partial support: hannes@juniper.net > Withdrawn objections: jgs@juniper.net > No support: rbonica@juniper.net >=20 > If I accidentally missed any vote please kindly let me know and the > above list will be updated. >=20 > Therefor the authors of the draft would like to ask chairs for the > recommendation on next step for this document. >=20 > Rgs, > R. Raszuk > C. Cassar > E. Aman > B. Decraene >=20 > -------- Original Message -------- > Subject: BGP Optimal Route Reflection (BGP-ORR) > Date: Thu, 31 Mar 2011 15:34:31 +0200 > From: Robert Raszuk > Reply-To: raszuk@cisco.com > To: idr@ietf.org List >=20 >=20 > Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document > would > like to propose the adoption of this work as the IDR WG item. >=20 > Ref: > = http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 >=20 > Rgs, > R. Raszuk > C. Cassar > E. Aman > B. Decraene > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Fri Apr 15 09:46:31 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A4AAE13003B for ; Fri, 15 Apr 2011 09:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7n2Mg73rkLf for ; Fri, 15 Apr 2011 09:46:27 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfc.amsl.com (Postfix) with ESMTP id 9F789130022 for ; Fri, 15 Apr 2011 09:46:22 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTah2XMy5P1ICs7i9uzpuOgy2FXKHTppn@postini.com; Fri, 15 Apr 2011 09:46:27 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 15 Apr 2011 09:40:06 -0700 From: John Scudder To: "raszuk@cisco.com" Date: Fri, 15 Apr 2011 09:42:04 -0700 Thread-Topic: [SUMMARY] Fwd: BGP Optimal Route Reflection (BGP-ORR) Thread-Index: Acv7i8a0IeQc4eX8RjW1rzPXH/HnIw== Message-ID: <8B54B7CC-24F6-438D-92B4-29776D5842EB@juniper.net> References: <4DA8597A.50402@cisco.com> In-Reply-To: <4DA8597A.50402@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , DECRAENE Bruno RD-CORE-ISS , =?iso-8859-1?Q?Erik_=C5man?= , "shares@ndzh.com" Subject: Re: [Idr] [SUMMARY] Fwd: BGP Optimal Route Reflection (BGP-ORR) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:46:31 -0000 Robert, Thanks for the administrative help. :-) There is clearly WG consensus to adopt the draft; please resubmit as draft-= ietf-idr. However, I do want to point out that it's not currently on our c= harter and so the next step for the chairs is to talk with our AD about tha= t. (The same question will likely arise about a number of the other drafts= that have been proposed as WG items.) Regards, --John On Apr 15, 2011, at 10:43 AM, Robert Raszuk wrote: > Dear IDR WG chairs, >=20 > After over two weeks of WG call for adoption of "BGP Optimal Route=20 > Reflection" draft here is the summary of the feedback received: >=20 > Support: >=20 > stephane.litkowski@orange-ftgroup.com > rjs@rob.sh > ub@cs.uni-bonn.de > marka888@gmail.com > paul@jakma.org > danny@tcb.net > ilya@nobulus.com > bruno.decraene@orange-ftgroup.com > jsw@inconcepts.biz > shane@castlepoint.net > russ@cisco.com >=20 > Partial support: hannes@juniper.net > Withdrawn objections: jgs@juniper.net > No support: rbonica@juniper.net >=20 > If I accidentally missed any vote please kindly let me know and the=20 > above list will be updated. >=20 > Therefor the authors of the draft would like to ask chairs for the=20 > recommendation on next step for this document. >=20 > Rgs, > R. Raszuk > C. Cassar > E. Aman > B. Decraene >=20 > -------- Original Message -------- > Subject: BGP Optimal Route Reflection (BGP-ORR) > Date: Thu, 31 Mar 2011 15:34:31 +0200 > From: Robert Raszuk > Reply-To: raszuk@cisco.com > To: idr@ietf.org List >=20 >=20 > Authors of "BGP Optimal Route Reflection (BGP-ORR)" draft document would= =20 > like to propose the adoption of this work as the IDR WG item. >=20 > Ref: > http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 >=20 > Rgs, > R. Raszuk > C. Cassar > E. Aman > B. Decraene From kent@bbn.com Fri Apr 15 08:46:35 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 82067E070B; Fri, 15 Apr 2011 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7hY+xHJmZeA; Fri, 15 Apr 2011 08:46:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 01802E069F; Fri, 15 Apr 2011 08:46:35 -0700 (PDT) Received: from dhcp89-089-062.bbn.com ([128.89.89.62]:49204) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAlEA-000E0W-CH; Fri, 15 Apr 2011 11:46:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DA6D6C8.2040304@cisco.com> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA6D6C8.2040304@cisco.com> Date: Fri, 15 Apr 2011 11:46:24 -0400 To: raszuk@cisco.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailman-Approved-At: Fri, 15 Apr 2011 09:48:47 -0700 Cc: john heasley , idr@ietf.org, sidr@ietf.org Subject: Re: [Idr] [sidr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:46:35 -0000 At 1:13 PM +0200 4/14/11, Robert Raszuk wrote: >>no. it is telling the edge site, your paying customer, that they can >>secure their prefix without upgrading hardware. > >Can anyone in IDR or SIDR demystify for us here what securing BGP >really requires (certificates, signatures, attestations you name it) >if to secure a single prefix originated by customer site requires >more then 4K of BGP message size ? BGPSEC calls for each AS hop along a path to sign AS path info. Although the average path length is a bit less than 4 hops, there are some very long paths that appear in FIBs, e.g., over 20 hops. The desire to increase the max UPADTE size (from the current 4K limit) is intended to accommodate very long paths. The principle contributor to the size increase is the digital signature. If on users RSA, each signature would be at least 1K bytes, and might be 2K bytes, depending on the key length size chosen. So, a 20-hop path could yield a 20-40K set of sigs, independent of the other path security data. The good news is that many long paths contain repeated AS#s, which could be collapsed into a single signature. But, that optimization has not yet been explored. Also, if we were to use DSA or ECDSA as a signature algorithm, instead of RSA, the signature size could drop to 128 or 256 bytes, from 1-2K, a savings of a factor of 4-8. Still, a 20-hop path, with no repeats, might not fit in a 4K UPDATE, with all of the other secruity data. Hope that explanation helps. Steve From jgs@juniper.net Fri Apr 15 10:14:20 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15E5A130080 for ; Fri, 15 Apr 2011 10:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTwynECGBpAD for ; Fri, 15 Apr 2011 10:14:19 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfc.amsl.com (Postfix) with ESMTP id 501AB13002E for ; Fri, 15 Apr 2011 10:14:19 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTah85DalJEjjtDTn6Yu4SEBlKBZTjGYW@postini.com; Fri, 15 Apr 2011 10:14:19 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 15 Apr 2011 10:09:30 -0700 From: John Scudder To: "idr@ietf.org List" Date: Fri, 15 Apr 2011 10:11:27 -0700 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acv7j+GNG/YnMm3IRnm54SO/xtic0A== Message-ID: <764D6146-53D3-4C06-8FB0-5D8D303D40F0@juniper.net> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110415055000.GK2749@shrubbery.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 17:14:20 -0000 May I suggest we wind down this thread and move conversation to the -02 thr= ead? (Hint: -02 seems to have addressed the issues being currently discuss= ed.) --John= From kent@bbn.com Fri Apr 15 12:12:24 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2EB9FE0774; Fri, 15 Apr 2011 12:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI0ZxN9dExwt; Fri, 15 Apr 2011 12:12:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id 8A2B1E0749; Fri, 15 Apr 2011 12:12:22 -0700 (PDT) Received: from dhcp89-089-062.bbn.com ([128.89.89.62]:49217) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAoRK-0006dR-7i; Fri, 15 Apr 2011 15:12:22 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DA86B39.8090008@cisco.com> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA6D6C8.2040304@cisco.com> <4DA86B39.8090008@cisco.com> Date: Fri, 15 Apr 2011 15:12:12 -0400 To: raszuk@cisco.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: john heasley , idr@ietf.org, sidr@ietf.org Subject: Re: [Idr] [sidr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 19:12:24 -0000 Robert, First let me apologize as I accidentally put in "bytes" where I meant "bits" in the examples I provided. Whoops! RSA 2K keys are 2K bits, i.e., 256 bytes (not 2K bytes). And, 2K RSA sig is the default, as this matches the key sizes we have already agreed upon for the RPKI certs. Still, a 20-hop path with RSA 2K (bit) sigs exceeds the 4K (byte) max UPDATE size, without any other overhead. Sorry for the confusion. > >- What is the maximum key length possible and how big would be the >RSA signature with such key length ? There is no max key size, but it does not make sense to push for bigger RSA key sizes, instead of moving to more efficient (in space and computation) sig algorithms. The sig size for RSA is the same size as the key. The likely sucessor algs are DSA or EC-DSA, which use smaller keys, but offer secruity equivalent to the larger RSA key sizes. The key sizes for those algorithms yield 128 or 256-bit sigs, under current hash algs. >- What are the other path security data and what their size might be min-max. I defer to Matt Lepinski for the details of the other data, as he is the author of the BGPSEC protocol doc. Steve From jeff.tantsura@ericsson.com Fri Apr 15 12:16:25 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A8624E0688 for ; Fri, 15 Apr 2011 12:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.072 X-Spam-Level: X-Spam-Status: No, score=-5.072 tagged_above=-999 required=5 tests=[AWL=1.527, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkir-lBotlPX for ; Fri, 15 Apr 2011 12:16:25 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 1A76AE08BD for ; Fri, 15 Apr 2011 12:16:25 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3FJGMBu010176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Apr 2011 14:16:22 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 15 Apr 2011 15:16:22 -0400 From: Jeff Tantsura To: Jie Dong , "idr@ietf.org" Date: Fri, 15 Apr 2011 15:16:21 -0400 Thread-Topic: [Idr] WG adoption of "IPv6 AF Extensions for Route TargetDistribution" Thread-Index: AQHL77veohlgKlPj5Eu+rRghEYxDvZRdoZ+ggAHAA2A= Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CAB3EBABC@EUSAACMS0701.eamcs.ericsson.se> References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route TargetDistribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 19:16:25 -0000 Yes/support Regards, Jeff =20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jie Dong Sent: Thursday, March 31, 2011 8:54 AM To: idr@ietf.org Subject: [Idr] WG adoption of "IPv6 AF Extensions for Route TargetDistribution" Dear all,=20 Authors of "IPv6 AF Extensions for Route Target Distribution" would like to propose to adopt this draft as IDR WG document. The draft could be found at:=20 http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01 Best regards, Keyur Patel Robert Raszuk Martine Djernaes Jie Dong Mach Chen From curtis@occnc.com Fri Apr 15 13:01:37 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9C5FCE06D8 for ; Fri, 15 Apr 2011 13:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0XoVnTt3eLJ for ; Fri, 15 Apr 2011 13:01:37 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 49CB2E0691 for ; Fri, 15 Apr 2011 13:01:35 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3FK1VGk074992; Fri, 15 Apr 2011 16:01:31 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104152001.p3FK1VGk074992@harbor.orleans.occnc.com> To: Randy Bush From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 14:04:54 +0900." <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> Date: Fri, 15 Apr 2011 16:01:31 -0400 Sender: curtis@occnc.com Cc: Keyur Patel , idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 20:01:37 -0000 In message <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> Randy Bush writes: > > Allow simplex edge site bgpsec router not to need large receive buffers > -- > sent from android, so terse You can receive 64KB BGP packets over TCP with a 4KB or 8KB TCP receive window but it has to be reassembled in user space. Prioritzing sockets for which some segments have been received would be an enabler to keep the number of active 64KB BGP buffers low. Presumably these really small routers have very few BGP sessions, usuaully just one and one times 64KB is not a big number even for implementations with very tiny amounts of RAM. I could see this argument maybe if we still had 20 year old IGS routers in the network, but I don't think they will be running the latest code. Curtis From gih@apnic.net Fri Apr 15 13:09:22 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0FAACE0687; Fri, 15 Apr 2011 13:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.704 X-Spam-Level: X-Spam-Status: No, score=-94.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Tc7wkYr1DTD; Fri, 15 Apr 2011 13:09:21 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfc.amsl.com (Postfix) with ESMTP id BA0CFE06D1; Fri, 15 Apr 2011 13:09:20 -0700 (PDT) Received: from 203.35.240.10.in-addr.arpa (mac5f36d0.tmodns.net [208.54.95.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 0C615B68C4; Sat, 16 Apr 2011 06:09:16 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 16 Apr 2011 06:09:10 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <169088F7-4722-41EA-9E6B-C3BC8D20D813@apnic.net> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA6D6C8.2040304@cisco.com> <4DA86B39.8090008@cisco.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: raszuk@cisco.com, john heasley , sidr@ietf.org, idr@ietf.org Subject: Re: [Idr] [sidr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 20:09:22 -0000 On 16/04/2011, at 5:12 AM, Stephen Kent wrote: > Robert, >=20 > First let me apologize as I accidentally put in "bytes" where I meant = "bits" in the examples I provided. Whoops! RSA 2K keys are 2K bits, = i.e., 256 bytes (not 2K bytes). And, 2K RSA sig is the default, as this = matches the key sizes we have already agreed upon for the RPKI certs. = Still, a 20-hop path with RSA 2K (bit) sigs exceeds the 4K (byte) max = UPDATE size, without any other overhead. Sorry for the confusion. >=20 >>=20 >> - What is the maximum key length possible and how big would be the = RSA signature with such key length ? >=20 > There is no max key size, but it does not make sense to push for = bigger RSA > key sizes, instead of moving to more efficient (in space and = computation) sig algorithms. The sig size for RSA is the same size as = the key. >=20 > The likely sucessor algs are DSA or EC-DSA, which use smaller keys, = but offer secruity equivalent to the larger RSA key sizes. The key sizes = for those algorithms yield 128 or 256-bit sigs, under current hash algs. >=20 >> - What are the other path security data and what their size might be = min-max. >=20 > I defer to Matt Lepinski for the details of the other data, as he is = the author of the BGPSEC protocol doc. I was doing a similar mental sum in my head and 256 bytes per sig is not = a lot. As far as I am aware the only other added per-AS part of the = attribute is the SKI of the public key. Presumably this is also 256 = bytes. SO thats 500 bytes per AS, and for a 20 AS path thats 10K in additional = data. Is my back of the envelope anywhere near in the right ball park? Geoff= From curtis@occnc.com Fri Apr 15 14:04:22 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1160BE0691 for ; Fri, 15 Apr 2011 14:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWJalDIgdOhS for ; Fri, 15 Apr 2011 14:04:21 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 64477E0674 for ; Fri, 15 Apr 2011 14:04:21 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3FL4JK6075718; Fri, 15 Apr 2011 17:04:19 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104152104.p3FL4JK6075718@harbor.orleans.occnc.com> To: Keyur Patel From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 07:23:45 PDT." Date: Fri, 15 Apr 2011 17:04:19 -0400 Sender: curtis@occnc.com Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 21:04:22 -0000 In message Keyur Patel writes: > > Curtis, > > >>>>> What I meant by bi-directional is both sides have to be able and > >>>>> willing to receive extended-messages for either side to send them. > >>>>> That way an entire packet can always be sent in the reverse direction > >>>>> when indicating that something was wrong with it. > >>>> > >>>> If a BGP sending speaker sees a need to receive complete encapsulated > >>>> packet, it can always send original packet with size less than > >>>> 65K. You don't need capability to be *bi-directional*. There are cases > >>>> where asymmetric capability may be needed. > >>> > >>> And what are those cases? > >> > >> SIDR requirement being the prime one. Any other applications that require > >> BGP to send longer length messages. > > > > You still haven't indicated why any usage of BGP would need the long > > message capability to be uni-directional. > > > > Please explain why the other direction cannot send extended messages. > > Typically, most implementations terminate BGP sessions upon *receiving* > messages longer than current 4096 octets. This is a receiving side behavior > (Sending side speaker would automatically build another message beyond 4096 > octets). The draft aims to relax this part and hence the capability being > asymmetric (specifically targeting the receiving side behavior). > > Its not that other direction "cannot send extended messages". Its more like > other direction does NOT need to enable this capability unless required. > > Hope that clarifies. > > Regards, > Keyur Actually no that doesn't help. It sounds like it can be assymetrical. It is defined to be assymetrical. But is has no solid reason that it needs to be assymetrical. It is also perfectly valid to define the capability such that both ends have to be known to be capable before either end sends a very long BGP packet. Curtis From randy@psg.com Fri Apr 15 14:11:32 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 52E66E07BA for ; Fri, 15 Apr 2011 14:11:32 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GKGhTDW0XNr for ; Fri, 15 Apr 2011 14:11:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id E842DE077E for ; Fri, 15 Apr 2011 14:11:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAqIa-000CLD-VC; Fri, 15 Apr 2011 21:11:29 +0000 Date: Sat, 16 Apr 2011 06:11:49 +0900 Message-ID: From: Randy Bush To: Curtis Villamizar In-Reply-To: <201104152104.p3FL4JK6075718@harbor.orleans.occnc.com> References: <201104152104.p3FL4JK6075718@harbor.orleans.occnc.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Keyur Patel , idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 21:11:32 -0000 > Actually no that doesn't help. It sounds like it can be assymetrical. > It is defined to be assymetrical. you may want to read the current draft randy From keyupate@cisco.com Fri Apr 15 14:17:32 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D7C5AE0801 for ; Fri, 15 Apr 2011 14:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.352 X-Spam-Level: X-Spam-Status: No, score=-10.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W15AFXNUdp0m for ; Fri, 15 Apr 2011 14:17:29 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id DD3C9E07CC for ; Fri, 15 Apr 2011 14:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=1184; q=dns/txt; s=iport; t=1302902248; x=1304111848; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=LEqkNXQiXGU+Vm1LnQd0hWRw9nw4wLC5uqkptc1S99Q=; b=nBOtUeXBsmk9/1FssWy7421U2FyivgFRD7xu04wE/6MZhTlukwTR0fxi qLVxYDiLt6AG4q/Lxrvv4PZYeHogI+aw3hoDqSH389mSceLfBH/TolA/d zZmGPM50StL4ZEsxwgxBUsDPX89n78BafezraxDkZxFcoXDQ6+0gA1JWI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACy1qE2rRDoI/2dsb2JhbACmCXeIb58JnQSEYIEOBIVgiBiDew X-IronPort-AV: E=Sophos;i="4.64,221,1301875200"; d="scan'208";a="338694227" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 21:17:28 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3FLHRaM028714; Fri, 15 Apr 2011 21:17:28 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 14:16:57 -0700 Received: from 10.33.12.64 ([10.33.12.64]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Fri, 15 Apr 2011 21:16:56 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 15 Apr 2011 14:16:21 -0700 From: Keyur Patel To: , Randy Bush Message-ID: Thread-Topic: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 Thread-Index: Acv7sl4AnGhqBmelEeCGfQAbY71bnA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Apr 2011 21:16:57.0143 (UTC) FILETIME=[738AFC70:01CBFBB2] Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 21:17:33 -0000 Folks, Rev 2 of the draft makes the Extended message capability symmetrical. With that change, authors of this draft document would like to propose the adoption of this work as IDR WG item. Regards, Keyur On 4/14/11 5:59 PM, "Randy Bush" wrote: > A new version of I-D, draft-ymbk-bgp-extended-messages-02.txt has been > successfully submitted by Randy Bush and posted to the IETF repository. > > Filename: draft-ymbk-bgp-extended-messages > Revision: 02 > Title: Extended Message support for BGP > Creation_date: 2011-04-15 > WG ID: Independent Submission > Number_of_pages: 5 > > Abstract: > The current 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 > draft provides an extension for BGP to extend its current message > size for BGP messages from 4096 octets to 65535 octets. > > > > The IETF Secretariat. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Fri Apr 15 14:34:08 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE110E06AD for ; Fri, 15 Apr 2011 14:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaEx3As-1rxU for ; Fri, 15 Apr 2011 14:34:08 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 24965E0674 for ; Fri, 15 Apr 2011 14:34:08 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3FLY6xd001389; Fri, 15 Apr 2011 16:34:07 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 15 Apr 2011 17:34:00 -0400 From: Jakob Heitz To: Keyur Patel , "idr@ietf.org" , Randy Bush Date: Fri, 15 Apr 2011 17:33:59 -0400 Thread-Topic: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 Thread-Index: Acv7sl4AnGhqBmelEeCGfQAbY71bnAAAjSxA Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 21:34:09 -0000 I'll support it if you change the maximum to 65279 (0xfeff). -- Jakob Heitz. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Keyur Patel > Sent: Friday, April 15, 2011 2:16 PM > To: idr@ietf.org; Randy Bush > Subject: Re: [Idr] New Version Notification for=20 > draft-ymbk-bgp-extended-messages-02 >=20 > Folks, >=20 > Rev 2 of the draft makes the Extended message capability=20 > symmetrical. With > that change, authors of this draft document would like to propose the > adoption of this work as IDR WG item. >=20 > Regards, > Keyur >=20 >=20 >=20 > On 4/14/11 5:59 PM, "Randy Bush" wrote: >=20 > > A new version of I-D,=20 > draft-ymbk-bgp-extended-messages-02.txt has been > > successfully submitted by Randy Bush and posted to the IETF=20 > repository. > >=20 > > Filename: draft-ymbk-bgp-extended-messages > > Revision: 02 > > Title: Extended Message support for BGP > > Creation_date: 2011-04-15 > > WG ID: Independent Submission > > Number_of_pages: 5 > >=20 > > Abstract: > > The current BGP specification mandates a maximum BGP message size of > > 4096 octets. As BGP is extended to support newer=20 > AFI/SAFIs, there is > > a need to extend the maximum message size beyond 4096 octets. This > > draft provides an extension for BGP to extend its current message > > size for BGP messages from 4096 octets to 65535 octets. > > =20 > >=20 > >=20 > > The IETF Secretariat. > >=20 > >=20 > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From randy@psg.com Fri Apr 15 14:41:35 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A6E46E06A9 for ; Fri, 15 Apr 2011 14:41:35 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEER6U+MM9S5 for ; Fri, 15 Apr 2011 14:41:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 2E360E0674 for ; Fri, 15 Apr 2011 14:41:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAqlg-000CS4-79; Fri, 15 Apr 2011 21:41:32 +0000 Date: Sat, 16 Apr 2011 06:41:52 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 21:41:35 -0000 > I'll support it if you change the maximum to 65279 (0xfeff). and change current bgp to 4351 randy From ilya@nobulus.com Fri Apr 15 15:38:28 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E9A4FE0665 for ; Fri, 15 Apr 2011 15:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pX-XzpB7AuK for ; Fri, 15 Apr 2011 15:38:28 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfc.amsl.com (Postfix) with ESMTP id EE2E3E0661 for ; Fri, 15 Apr 2011 15:38:27 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id F050117442; Sat, 16 Apr 2011 00:38:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DrfMHWREoDlO; Sat, 16 Apr 2011 00:38:21 +0200 (CEST) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id BE832172DA; Sat, 16 Apr 2011 00:38:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: Date: Sat, 16 Apr 2011 00:38:13 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Keyur Patel X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 22:38:29 -0000 I'm fine with new version. Support +1 /iLya On Apr 15, 2011, at 23:16 , Keyur Patel wrote: > Folks, > > Rev 2 of the draft makes the Extended message capability symmetrical. With > that change, authors of this draft document would like to propose the > adoption of this work as IDR WG item. > > Regards, > Keyur > > > > On 4/14/11 5:59 PM, "Randy Bush" wrote: > >> A new version of I-D, draft-ymbk-bgp-extended-messages-02.txt has been >> successfully submitted by Randy Bush and posted to the IETF repository. >> >> Filename: draft-ymbk-bgp-extended-messages >> Revision: 02 >> Title: Extended Message support for BGP >> Creation_date: 2011-04-15 >> WG ID: Independent Submission >> Number_of_pages: 5 >> >> Abstract: >> The current 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 >> draft provides an extension for BGP to extend its current message >> size for BGP messages from 4096 octets to 65535 octets. >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > /iLya From curtis@occnc.com Fri Apr 15 15:44:31 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 86B42E0665 for ; Fri, 15 Apr 2011 15:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7P2OiY9ufYz for ; Fri, 15 Apr 2011 15:44:31 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id DDD27E0661 for ; Fri, 15 Apr 2011 15:44:30 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3FMiUhX077260; Fri, 15 Apr 2011 18:44:30 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104152244.p3FMiUhX077260@harbor.orleans.occnc.com> To: Randy Bush From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 17:16:38 +0900." Date: Fri, 15 Apr 2011 18:44:30 -0400 Sender: curtis@occnc.com Cc: john heasley , idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 22:44:31 -0000 In message Randy Bush writes: > > >> IMHO it is always a bad idea to maintain different defaults for > >> routing protocols on a per platform basis. > > > > yes, this is silly. it appears to be engineering around limitations > > of a specific piece of hardware. > > no. it is telling the edge site, your paying customer, that they can > secure their prefix without upgrading hardware. > > randy Randy, A router that can't support a 64KB buffer must have been purchased at WallyWorld and can't be much of an investment to toss. Wasn't the 64Kbit DRAM chip commercialized in about 1978? Even the IGS and AGS routers circa early 1990s had whole 4 MB of DRAM. Are we talking about DSL modems with only on-chip SRAM running BGP? Curtis From curtis@occnc.com Fri Apr 15 15:47:20 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 05F24E0691 for ; Fri, 15 Apr 2011 15:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWA09e2J8z6e for ; Fri, 15 Apr 2011 15:47:19 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id E7414E0665 for ; Fri, 15 Apr 2011 15:47:18 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3FMlG7H077293; Fri, 15 Apr 2011 18:47:16 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104152247.p3FMlG7H077293@harbor.orleans.occnc.com> To: Randy Bush From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Apr 2011 17:17:56 +0900." Date: Fri, 15 Apr 2011 18:47:16 -0400 Sender: curtis@occnc.com Cc: Robert Raszuk , idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 22:47:20 -0000 In message Randy Bush writes: > > > RP receive buffers are carved out of RP DRAM and those today are > > measured in gigabytes for BGP systems. > > perhaps you should look into what the edge enterprises have bought from > your company. > > randy Randy, I'll get back to you after I check with grandma as to whether she is running BGP and feels the need to secure her announced routes. Curtis From curtis@occnc.com Fri Apr 15 16:03:24 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 75418E067E for ; Fri, 15 Apr 2011 16:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WDEu6icVGFd for ; Fri, 15 Apr 2011 16:03:24 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id E2D52E0665 for ; Fri, 15 Apr 2011 16:03:23 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3FN3LN1077562; Fri, 15 Apr 2011 19:03:21 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104152303.p3FN3LN1077562@harbor.orleans.occnc.com> To: Randy Bush From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Apr 2011 15:03:52 +0900." Date: Fri, 15 Apr 2011 19:03:21 -0400 Sender: curtis@occnc.com Cc: john heasley , Robert Raszuk , idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 23:03:24 -0000 In message Randy Bush writes: > > > besides a major design flaw, why would any bgp speaker not be capable > > of handling a 65k msg? > > when ram is one of the most frequent causes of having to spend more > money to upgrade routers, i tend toward conservative. > > randy I always thought that had more to do with 300,000+ global BGP routes, not the socket buffer size. [Is grandma running full routes on her linksys dsl modem? I'll have to check with grandma again.] I also mentioned a few times that you can support 64K application messages over TCP with socket buffers of less than 64K. OTOH, right now 56K and 64K are the most common defaults so I seriously doubt there is any valid memory concern. Curtis From curtis@occnc.com Fri Apr 15 16:12:26 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CC40FE06BD for ; Fri, 15 Apr 2011 16:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d+5nEByCfGD for ; Fri, 15 Apr 2011 16:12:26 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 37671E066C for ; Fri, 15 Apr 2011 16:12:26 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3FNCJNO077701; Fri, 15 Apr 2011 19:12:20 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104152312.p3FNCJNO077701@harbor.orleans.occnc.com> To: Stephen Kent From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Apr 2011 11:46:24 EDT." Date: Fri, 15 Apr 2011 19:12:19 -0400 Sender: curtis@occnc.com Cc: raszuk@cisco.com, john heasley , idr@ietf.org Subject: Re: [Idr] [sidr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 23:12:27 -0000 In message Stephen Kent writes: > > At 1:13 PM +0200 4/14/11, Robert Raszuk wrote: > >>no. it is telling the edge site, your paying customer, that they can > >>secure their prefix without upgrading hardware. > > > >Can anyone in IDR or SIDR demystify for us here what securing BGP > >really requires (certificates, signatures, attestations you name it) > >if to secure a single prefix originated by customer site requires > >more then 4K of BGP message size ? > > BGPSEC calls for each AS hop along a path to sign AS path info. > Although the average path length is a bit less than 4 hops, there are > some very long paths that appear in FIBs, e.g., over 20 hops. The > desire to increase the max UPADTE size (from the current 4K limit) is > intended to accommodate very long paths. The principle contributor to > the size increase is the digital signature. If on users RSA, each > signature would be at least 1K bytes, and might be 2K bytes, > depending on the key length size chosen. So, a 20-hop path could > yield a 20-40K set of sigs, independent of the other path security > data. > > The good news is that many long paths contain repeated AS#s, which > could be collapsed into a single signature. But, that optimization > has not yet been > explored. Also, if we were to use DSA or ECDSA as a signature > algorithm, instead > of RSA, the signature size could drop to 128 or 256 bytes, from 1-2K, > a savings of a factor of 4-8. Still, a 20-hop path, with no repeats, > might not fit in a 4K UPDATE, with all of the other secruity data. > > Hope that explanation helps. > > Steve Steve, I would venture to guess that almost everyone on this thread knows of this motivation for extended-message. The question being debated is whether having extended-message in one direction but not the other direction serves any legitimate purpose. Curtis BTW- SIDR dropped from the Cc so as not to cross post and also since I dropped off SIDR quite a long time ago. From randy@psg.com Fri Apr 15 16:47:07 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8EF83E066C for ; Fri, 15 Apr 2011 16:47:07 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npsDv7GCJGfT for ; Fri, 15 Apr 2011 16:47:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 0DB63E0665 for ; Fri, 15 Apr 2011 16:47:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAsjB-000CvR-Vd; Fri, 15 Apr 2011 23:47:06 +0000 Date: Sat, 16 Apr 2011 08:47:26 +0900 Message-ID: From: Randy Bush To: Curtis Villamizar In-Reply-To: <201104152312.p3FNCJNO077701@harbor.orleans.occnc.com> References: <201104152312.p3FNCJNO077701@harbor.orleans.occnc.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] [sidr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 23:47:08 -0000 > The question being debated is whether having extended-message in one > direction but not the other direction serves any legitimate purpose. no. only those who have not read the current draft are debating that. randy From curtis@occnc.com Fri Apr 15 18:32:03 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 63DECE0682 for ; Fri, 15 Apr 2011 18:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRv9oYbd+-Au for ; Fri, 15 Apr 2011 18:32:02 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id C88D9E061E for ; Fri, 15 Apr 2011 18:32:02 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3G1W06m080010; Fri, 15 Apr 2011 21:32:00 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104160132.p3G1W06m080010@harbor.orleans.occnc.com> To: Randy Bush From: Curtis Villamizar In-reply-to: Your message of "Sat, 16 Apr 2011 06:11:49 +0900." Date: Fri, 15 Apr 2011 21:32:00 -0400 Sender: curtis@occnc.com Cc: Keyur Patel , idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 01:32:03 -0000 In message Randy Bush writes: > > > Actually no that doesn't help. It sounds like it can be assymetrical. > > It is defined to be assymetrical. > > you may want to read the current draft > > randy OK. thanks. I stand corrected. the unidirectionalness is out. (is that a word?) Curtis From christopher.morrow@gmail.com Fri Apr 15 18:45:59 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C9399E0682 for ; Fri, 15 Apr 2011 18:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kBwvmEY0Eqe for ; Fri, 15 Apr 2011 18:45:59 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id EB6EEE0660 for ; Fri, 15 Apr 2011 18:45:58 -0700 (PDT) Received: by wyb29 with SMTP id 29so2983968wyb.31 for ; Fri, 15 Apr 2011 18:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=olBx3lpeZ2zWoGWODCcq/tVMBRm94/L+jJ0VfduG37M=; b=cxVp3Y8bfcz1FoXow2mddQ7n2BtW4tgG3kNYIRJeUPhnAHK2IV1Og08bL7q+XgoZ7h cI5uZHdxW99WROR06W8nE73JIH1R6XA6dIk84xlyjSbaL5Sc8AG9qkZOvwVabCb7TEHF 76HKuWfPd2KOu1JIhwsgb9J+UudwD2DxHKDXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=eBrB0xsWwnGz8aLqdZLgfymPgs8Js5KLF2+I0cCQ8t30Gi3YKpvDLfEd1ydGcLAQ3X XF/lSmiy4tkWXGo1gGabpD9x8+iDxekvGms/GJ5F87cmFHV63W2N15Amk8ks6NQEeHHj 1DuNgOAaOqvtZcdqmrDFDXGuEjObI9uLu0oH0= MIME-Version: 1.0 Received: by 10.216.145.134 with SMTP id p6mr1541856wej.112.1302918358110; Fri, 15 Apr 2011 18:45:58 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.50.211 with HTTP; Fri, 15 Apr 2011 18:45:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Apr 2011 21:45:58 -0400 X-Google-Sender-Auth: YuE7RA8GkrruZFaYNYymZylIxKk Message-ID: From: Christopher Morrow To: Ilya Varlashkin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keyur Patel , idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 01:45:59 -0000 as well, this seems good, pls to make this final and publish :) On Fri, Apr 15, 2011 at 6:38 PM, Ilya Varlashkin wrote: > I'm fine with new version. Support +1 > > /iLya > > On Apr 15, 2011, at 23:16 , Keyur Patel wrote: > >> Folks, >> >> Rev 2 of the draft makes the Extended message capability symmetrical. Wi= th >> that change, authors of this draft document would like to propose the >> adoption of this work as IDR WG item. >> >> Regards, >> Keyur >> >> >> >> On 4/14/11 5:59 PM, "Randy Bush" wrote: >> >>> A new version of I-D, draft-ymbk-bgp-extended-messages-02.txt has been >>> successfully submitted by Randy Bush and posted to the IETF repository. >>> >>> Filename: =A0draft-ymbk-bgp-extended-messages >>> Revision: =A002 >>> Title: =A0 Extended Message support for BGP >>> Creation_date: =A02011-04-15 >>> WG ID: =A0 Independent Submission >>> Number_of_pages: 5 >>> >>> Abstract: >>> The current BGP specification mandates a maximum BGP message size of >>> 4096 octets. =A0As BGP is extended to support newer AFI/SAFIs, there is >>> a need to extend the maximum message size beyond 4096 octets. =A0This >>> draft provides an extension for BGP to extend its current message >>> size for BGP messages from 4096 octets to 65535 octets. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > /iLya > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From curtis@occnc.com Fri Apr 15 19:16:54 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7E555E0683 for ; Fri, 15 Apr 2011 19:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWy5HFCeXwsd for ; Fri, 15 Apr 2011 19:16:54 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id D5F85E061E for ; Fri, 15 Apr 2011 19:16:53 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3G2GnZ1080665; Fri, 15 Apr 2011 22:16:49 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104160216.p3G2GnZ1080665@harbor.orleans.occnc.com> To: Jakob Heitz From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Apr 2011 17:33:59 EDT." <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs.ericsson.se> Date: Fri, 15 Apr 2011 22:16:49 -0400 Sender: curtis@occnc.com Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 02:16:54 -0000 In message <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs.ericsson.se> Jakob Heitz writes: > > I'll support it if you change the maximum to 65279 (0xfeff). > > -- > Jakob Heitz. How about send 65279 (0xfeff), and be capabile of receiving 65535 (0xffff)? Curtis > > -----Original Message----- > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On > > Behalf Of Keyur Patel > > Sent: Friday, April 15, 2011 2:16 PM > > To: idr@ietf.org; Randy Bush > > Subject: Re: [Idr] New Version Notification for > > draft-ymbk-bgp-extended-messages-02 > > > > Folks, > > > > Rev 2 of the draft makes the Extended message capability > > symmetrical. With > > that change, authors of this draft document would like to propose the > > adoption of this work as IDR WG item. > > > > Regards, > > Keyur > > > > > > > > On 4/14/11 5:59 PM, "Randy Bush" wrote: > > > > > A new version of I-D, > > draft-ymbk-bgp-extended-messages-02.txt has been > > > successfully submitted by Randy Bush and posted to the IETF > > repository. > > > > > > Filename: draft-ymbk-bgp-extended-messages > > > Revision: 02 > > > Title: Extended Message support for BGP > > > Creation_date: 2011-04-15 > > > WG ID: Independent Submission > > > Number_of_pages: 5 > > > > > > Abstract: > > > The current 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 > > > draft provides an extension for BGP to extend its current message > > > size for BGP messages from 4096 octets to 65535 octets. > > > > > > > > > > > > The IETF Secretariat. From jakob.heitz@ericsson.com Fri Apr 15 20:01:25 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 94BB4E06B0 for ; Fri, 15 Apr 2011 20:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.468 X-Spam-Level: X-Spam-Status: No, score=-5.468 tagged_above=-999 required=5 tests=[AWL=1.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xbOfMfYqLfd for ; Fri, 15 Apr 2011 20:01:24 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id B9C34E06AC for ; Fri, 15 Apr 2011 20:01:24 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3G31MZc031960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Apr 2011 22:01:22 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 15 Apr 2011 23:01:21 -0400 From: Jakob Heitz To: "curtis@occnc.com" Date: Fri, 15 Apr 2011 23:01:18 -0400 Thread-Topic: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 Thread-Index: Acv73Fw18N+uZhJ4QSSID5pu6ss9dAABZr8g Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6159@EUSAACMS0701.eamcs.ericsson.se> References: Your message of "Fri, 15 Apr 2011 17:33:59 EDT." <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs.ericsson.se> <201104160216.p3G2GnZ1080665@harbor.orleans.occnc.com> In-Reply-To: <201104160216.p3G2GnZ1080665@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 03:01:25 -0000 No. Then my robustness goes away. Say message 1 had the wrong length. I don't detect it. Then message 2 breaks. I send a notification for malformed message, including message 2. This will confuse the debugging effort, because the real problem was message 1. It's a small thing, but then 256 bytes in 65535 is also a small thing. -- Jakob Heitz. =20 > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com]=20 > Sent: Friday, April 15, 2011 7:17 PM > To: Jakob Heitz > Cc: Keyur Patel; idr@ietf.org; Randy Bush > Subject: Re: [Idr] New Version Notification for=20 > draft-ymbk-bgp-extended-messages-02=20 >=20 >=20 > In message=20 > <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs .ericsson.se> > Jakob Heitz writes: > > =20 > > I'll support it if you change the maximum to 65279 (0xfeff). > > =20 > > -- > > Jakob Heitz. >=20 >=20 > How about send 65279 (0xfeff), and be capabile of receiving 65535 > (0xffff)? >=20 > Curtis >=20 >=20 > > > -----Original Message----- > > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > > > Behalf Of Keyur Patel > > > Sent: Friday, April 15, 2011 2:16 PM > > > To: idr@ietf.org; Randy Bush > > > Subject: Re: [Idr] New Version Notification for=20 > > > draft-ymbk-bgp-extended-messages-02 > > >=20 > > > Folks, > > >=20 > > > Rev 2 of the draft makes the Extended message capability=20 > > > symmetrical. With > > > that change, authors of this draft document would like to=20 > propose the > > > adoption of this work as IDR WG item. > > >=20 > > > Regards, > > > Keyur > > >=20 > > >=20 > > >=20 > > > On 4/14/11 5:59 PM, "Randy Bush" wrote: > > >=20 > > > > A new version of I-D,=20 > > > draft-ymbk-bgp-extended-messages-02.txt has been > > > > successfully submitted by Randy Bush and posted to the IETF=20 > > > repository. > > > >=20 > > > > Filename: draft-ymbk-bgp-extended-messages > > > > Revision: 02 > > > > Title: Extended Message support for BGP > > > > Creation_date: 2011-04-15 > > > > WG ID: Independent Submission > > > > Number_of_pages: 5 > > > >=20 > > > > Abstract: > > > > The current BGP specification mandates a maximum BGP=20 > message size of > > > > 4096 octets. As BGP is extended to support newer=20 > > > AFI/SAFIs, there is > > > > a need to extend the maximum message size beyond 4096=20 > octets. This > > > > draft provides an extension for BGP to extend its=20 > current message > > > > size for BGP messages from 4096 octets to 65535 octets. > > > > =20 > > > >=20 > > > >=20 > > > > The IETF Secretariat. > = From randy@psg.com Fri Apr 15 20:13:24 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 61248E06C3 for ; Fri, 15 Apr 2011 20:13:24 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hk7+c0Ky8LD for ; Fri, 15 Apr 2011 20:13:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id CF2F0E06AC for ; Fri, 15 Apr 2011 20:13:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAvwj-000FLe-Cp; Sat, 16 Apr 2011 03:13:17 +0000 Date: Sat, 16 Apr 2011 12:13:38 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6159@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs.ericsson.se> <201104160216.p3G2GnZ1080665@harbor.orleans.occnc.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6159@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 03:13:24 -0000 > Say message 1 had the wrong length. I don't detect it. > Then message 2 breaks. I send a notification for malformed message, > including message 2. This will confuse the debugging effort, > because the real problem was message 1. what happens if it is ten times around? people don't seem to get it. the bgp message is X. if you need more for something else, make something else larger. use X+20k or whatever. randy From jakob.heitz@ericsson.com Fri Apr 15 21:04:36 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8585FE06C7 for ; Fri, 15 Apr 2011 21:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1SXmVXSOZ6I for ; Fri, 15 Apr 2011 21:04:35 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 9ABEBE06C4 for ; Fri, 15 Apr 2011 21:04:35 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3G44XC5000819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Apr 2011 23:04:33 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 16 Apr 2011 00:04:33 -0400 From: Jakob Heitz To: Randy Bush Date: Sat, 16 Apr 2011 00:04:32 -0400 Thread-Topic: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 Thread-Index: Acv75D7aNOb7ajPvS6GO4Iti985bgwABsfLw Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D615D@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs.ericsson.se> <201104160216.p3G2GnZ1080665@harbor.orleans.occnc.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6159@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 04:04:36 -0000 Your point is that it's senseless to try to fit the whole message into the error message. I get that point. Now, do you get mine? Never mind if you agree with it or not, do you get it? -- Jakob Heitz. =20 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com]=20 > Sent: Friday, April 15, 2011 8:14 PM > To: Jakob Heitz > Cc: curtis@occnc.com; Keyur Patel; idr@ietf.org > Subject: Re: [Idr] New Version Notification for=20 > draft-ymbk-bgp-extended-messages-02=20 >=20 > > Say message 1 had the wrong length. I don't detect it. > > Then message 2 breaks. I send a notification for malformed message, > > including message 2. This will confuse the debugging effort, > > because the real problem was message 1. >=20 > what happens if it is ten times around? >=20 > people don't seem to get it. the bgp message is X. if you need more > for something else, make something else larger. use X+20k or=20 > whatever. >=20 > randy > = From randy@psg.com Fri Apr 15 21:06:50 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 14DFCE06CB for ; Fri, 15 Apr 2011 21:06:50 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Gd6zpaDD16n for ; Fri, 15 Apr 2011 21:06:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 83810E06C7 for ; Fri, 15 Apr 2011 21:06:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAwmU-000FVi-NZ; Sat, 16 Apr 2011 04:06:47 +0000 Date: Sat, 16 Apr 2011 13:07:07 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D615D@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs.ericsson.se> <201104160216.p3G2GnZ1080665@harbor.orleans.occnc.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6159@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21390E3F8D615D@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 04:06:50 -0000 > Your point is that it's senseless to try to > fit the whole message into the error message. no. my point is that your error message is not a bgp message. so you can make it some other arbitrary [ larger ] size. randy From jsw@inconcepts.biz Fri Apr 15 21:23:36 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 29543E06C4 for ; Fri, 15 Apr 2011 21:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Xl71F0zLAH9 for ; Fri, 15 Apr 2011 21:23:35 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 284DFE06C7 for ; Fri, 15 Apr 2011 21:23:34 -0700 (PDT) Received: by vws12 with SMTP id 12so3156575vws.31 for ; Fri, 15 Apr 2011 21:23:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.176.98 with SMTP id ch2mr1793981vdc.51.1302927814412; Fri, 15 Apr 2011 21:23:34 -0700 (PDT) Received: by 10.220.177.11 with HTTP; Fri, 15 Apr 2011 21:23:34 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs.ericsson.se> <201104160216.p3G2GnZ1080665@harbor.orleans.occnc.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6159@EUSAACMS0701.eamcs.ericsson.se> Date: Sat, 16 Apr 2011 00:23:34 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 04:23:36 -0000 On Fri, Apr 15, 2011 at 11:13 PM, Randy Bush wrote: > what happens if it is ten times around? This is a solved problem. Obviously a diagnostic notification may not be sent in response to a corrupt diagnostic notification. > people don't seem to get it. =A0the bgp message is X. =A0if you need more > for something else, make something else larger. =A0use X+20k or whatever. Which of these things is more valuable to you, Randy? 1) maximum BGP message size being 19 bytes larger; or 2) receiving a diagnostic message if the neighbor is unable to parse a malformed message On Sat, Apr 16, 2011 at 12:07 AM, Randy Bush wrote: > no. =A0my point is that your error message is not a bgp message. =A0so yo= u > can make it some other arbitrary [ larger ] size. If this were true, the options would be: 1) define a completely new protocol and establish a new session to the neighbors for diagnostic messaging 2) mux a second protocol into the same TCP session as BGP 3) extend the BGP parser to recognize that a specific message type has a larger length field than 2-octets Fortunately, the truth is a choice can easily be made to allow head-room for diagnostic outer-message headers within the already-defined 2-octet length field, without employing any of the bad options above. I object to your reasoning and the current draft. There is very clear value to both of Jakob's outstanding suggestions. You have failed to demonstrate how either of them may have any cost at all, aside from reducing the available BGP message payload by 0.4% at a juncture when the proposed change is increasing it by more than an order of magnitude. If you can't afford to sacrifice a few octets for these valuable features, you need to ask for much more than 65535 bytes anyway. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From keyupate@cisco.com Fri Apr 15 21:56:02 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 44F52E0682 for ; Fri, 15 Apr 2011 21:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.383 X-Spam-Level: X-Spam-Status: No, score=-10.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSxajHM2QBlt for ; Fri, 15 Apr 2011 21:56:01 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 2205FE0677 for ; Fri, 15 Apr 2011 21:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=2861; q=dns/txt; s=iport; t=1302929761; x=1304139361; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=2nM1bDzpY8m6SRbICDC1iGtAdelw8QAlKSatujbQyYg=; b=aq61Ph1L7BYqiAR5d/N+yOrSDLaNqzXzwiQyPXIfKJYnXa99wXOvAhVB oxyP6KM6IHiC6AGmM0COi9JDEOrYwtBr+LPlBfjZb+mI16DUyzugVjoN1 QuilyIZGIOQJuyUO3SfQMqpn5RBLO2dcYoCYNU1cmP4iLDeARS01XSarb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAMMgqU2rRDoH/2dsb2JhbACYEY1+d4hvnxedA4RggQ4EhWGIGYN7 X-IronPort-AV: E=Sophos;i="4.64,223,1301875200"; d="scan'208";a="295737675" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 16 Apr 2011 04:56:00 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3G4u0lI011620; Sat, 16 Apr 2011 04:56:00 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 21:56:00 -0700 Received: from 10.21.77.69 ([10.21.77.69]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.114]) with Microsoft Exchange Server HTTP-DAV ; Sat, 16 Apr 2011 04:55:59 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 15 Apr 2011 21:55:22 -0700 From: Keyur Patel To: Jakob Heitz , "curtis@occnc.com" Message-ID: Thread-Topic: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 Thread-Index: Acv73Fw18N+uZhJ4QSSID5pu6ss9dAABZr8gAAQhobQ= In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6159@EUSAACMS0701.eamcs.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Apr 2011 04:56:00.0115 (UTC) FILETIME=[946EFC30:01CBFBF2] Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 04:56:02 -0000 On 4/15/11 8:01 PM, "Jakob Heitz" wrote: > No. Then my robustness goes away. > > Say message 1 had the wrong length. I don't detect it. > Then message 2 breaks. I send a notification for malformed message, > including message 2. This will confuse the debugging effort, > because the real problem was message 1. You cant deterministically figure this out ever for all cases. Depending on an error case you MAY end up sending 2nd message in notification. Reserving a byte is useless for such a case. Regards, Keyur > > It's a small thing, but then 256 bytes in 65535 is also a small thing. > > -- > Jakob Heitz. > > >> -----Original Message----- >> From: curtis@occnc.com [mailto:curtis@occnc.com] >> Sent: Friday, April 15, 2011 7:17 PM >> To: Jakob Heitz >> Cc: Keyur Patel; idr@ietf.org; Randy Bush >> Subject: Re: [Idr] New Version Notification for >> draft-ymbk-bgp-extended-messages-02 >> >> >> In message >> <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs > .ericsson.se> >> Jakob Heitz writes: >>> >>> I'll support it if you change the maximum to 65279 (0xfeff). >>> >>> -- >>> Jakob Heitz. >> >> >> How about send 65279 (0xfeff), and be capabile of receiving 65535 >> (0xffff)? >> >> Curtis >> >> >>>> -----Original Message----- >>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On >>>> Behalf Of Keyur Patel >>>> Sent: Friday, April 15, 2011 2:16 PM >>>> To: idr@ietf.org; Randy Bush >>>> Subject: Re: [Idr] New Version Notification for >>>> draft-ymbk-bgp-extended-messages-02 >>>> >>>> Folks, >>>> >>>> Rev 2 of the draft makes the Extended message capability >>>> symmetrical. With >>>> that change, authors of this draft document would like to >> propose the >>>> adoption of this work as IDR WG item. >>>> >>>> Regards, >>>> Keyur >>>> >>>> >>>> >>>> On 4/14/11 5:59 PM, "Randy Bush" wrote: >>>> >>>>> A new version of I-D, >>>> draft-ymbk-bgp-extended-messages-02.txt has been >>>>> successfully submitted by Randy Bush and posted to the IETF >>>> repository. >>>>> >>>>> Filename: draft-ymbk-bgp-extended-messages >>>>> Revision: 02 >>>>> Title: Extended Message support for BGP >>>>> Creation_date: 2011-04-15 >>>>> WG ID: Independent Submission >>>>> Number_of_pages: 5 >>>>> >>>>> Abstract: >>>>> The current 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 >>>>> draft provides an extension for BGP to extend its >> current message >>>>> size for BGP messages from 4096 octets to 65535 octets. >>>>> >>>>> >>>>> >>>>> The IETF Secretariat. >> From paul@jakma.org Sat Apr 16 04:10:06 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 82A1EE066F for ; Sat, 16 Apr 2011 04:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gSTeQyP4sCv for ; Sat, 16 Apr 2011 04:10:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id C6E98E066E for ; Sat, 16 Apr 2011 04:10:04 -0700 (PDT) Received: by wwa36 with SMTP id 36so2728517wwa.13 for ; Sat, 16 Apr 2011 04:10:03 -0700 (PDT) Received: by 10.227.195.75 with SMTP id eb11mr3106255wbb.120.1302952203459; Sat, 16 Apr 2011 04:10:03 -0700 (PDT) Received: from stoner.jakma.org (stoner.jakma.org [81.168.24.42]) by mx.google.com with ESMTPS id y29sm2113444wbd.38.2011.04.16.04.10.01 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Apr 2011 04:10:02 -0700 (PDT) Date: Sat, 16 Apr 2011 12:09:58 +0100 (BST) From: Paul Jakma To: Randy Bush In-Reply-To: Message-ID: References: <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6094@EUSAACMS0701.eamcs.ericsson.se> <201104160216.p3G2GnZ1080665@harbor.orleans.occnc.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F8D6159@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21390E3F8D615D@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 11:10:06 -0000 On Sat, 16 Apr 2011, Randy Bush wrote: > no. my point is that your error message is not a bgp message. so you > can make it some other arbitrary [ larger ] size. Can you elaborate? Do you mean we'd have to have a new draft to a different message format from the standard/extended BGP message format? (That format would have to have to either have a 'dummy' BGP message header with a special type, or else we'd have to change the BGP message marker to effectively use it as a distinguishing type). Then we'd have 2 message formats - BGP messages and not-BGP messages? Or if you mean something else? regards, -- Paul Jakma paul@jakma.org @pjakma Key ID: 64A2FF6A Fortune: You will be run over by a bus. From john@jlc.net Sat Apr 16 05:31:56 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 51FA4E0675 for ; Sat, 16 Apr 2011 05:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.309 X-Spam-Level: X-Spam-Status: No, score=-106.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzrsV+w6pM2K for ; Sat, 16 Apr 2011 05:31:55 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfc.amsl.com (Postfix) with ESMTP id 8B8AFE0613 for ; Sat, 16 Apr 2011 05:31:55 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 127A633C2A; Sat, 16 Apr 2011 08:31:55 -0400 (EDT) Date: Sat, 16 Apr 2011 08:31:55 -0400 From: John Leslie To: Randy Bush Message-ID: <20110416123154.GA64981@verdi> References: <201104152104.p3FL4JK6075718@harbor.orleans.occnc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 12:31:56 -0000 Randy Bush wrote: > > you may want to read the current draft Presumably Randy refers to: ] ] To advertise BGP Extended Message Capability to a peer, a BGP speaker ] uses BGP Capadbilities Advertisement [RFC3392]. By advertising the ] BGP Extended message Capability to a peer, a BGP speaker conveys to ] that peer that the speaker may send, and is capable of receiving and ] properly handling, BGP Extended Messages. I really dislike this new "speaker may send" language. (I have no problem requiring the capability be symmetric; it's the "may" I dislike.) The capability being advertised is receiving and handling extended length. If I understand correctly, we mean to require that a speaker advertising this capability MUST also be able to send extended length (though I'm less than clear how we could tell). "may send" doesn't convey that, and puts us in the MUSTard-land of "what does lower-case 'may' mean?" Also, it's too easy to misinterpret to suggest this speaker might send extended-length without waiting for receipt of the same advertisement from its peer. (Yes, one would have to be clue-challenged to think that; but I keep meeting folks that clue-challenged: why invite the problem?) I suggest language closer to "capable of both receiving and sending BGP Extended Messages". -- John Leslie From rjs@rob.sh Sat Apr 16 09:09:37 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 001A3E069A for ; Sat, 16 Apr 2011 09:09:36 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJzwLaJlphZU for ; Sat, 16 Apr 2011 09:09:36 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfc.amsl.com (Postfix) with ESMTP id 41100E066B for ; Sat, 16 Apr 2011 09:09:35 -0700 (PDT) Received: from [86.2.91.228] (helo=[10.0.0.105]) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1QB83r-0001qQ-51; Sat, 16 Apr 2011 17:09:28 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: Date: Sat, 16 Apr 2011 17:09:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110415005809.E1BBBE06BC@ietfc.amsl.com> To: "idr@ietf.org List" X-Mailer: Apple Mail (2.1082) Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 16:09:37 -0000 On 15 Apr 2011, at 01:59, Randy Bush wrote: > A new version of I-D, draft-ymbk-bgp-extended-messages-02.txt has been > successfully submitted by Randy Bush and posted to the IETF = repository. >=20 > Filename: draft-ymbk-bgp-extended-messages > Revision: 02 > Title: Extended Message support for BGP > Creation_date: 2011-04-15 > WG ID: Independent Submission > Number_of_pages: 5 Hi IDR, I'd like to add my support for the request for adoption for this draft. I'm somewhat confused by the arguments as to why we gain any advantage = from the maximum message length being <65535. If the length of the = message is specified incorrectly, such that the actual message is = smaller than the length being specified - I can't see how this is = recoverable. For any arbitrary length if the actual length is smaller = than the specified one, it seems to me that we will have some overlap = into the following message. Reviewing the two threads, I didn't find a clear technical justification = for requests for the maximum size being smaller. I'm not sure whether = others agree, but I would appreciate a succinct technical summary of = this requirement for those of us that do not directly develop BGP = implementations please? In addition, we seem to have strayed away from the key point here. What = we are trying to agree here is that there is a requirement for a message = length >4K, as such, this is really what the draft now specifies (the = symmetry discussions have been resolved). It's on this basis that I = support the WG adoption, as the information relayed to us by the SIDR WG = appears to indicate a clear requirement for this message size for (at = least) this application. My opinion is that the following statement: Applications generating messages which might be encapsulated within BGP messages MUST limit the size of their payload to take into account the maximum message size and all encapsulation overheads on the path the encapsulated data are expected to traverse. gives guidance for the other issues discussed (e.g. encapsulation), but = this standard does not specify any means by which encapsulation will = occur, this is within the realm of other documents. As such, these = drafts should ensure that they specify behaviour such that their = intention is compatible with a fixed maximum message size in BGP, no = matter what this value should be. Kind regards, r. From housley@vigilsec.com Sat Apr 16 11:17:09 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70C1CE0708 for ; Sat, 16 Apr 2011 11:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MulnVTTiZG-9 for ; Sat, 16 Apr 2011 11:17:08 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfc.amsl.com (Postfix) with ESMTP id B37B0E0681 for ; Sat, 16 Apr 2011 11:17:02 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D5930F240C0 for ; Sat, 16 Apr 2011 14:17:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 7rCIbznEoHm0 for ; Sat, 16 Apr 2011 14:17:01 -0400 (EDT) Received: from [192.168.2.101] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id F3EA0F24099 for ; Sat, 16 Apr 2011 14:17:03 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 16 Apr 2011 14:17:00 -0400 Message-Id: To: idr@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 18:17:09 -0000 I'll support adoption of this draft by the IDR WG. Russ > From: ... On Behalf Of Keyur Patel > Sent: Friday, April 15, 2011 2:16 PM > To: idr at ietf.org; Randy Bush > Subject: Re: [Idr] New Version Notification for > draft-ymbk-bgp-extended-messages-02 > > Folks, > > Rev 2 of the draft makes the Extended message capability > symmetrical. With > that change, authors of this draft document would like to propose the > adoption of this work as IDR WG item. > > Regards, > Keyur > > > > On 4/14/11 5:59 PM, "Randy Bush" wrote: > > > A new version of I-D, > draft-ymbk-bgp-extended-messages-02.txt has been > > successfully submitted by Randy Bush and posted to the IETF > repository. > > > > Filename: draft-ymbk-bgp-extended-messages > > Revision: 02 > > Title: Extended Message support for BGP > > Creation_date: 2011-04-15 > > WG ID: Independent Submission > > Number_of_pages: 5 > > > > Abstract: > > The current 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 > > draft provides an extension for BGP to extend its current message > > size for BGP messages from 4096 octets to 65535 octets. > > > > > > > > The IETF Secretariat. From warren@kumari.net Sat Apr 16 13:13:49 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C92E6E074F for ; Sat, 16 Apr 2011 13:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQDTJ9oTd3go for ; Sat, 16 Apr 2011 13:13:49 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfc.amsl.com (Postfix) with ESMTP id 2122FE065F for ; Sat, 16 Apr 2011 13:13:48 -0700 (PDT) Received: from [172.19.118.249] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id EA2621B412A7; Sat, 16 Apr 2011 16:13:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Sat, 16 Apr 2011 16:13:41 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: Keyur Patel X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 20:13:49 -0000 I have read this draft and strongly support adoption as a WG item... W On Apr 15, 2011, at 5:16 PM, Keyur Patel wrote: > Folks, > > Rev 2 of the draft makes the Extended message capability symmetrical. With > that change, authors of this draft document would like to propose the > adoption of this work as IDR WG item. > > Regards, > Keyur > > > > On 4/14/11 5:59 PM, "Randy Bush" wrote: > >> A new version of I-D, draft-ymbk-bgp-extended-messages-02.txt has been >> successfully submitted by Randy Bush and posted to the IETF repository. >> >> Filename: draft-ymbk-bgp-extended-messages >> Revision: 02 >> Title: Extended Message support for BGP >> Creation_date: 2011-04-15 >> WG ID: Independent Submission >> Number_of_pages: 5 >> >> Abstract: >> The current 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 >> draft provides an extension for BGP to extend its current message >> size for BGP messages from 4096 octets to 65535 octets. >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From randy@psg.com Sat Apr 16 15:35:31 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C9E78E0751 for ; Sat, 16 Apr 2011 15:35:31 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk1k5ia8Z+MT for ; Sat, 16 Apr 2011 15:35:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 46382E0674 for ; Sat, 16 Apr 2011 15:35:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QBE5P-000Iso-FY; Sat, 16 Apr 2011 22:35:28 +0000 Date: Sun, 17 Apr 2011 07:35:49 +0900 Message-ID: From: Randy Bush To: Rob Shakir In-Reply-To: References: <20110415005809.E1BBBE06BC@ietfc.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org List" Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 22:35:31 -0000 > the symmetry discussions have been resolved well, i am less sure. the first stickler for proper conformance has written to me privately. rfc 3392 section 3 sure looks asymmetric. randy From jakob.heitz@ericsson.com Sat Apr 16 16:34:34 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3BCCEE0691 for ; Sat, 16 Apr 2011 16:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.619 X-Spam-Level: X-Spam-Status: No, score=-5.619 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZnkt5Qn-sWV for ; Sat, 16 Apr 2011 16:34:33 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 880E8E0674 for ; Sat, 16 Apr 2011 16:34:33 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3GNYV8B014076; Sat, 16 Apr 2011 18:34:32 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sat, 16 Apr 2011 19:34:25 -0400 From: Jakob Heitz To: Randy Bush Date: Sat, 16 Apr 2011 19:34:29 -0400 Thread-Topic: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 Thread-Index: Acv8jtJSJrSrLG4MSGOUnG05odU/Yg== Message-ID: <3A36CD51-B2AF-4654-8F68-B07B0236AB57@ericsson.com> References: <20110415005809.E1BBBE06BC@ietfc.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 23:34:34 -0000 My hold timer just went off. Oh, I had an error burst in my line and TCP ch= oked to a crawl. By the time it recovered enough to send that 65535 byte me= ssage, it was too late. Could we please modify the hold timer rule to reset the timer not when a me= ssage arrives on the socket, but every time anything arrives. -- Jakob Heitz. On Apr 14, 2011, at 5:59 PM, "Randy Bush" wrote: > A new version of I-D, draft-ymbk-bgp-extended-messages-02.txt has been > successfully submitted by Randy Bush and posted to the IETF repository. >=20 > Filename: draft-ymbk-bgp-extended-messages > Revision: 02 > Title: Extended Message support for BGP > Creation_date: 2011-04-15 > WG ID: Independent Submission > Number_of_pages: 5 >=20 > Abstract: > The current 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 > draft provides an extension for BGP to extend its current message > size for BGP messages from 4096 octets to 65535 octets. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jhaas@slice.pfrc.org Sun Apr 17 06:17:00 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E027FE0767 for ; Sun, 17 Apr 2011 06:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.335 X-Spam-Level: X-Spam-Status: No, score=-101.335 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qChm1yRBUKgo for ; Sun, 17 Apr 2011 06:17:00 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id 7E53FE074A for ; Sun, 17 Apr 2011 06:17:00 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2E9272241E9; Sun, 17 Apr 2011 13:17:00 +0000 (UTC) Date: Sun, 17 Apr 2011 13:17:00 +0000 From: Jeffrey Haas To: Randy Bush Message-ID: <20110417131700.GC11808@slice> References: <20110415005809.E1BBBE06BC@ietfc.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 13:17:01 -0000 On Fri, Apr 15, 2011 at 09:59:15AM +0900, Randy Bush wrote: > A new version of I-D, draft-ymbk-bgp-extended-messages-02.txt has been > successfully submitted by Randy Bush and posted to the IETF repository. > > Filename: draft-ymbk-bgp-extended-messages > Revision: 02 > Title: Extended Message support for BGP I would like to support adoption of this draft as a WG item. I believe that we have good consensus that this is something we want to work on even if some of the details still need to be addressed. -- Jeff From jhaas@slice.pfrc.org Sun Apr 17 06:23:46 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3C96DE074A for ; Sun, 17 Apr 2011 06:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKmjbpO6x4f8 for ; Sun, 17 Apr 2011 06:23:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id C220BE0694 for ; Sun, 17 Apr 2011 06:23:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9EC472241E8; Sun, 17 Apr 2011 13:23:45 +0000 (UTC) Date: Sun, 17 Apr 2011 13:23:45 +0000 From: Jeffrey Haas To: Jakob Heitz Message-ID: <20110417132345.GD11808@slice> References: <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: idr Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 13:23:46 -0000 Jakob, On Sun, Apr 10, 2011 at 02:15:21PM -0400, Jakob Heitz wrote: > The length field follows the marker. If the first byte of the length field can be 0xff, it reduces the value of the marker. The value of the marker is to validate the beginning of a message. This is good both in protocol operation as well as for debugging. > > To preserve the value of the marker, I propose the maximum message length to be 65279 (0xfeff). While I strongly sympathize with the usefulness of the marker field for purposes of re-detecting lost framing in BGP PDUs in a TCP stream, I think the property you're really looking for is predictability of value. As such, I don't think we want to preclude any particular value for the message length. As an observation, the message type is a well constrained value that is unlikely to ever jump over 128 for hopefully most of our lifetimes. This should assist in the necessary bit pattern matches you might be looking for. As another observation, the marker field is an appropriate place for any UPDATE sequence numbering should we ever decide to use such a mechanism for one of our recovery mechanisms for bad BGP UPDATEs. (This has been mostly IETF hallway conversation rather than any formal proposal at this time.) -- Jeff From raszuk@cisco.com Sun Apr 17 06:55:38 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 35D46E074A for ; Sun, 17 Apr 2011 06:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT8Rp5f902UV for ; Sun, 17 Apr 2011 06:55:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 3744BE0675 for ; Sun, 17 Apr 2011 06:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=703; q=dns/txt; s=iport; t=1303048537; x=1304258137; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=d0B28HOe2X0nOPSSITOG4k8X4077/V56QP7Kw0BD4lk=; b=AGMVXCne7oEQcyQKRxFSWArqkYJUjCnGgHy2bBkcJ/FIWFw5RIlGA2Po WmbQ73r2aSdmMalZ9nGCYA18YOLRnPfCYDC1/9s5JuUpmwJy8tdL9hKEq eeA0dnfS9bCx6kcW6M1rg8H9Ns0Qj40ZnyFiMa4/lR7ReZrwn/Vc84KXV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkHAAzxqk2rRDoI/2dsb2JhbACYT41Bd4hvnzGCdA4BmBSFcQSOA4N1 X-IronPort-AV: E=Sophos;i="4.64,227,1301875200"; d="scan'208";a="339247785" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 17 Apr 2011 13:55:36 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3HDtZ9k005322 for ; Sun, 17 Apr 2011 13:55:36 GMT Message-ID: <4DAAF160.8040306@cisco.com> Date: Sun, 17 Apr 2011 15:55:44 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: idr@ietf.org References: <20110415005809.E1BBBE06BC@ietfc.amsl.com> <20110417131700.GC11808@slice> In-Reply-To: <20110417131700.GC11808@slice> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 13:55:38 -0000 +1 R. > On Fri, Apr 15, 2011 at 09:59:15AM +0900, Randy Bush wrote: >> A new version of I-D, draft-ymbk-bgp-extended-messages-02.txt has been >> successfully submitted by Randy Bush and posted to the IETF repository. >> >> Filename: draft-ymbk-bgp-extended-messages >> Revision: 02 >> Title: Extended Message support for BGP > > I would like to support adoption of this draft as a WG item. > > I believe that we have good consensus that this is something we want to work > on even if some of the details still need to be addressed. > > -- Jeff > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From jhaas@slice.pfrc.org Sun Apr 17 06:57:48 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 54EE9E0774 for ; Sun, 17 Apr 2011 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8Riu+W7iMN8 for ; Sun, 17 Apr 2011 06:57:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id ABCA4E068E for ; Sun, 17 Apr 2011 06:57:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9ECC6134004; Sun, 17 Apr 2011 13:57:47 +0000 (UTC) Date: Sun, 17 Apr 2011 13:57:47 +0000 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20110417135747.GE11808@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Idr] Filing down the rough edges of draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 13:57:48 -0000 WG, This thread is my attempt to try to centralize some of the known rough edges of this draft with respect to RFC 4271 et al. updates. If possible, I'd like to suggest that the issue of the maximum send and receive size remain in a separate thread since that is still contentious enough to require separate tracking. Jakob Heitz brought up the point that our holdtimers can't be measured by the receipt of the start of the received packet. While I hate to say it, this has implications on the RFC 4271 FSM especially with regards to the TCP state machine. :-/ In particular, the text in section 8 is TCP framing unaware. This was an issue in the original text and no one really wanted to make complicated text any worse. But the implication is that events that rely on receiving a given message such as an UPDATE are only supposed to succeed when you've parsed a valid message. A slow peer sending down a 4k UPDATE a few byte in each TCP segment at a time would already cause problem. Such slow peers will be a bigger problem spec-wise. (It's my personal opinion that it starts becoming a matter of local choice how this issue is dealt with. You can either choose to be pedantic about the spec and risk sessions bouncing on aggressive timers when you have a sluggish peer or you can risk keeping alive a bad session when you slip your timers based on any I/O.) Constraints on variable sized lists: Like it or not, the 4k message size provided a nice upper bound to certain types of foolishness. As one example, the AS_PATH could never be longer than what could be maximimally packed into a 4k UPDATE with a single prefix, message overhead and minimal path attributes needed for iBGP. It's my belief that many implementations have an upper bound on this length as well. Such constraints also applied to things like communities and extended communities. It's my belief that for regular communities, current operational practices tend to constrain the number of communities attached to a route within a service provider. But as already mentioned, for extended communities - particularly route targets - this has been a scaling issue for certain types of deployments. While outside of 4271, Route Reflection Cluster Lists are also variably sized. Route selection and loop detection will generally provide an upper bound on this value. It should be considered whether we want to place any types of upper bounds on such lists and whether such limits should be required for new drafts that contain variable sized lists. Formal changes for RFC 4271 (tedious bookkeeping): Note section 6.1 and that the value should be 65535 when the capability is negotiated. Error handling: Depending on the resolution of the thread on maximum send/receive message sizes, we may need a slightly more precise NOTIFICATION code for lengths than "Bad message length". This will somewhat depend on whether the semantics of the extended message draft require a MUST support 65k messages when negotiated or not. The draft is currently silent on this (yes, a nit). -- Jeff From jhaas@slice.pfrc.org Sun Apr 17 07:07:40 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 91F97E06BF for ; Sun, 17 Apr 2011 07:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.033 X-Spam-Level: X-Spam-Status: No, score=-102.033 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2IgUtCHz9Ej for ; Sun, 17 Apr 2011 07:07:40 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id 138EBE06B9 for ; Sun, 17 Apr 2011 07:07:40 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DBE1B2240C8; Sun, 17 Apr 2011 14:07:39 +0000 (UTC) Date: Sun, 17 Apr 2011 14:07:39 +0000 From: Jeffrey Haas To: Rob Shakir Message-ID: <20110417140739.GF11808@slice> References: <20110415005809.E1BBBE06BC@ietfc.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "idr@ietf.org List" Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 14:07:40 -0000 On Sat, Apr 16, 2011 at 05:09:25PM +0100, Rob Shakir wrote: > My opinion is that the following statement: > > Applications generating messages which might be encapsulated within > BGP messages MUST limit the size of their payload to take into > account the maximum message size and all encapsulation overheads on > the path the encapsulated data are expected to traverse. > > gives guidance for the other issues discussed (e.g. encapsulation), but this standard does not specify any means by which encapsulation will occur, this is within the realm of other documents. As such, these drafts should ensure that they specify behaviour such that their intention is compatible with a fixed maximum message size in BGP, no matter what this value should be. I also am generally concerned by this issue. My suspicion is that in many cases a transition mechanism that can't rely on "discard unnecessary state to fit into 4k" will make theoretical features undeployable. What are we going to do, have a tunnel attribute that splits up jumbo-UPDATE into multiple sequence numbered UPDATEs that have to be reassembled by a given downstream from who knows how many copies of the UPDATE? Path selection will make that rather painful. While I expect the detail of the draft concerning MUST support sizes when the capability is negotiated to be dealt with, a consequence of a MAY would be unknowable downstream path sizes. I don't expect this to be a real issue for some time. The two scenarios that extended message sizes immediately address are both appropriately scoped to not have this problem: 1. SIDR routes can simply drop the necessary path attributes when speaking to a non-compliant speaker. The semantics of this have to be dealt with in the SIDR drafts anyway. 2. Large VPN membership is mostly scoped to within a given AS or at least a subset of the AS. VPN route reflector deployments already allow for disjoint reflectors to be deployed for scalability purposes. -- Jeff From raszuk@cisco.com Sun Apr 17 07:26:44 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3AB39E06D9 for ; Sun, 17 Apr 2011 07:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rITxqxZmWXa7 for ; Sun, 17 Apr 2011 07:26:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 59990E0675 for ; Sun, 17 Apr 2011 07:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2337; q=dns/txt; s=iport; t=1303050403; x=1304260003; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=G7OpqxxilABnrpSP2jDQxdfZDjwHBLXiEw54aZZ3BT4=; b=NLVUydEHXfhS65dCM5lgMkZ1QcUgwfWMxyIG9f6ag+l0XFEerpd/zOMD bU5rGbYPctwlVacMdbNCmnv72t5EPH2CJFrviAygH547Bjd1+rqNN7i/v birChFGD9b2ZAuVibplx+cohY6RjBihd0CKnEdrJSJEjSjXkMIjxPQnmR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACb3qk2rRDoH/2dsb2JhbACmEHeoCYJ0DgGYEoVxBI4Dg3U X-IronPort-AV: E=Sophos;i="4.64,227,1301875200"; d="scan'208";a="682858864" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 17 Apr 2011 14:26:42 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3HEQfcK010628 for ; Sun, 17 Apr 2011 14:26:42 GMT Message-ID: <4DAAF8AA.6060303@cisco.com> Date: Sun, 17 Apr 2011 16:26:50 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "idr@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 14:26:44 -0000 Hi, Jakob and Jeff's emails triggered me to think if the overall approach here to extending all BGP messages size is the right one. Let's realize that: - To send 4096 octets msg on 10 Mbit/s wire takes 3.28 sec - To send 65535 octets msg on 10 Mbit/s wire takes 52.43 sec ! No congestion, no delays ... pure best case numbers. Now add to this time for acks, some router CPU delay, some I/O processing or worse some congestion or slow peer case and we are off the cliff. I like the summary Jeff sent indicating a real consequences for implicit bound on current BGP attributes. Do we want to redefine BGP spec and subsequent specs so fundamentally now to try only one proposal of available number of others in the BGP security area ? The answer I think is pretty obvious. So let me propose that all elements related to securing BGP would be contain in a new message all together. (Perhaps new SAFI perhaps not .. I am not sure yet). That would allow zero impact to Internet IPv4 and IPv6 routing as we know it today, gradual deployment etc ... Here one also needs to keep in mind that all additional AS signatures as proposed today would be duplicated or N-plicated for each AFI/SAFI individually. You would use the same space amount of information to sign IPv4 updates as IPv6 updates. Leave alone the encapsulation part .. but storing and processing the same thing many times seems to me like really waist. The open issues are how to couple the secure BGP message with normal BGP message if such coupling at all is needed. Even if we would duplicate MP_REACH_NLRI into such Secure messages it still seems worth. Another advantage is processing ... If we combine the secure BGP overhead with current BGP UPDATE message you like it or not it will have to be handled by today's old fashion general BGP CPU processing. But if this is defined as a separate message .. maybe even on separate session (by enforcing multisession on it) it could be all together easily processed by some other CPU/CPU core/programmable FPGA or ASIC without causing any burden and delay to current BGP processing. That would very nicely allow to decouple the functions and only pass final decision to main core BGP as prefix X - valid .. prefix Y - invalid. Many thx, R. From jhaas@slice.pfrc.org Sun Apr 17 07:51:15 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A8551E076A for ; Sun, 17 Apr 2011 07:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.079 X-Spam-Level: X-Spam-Status: No, score=-102.079 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrLiN9I1btQD for ; Sun, 17 Apr 2011 07:51:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id 21357E06FF for ; Sun, 17 Apr 2011 07:51:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0EC85134001; Sun, 17 Apr 2011 14:51:15 +0000 (UTC) Date: Sun, 17 Apr 2011 14:51:15 +0000 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20110417145115.GH11808@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Idr] draft-ymbk-bgp-extended-messages implications on TCP windows X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 14:51:15 -0000 Caveat: I'm not a TCP protocol expert nor do I play one at my employer. Like many people on this list, TCP looks like a socket to me and the majority of the pain I live with under TCP gets represented at the socket level. Support for extended messages probably should be predicated on support for TCP window scaling on the TCP session. Without this, the maximum TCP window size is 65k. While it's my belief that most current router stacks support this, the draft probably should note that requirement. This is a somewhat messy requirement since you either have to know that support is a priori there or be willing to have your BGP peering session capable of dynamically moving you from one peer group for 65k peers to one that isn't based on what TCP tells you is negotiated. Your implementation must also dynamically advertise the capability based on the TCP negotiation as well. What I'm a bit more concerned about isn't large window support as it is with the interaction of larger message sizes and one's peers. When an implementation slows down its read behavior for whatever reason, this is experienced as throttling at the TCP level and thus blocked writes at the sender. Implementations for efficiency sake often have hooks into TCP to watch for a given low water mark for purposes of even trying to do a write on the socket. To continue on Jakob Heitz's issue about hold timers expiring on slow reads, when one hooks into the TCP window state for purposes of determining whether one can write or not, one now has to consider the need for larger windows. We're unlikely to really require 65k packets. However, we'll probably want to change those marks for something bigger - perhaps 8-16k. I already see headaches in troubleshooting slow peers due to TCP stalling issues. This will only exacerbate some of them. How is this going to impact your implementation? -- Jeff From jhaas@slice.pfrc.org Sun Apr 17 08:08:44 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A536BE0777 for ; Sun, 17 Apr 2011 08:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.11 X-Spam-Level: X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u+cgGcGgkse for ; Sun, 17 Apr 2011 08:08:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id EA24AE0694 for ; Sun, 17 Apr 2011 08:08:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BE8952241E9; Sun, 17 Apr 2011 15:08:43 +0000 (UTC) Date: Sun, 17 Apr 2011 15:08:43 +0000 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20110417150843.GI11808@slice> References: <4DAAF8AA.6060303@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DAAF8AA.6060303@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "idr@ietf.org List" Subject: Re: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 15:08:44 -0000 Robert, On Sun, Apr 17, 2011 at 04:26:50PM +0200, Robert Raszuk wrote: > Jakob and Jeff's emails triggered me to think if the overall approach > here to extending all BGP messages size is the right one. > > Let's realize that: > > - To send 4096 octets msg on 10 Mbit/s wire takes 3.28 sec > - To send 65535 octets msg on 10 Mbit/s wire takes 52.43 sec ! > > No congestion, no delays ... pure best case numbers. I suspect you'll send your own correction soon, but I think you're off a few orders of magnitude. 4096 octets with a simplistic encoding of 10 bits to one octet on the wire (for simplicity) means we have 40960 (40kb). At a rate of 10Mbps, that's 0.0041 seconds to send the packet. I think it's fair to say that while BGP is TCP-bound with regard to some of its poor behavior, it's not link-bound unless we're still talking T1. :-) > Now add to this time for acks, some router CPU delay, some I/O > processing or worse some congestion or slow peer case and we are off the > cliff. Those are the sticky points. I've spawned a new thread specifically for TCP interactions of extended messages. > I like the summary Jeff sent indicating a real consequences for implicit > bound on current BGP attributes. Do we want to redefine BGP spec and > subsequent specs so fundamentally now to try only one proposal of > available number of others in the BGP security area ? > > The answer I think is pretty obvious. > While I think I sympathize with your thought about "let's go for the path of least pain", I also think that we have a good general problem to solve with at least two known applications to drive it. IDR readers seeing my comments on extended messages should take those comments not as attacks on the proposal but as constructive criticisms of things we have to deal with as part of standardization. I think we can get there from here. > So let me propose that all elements related to securing BGP would be > contain in a new message all together. (Perhaps new SAFI perhaps not .. > I am not sure yet). As long as the proposal is backward compatible with 4k messages, I don't know that we need a new code point for the reachability. As I half alluded to at the SIDR session on Friday at IETF 80, I think we'll eventually want to move on to securing other reachability and perhaps other path attributes. Requiring new AFI/SAFI code points would give us a full cross-product of things to worry about. (Perhaps fewer if we're clever with our bits.) > You would use the same space amount of information to sign IPv4 updates > as IPv6 updates. Leave alone the encapsulation part .. but storing and > processing the same thing many times seems to me like really waist. I think what you're talking about here is a form of detached signature. If you can make the crypto for it work, I'd suggest proposing it in SIDR. > Another advantage is processing ... If we combine the secure BGP > overhead with current BGP UPDATE message you like it or not it will have > to be handled by today's old fashion general BGP CPU processing. But if > this is defined as a separate message .. maybe even on separate session > (by enforcing multisession on it) it could be all together easily > processed by some other CPU/CPU core/programmable FPGA or ASIC without > causing any burden and delay to current BGP processing. That would very > nicely allow to decouple the functions and only pass final decision to > main core BGP as prefix X - valid .. prefix Y - invalid. I think these are implementation discussions that will be very interesting to have in SIDR. :-) -- Jeff From jhaas@slice.pfrc.org Sun Apr 17 09:22:08 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DC0B8E0684 for ; Sun, 17 Apr 2011 09:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.132 X-Spam-Level: X-Spam-Status: No, score=-102.132 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGmORnaYAOkm for ; Sun, 17 Apr 2011 09:22:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id 66A2AE0670 for ; Sun, 17 Apr 2011 09:22:08 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CF24F2241E8; Sun, 17 Apr 2011 16:22:07 +0000 (UTC) Date: Sun, 17 Apr 2011 16:22:07 +0000 From: Jeffrey Haas To: Jie Dong Message-ID: <20110417162207.GM11808@slice> References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "idr@ietf.org" Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 16:22:09 -0000 Apologies if this is a duplicate. I had thought I had responded to this but I don't see it either in my inbox or the IDR archives. On Thu, Mar 31, 2011 at 03:54:07PM +0000, Jie Dong wrote: > Authors of "IPv6 AF Extensions for Route Target Distribution" would like to propose to adopt this draft as IDR WG document. > > The draft could be found at: > http://tools.ietf.org/html/draft-keyur-bgp-af-specific-rt-constrain-01 I support adoption of this draft as a working group item. However, I also strongly request that the IPv6 RTC be moved to a different code point, whether AFI or SAFI. This would avoid muddying the semantics of an 12 byte RTC vs. the 20 byte RTC. As an example, the type and subtype fields of both regular AS-based route targets are identical with the IPv6 route target. It's unclear if the RTC prefix is /64 if the two octets not including the type/subtype are intended to be IP address or AS. -- Jeff From jhaas@slice.pfrc.org Sun Apr 17 09:25:11 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 76202E0684 for ; Sun, 17 Apr 2011 09:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r4-UPLfep5r for ; Sun, 17 Apr 2011 09:25:10 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id E2AF9E0670 for ; Sun, 17 Apr 2011 09:25:10 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B5694224307; Sun, 17 Apr 2011 16:25:10 +0000 (UTC) Date: Sun, 17 Apr 2011 16:25:10 +0000 From: Jeffrey Haas To: John Scudder Message-ID: <20110417162510.GN11808@slice> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC for draft-ietf-idr-fsm-subcode-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 16:25:11 -0000 On Tue, Apr 12, 2011 at 07:57:06PM -0700, John Scudder wrote: > Folks, > > This is to start an IDR working group last call for draft-ietf-idr-fsm-subcode-01. Please send your comments by April 27. I believe this draft is ready for publication. -- Jeff From jsw@inconcepts.biz Sun Apr 17 10:16:40 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E1F44E06B5 for ; Sun, 17 Apr 2011 10:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBCdXjKLe30j for ; Sun, 17 Apr 2011 10:16:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id CB6AEE0669 for ; Sun, 17 Apr 2011 10:16:39 -0700 (PDT) Received: by vxg33 with SMTP id 33so3815010vxg.31 for ; Sun, 17 Apr 2011 10:16:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.125.102 with SMTP id x38mr1134796vcr.260.1303060599204; Sun, 17 Apr 2011 10:16:39 -0700 (PDT) Received: by 10.220.177.11 with HTTP; Sun, 17 Apr 2011 10:16:39 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: Date: Sun, 17 Apr 2011 13:16:39 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 17:16:41 -0000 Lengthy response to several posts... On Sat, Apr 16, 2011 at 1:05 AM, Keyur Patel wrote: > Can you please explain what clear value it brings and how it helps solve > error cases? And while your at it can you also explain how it can be solv= ed > in existing case of 4091 bytes? Keyur, I'm glad to explain this (again), but there's a basic disconnect here between some list posters who have hands-on experience implementing BGP and similar message protocols, and those who just don't have that kind of in-depth background. So before I go into detail again, I want to remind you of this simple fact: 1) an existing header validation/parser error detection mechanism already exists, because maximum message size is 4096 2) that mechanism goes away if the maximum message size is increased to any value above 0xFEFF or 65279 octets 3) the cost of keeping this mechanism is only 256 octets of maximum message= size 4) if any foreseeable functionality of BGP will not be possible because of a < 1% difference in maximum message size, you guys should be extending the length field beyond 16 bits, not quibbling over 256 octets You need to understand the cost/benefit here, which has been repeatedly ignored by Randy when directly asked, and others have not responded with an opinion on this either. I view these questions from the perspective of implementation in software, troubleshooting, and use by operators; and I understand the importance of communicating my opinion to those on the list who do not have this kind of in-depth background. In fact, the reason I have subscribed to this list and invested time in posting is to turn my dissatisfaction with the results of these standards processes into constructive input for your use. Now the details: > In cases where the (malformed) update message lengths are longer than act= ual > message such things don't make sense at all because it probably has gone > over a second message. In cases where trailing bytes of the first message > are more 0xffs all bets are off! Furthermore, you cant figure out from an If you re-read my first posts on this topic, you'll learn that I very specifically laid out the limited benefit of Jakob's proposal, which is to retain the ability to detect "off-by-one" errors in code, which are common. It is true that BGP message payload can contain arbitrary data which might appear to be a valid message, and other kinds of software malfunction would be untrapped by the existing header validation mechanism, whether it is retained or not. I think this is very well understood by anyone who has actually implemented a BGP protocol speaker. > Reserving such bytes are nothing but a hack from a developer's pov. =A0Le= t me > assure you that I have no problems reducing message size if you can > deterministically convince it can solve anything. It keeps the existing solution, which is that the first octet of the message length cannot be 0xFF, the constant value of all 16 octets of the MARKER. This is how off-by-one errors are able to be detected when the trailing octets of a message are 0xFF. Quite simply, if the parser mistakenly believes that a message begins within the trailing octets of the payload of Message One, it will know with certainty that Message One is in error if the length was "too low" by 1, 2, .. 16, no matter what the trailing octets of Message One's payload contain. The parser will also know if the transmitted length value in Message One was "too high" by 1 or 2 -- this is the guarantee that is lost if the maximum message length may be > 0xFEFF. Errors from 3 .. 16 will still be trapped in either case because there is no BGP message TYPE 0xFF, and indeed that value should never be used for a BGP message TYPE. > Jakob feel free to explain how its going to help and how are you handling > current cases of 4091 bytes deterministically! This works fine today and has since BGP was originally defined in RFC1105. The first octet may not be 0xFF. If a message is 4091 octets long it will encode 0x0FFB into the message LENGTH field, preceded by the MARKER which is a sequence of octets that are always 0xFF. Since you are asking this question, I will point out in no uncertain terms that you do not have the needed protocol implementation experience to understand the changes which are proposed. If you really don't know how these values are encoded for transmission, or truly do not understand how a message parser works, I am glad you are asking questions so you can better understand the issue and develop a more informed opinion, but I have trouble understanding why you would argue against Jakob's concern if you lack this background and have not consulted folks you trust to help shape your opinion. The opinions against limiting message length to 0xFEFF all seem to come from folks who, to use an analogy, are specifying that cars should not have a "check engine light" because they don't understand how it works. Frankly, you should do more reading or consult people you trust who do have an in-depth understanding in this area before you decide that 256 octets more of message length is worth removing an already-existing error trap. On Sat, Apr 16, 2011 at 12:09 PM, Rob Shakir wrote: > Reviewing the two threads, I didn't find a clear technical justification = for requests for the maximum size being smaller. I'm not sure whether other= s agree, but I would appreciate a succinct technical summary of this requir= ement for those of us that do not directly develop BGP implementations plea= se? In the simplest terms, it is currently guaranteed that a BGP parser can detect if the message length of a message was off by as much as -18 octets or +18 octets. The proposed change to a maximum message length > 0xFEFF will create corner cases, and it will only be guaranteed that the parser can detect if the length of a message is off by -18 to -3 or +3 to +18 octets. It will no longer be guaranteed to detect "off by one" (or off by two) errors. If you've dealt with developers much, you probably know that "oops, it was an off-by-one mistake" is a pretty common explanation for bugs of all kinds. On Sat, Apr 16, 2011 at 7:53 PM, Keyur Patel wrote: > Remember it has to work as well deterministically. ;) This does NOT make = it > Robust. =A0Why don't you try and explain how your going to identify cases= with > extcomm corruption I talked about or if trailing bytes are all 0xff. Again, if you re-read my first replies to Jakob's concern, you will see that I quite specifically identified the error cases that are affected by this change. Obviously if the message length is off by 19 or more octets, there is no way to guarantee the parser will trap such an error, because the payload of a message is arbitrary. It could look exactly like a BGP message header. However, "tricking" the parser in such a manner is extremely unlikely, because it requires a sequence of 16 octets which are all 0xFF, followed by two octets which it would believe to be the length field, followed by one octet which is a valid BGP message type. It is well understood that not every extreme case of incorrect BGP message length can be trapped. I believe 256 octets less maximum message length is a very low cost for retaining the guarantee to detect common errors, off-by-one. On Sun, Apr 17, 2011 at 5:16 AM, Robert Raszuk wrote: > * Declare that the header validation is "outside the scope of your draft" > and in spite that your draft makes it harder recommend to address it in a The problem is that this draft directly affects the header validation mechanism, if it extends the maximum message length beyond 0xFEFF octets. They really shouldn't say "oh, ignore the changes we've made to the validation mechanism included in BGP in 1989 and preserved in every iteration of BGP since then," while making a wholesale change to it. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From raszuk@cisco.com Sun Apr 17 10:58:01 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4A326E06EC for ; Sun, 17 Apr 2011 10:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhFzTgcirNwg for ; Sun, 17 Apr 2011 10:58:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 69223E06A0 for ; Sun, 17 Apr 2011 10:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2090; q=dns/txt; s=iport; t=1303063080; x=1304272680; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nGazDRtjqnDAs1DALE/1QDD/wMGiNP7XH34RhWHVLwc=; b=cbWnsSUZpFyrQ/OCSs+NLDWW0iNPUVp4rKro4Q75y1NtTYUX9ZgWlE6I ix0bP23IXaDlQdafS3F6oXTNlvVJF8KQdxkPsuKMLOqt1duLCeeC2yMJv PCN4ksJuuOa7NkZ9Vt6Is/yJsF3tEolPT/hDxRnMUteGe5D3JwSLguTVE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACEpq02rRDoI/2dsb2JhbACmBneIb55HgnQOAZgVhXEEjgODdQ X-IronPort-AV: E=Sophos;i="4.64,228,1301875200"; d="scan'208";a="296315230" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 17 Apr 2011 17:57:59 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3HHvvZs005508; Sun, 17 Apr 2011 17:57:58 GMT Message-ID: <4DAB2A2F.2020606@cisco.com> Date: Sun, 17 Apr 2011 19:58:07 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jeffrey Haas References: <4DAAF8AA.6060303@cisco.com> <20110417150843.GI11808@slice> In-Reply-To: <20110417150843.GI11808@slice> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 17:58:01 -0000 Jeff, > I suspect you'll send your own correction soon, but I think you're off a few > orders of magnitude. > > 4096 octets with a simplistic encoding of 10 bits to one octet on the wire > (for simplicity) means we have 40960 (40kb). At a rate of 10Mbps, that's > 0.0041 seconds to send the packet. Yes .. sorry eaten 3 zeros - thx for correction ! But the main point was to show that it takes 16 times longer to send 65K then 4K message. > I think it's fair to say that while BGP is TCP-bound with regard to some of > its poor behavior, it's not link-bound unless we're still talking T1. :-) Ack. >> Now add to this time for acks, some router CPU delay, some I/O >> processing or worse some congestion or slow peer case and we are off the >> cliff. > > Those are the sticky points. I've spawned a new thread specifically for TCP > interactions of extended messages. Indeed. And this thread was sort of saying .. Perhaps we look at the overall problem rather then start 12 threads fixing details which perhaps do not need to be fixed. At least not now. >> You would use the same space amount of information to sign IPv4 updates >> as IPv6 updates. Leave alone the encapsulation part .. but storing and >> processing the same thing many times seems to me like really waist. > > I think what you're talking about here is a form of detached signature. If > you can make the crypto for it work, I'd suggest proposing it in SIDR. Assuming that securing BGP brings value, everything which brings value costs money. And if now ISP have to invest and will not be able to differentiate to their customers with raise of service fee I am not sure how it will get deployed. So some form of "detached signatures" or "semi-detached signatures" would just create basis of secured internet which could cost more from this best effort one - the one we know today - which would cost less. If Grandma is using net to check email once a day she really does not need to bear any costs associated with "securing the Internet". Many thx, R. From raszuk@cisco.com Sun Apr 17 10:59:44 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9DBB9E06EC for ; Sun, 17 Apr 2011 10:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDxvsIyMvG8C for ; Sun, 17 Apr 2011 10:59:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id DA1C7E06A0 for ; Sun, 17 Apr 2011 10:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1531; q=dns/txt; s=iport; t=1303063183; x=1304272783; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Ol6RljuFkWG09DdjCEZkq0ZF5TLI+DAKwUB8u/k5ZWM=; b=WFxOqETMnkUlr6s5yn5iUFlqV+VYVW8Xv9dSHN8mI16zxb6OTckTLoNM Q2h2RqTCjPB29fXfSd0+ICHC9glUeb3FHLdvninM1ehuwOf9Zn9Jteh0U D/8tBOVbhbVjyEPufNNaKcm7Z64G6yGhxDOjb1lUJa8ZR9FwGfxmkgtst c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI8pq02rRDoG/2dsb2JhbACmBXeIb55LgnQOAZgWhXEEjgODdQ X-IronPort-AV: E=Sophos;i="4.64,228,1301875200"; d="scan'208";a="431733672" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 17 Apr 2011 17:59:43 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3HHxfJh010643; Sun, 17 Apr 2011 17:59:42 GMT Message-ID: <4DAB2A97.5010901@cisco.com> Date: Sun, 17 Apr 2011 19:59:51 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jeff Wheeler References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 17:59:44 -0000 Jeff, > On Sun, Apr 17, 2011 at 5:16 AM, Robert Raszuk wrote: >> * Declare that the header validation is "outside the scope of your draft" >> and in spite that your draft makes it harder recommend to address it in a > > The problem is that this draft directly affects the header validation > mechanism, if it extends the maximum message length beyond 0xFEFF > octets. They really shouldn't say "oh, ignore the changes we've made > to the validation mechanism included in BGP in 1989 and preserved in > every iteration of BGP since then," while making a wholesale change to > it. > When quoted I think it is better to quote entire bullet as opposed to out of context single sentence. For that matter the second sentence was critical and integral part of the option. Here it is: * Declare that the header validation is "outside the scope of your draft" and in spite that your draft makes it harder recommend to address it in a separate document. However that new document must be completed before we last call (it is still fine to accept yr draft as WG doc today) this document. Otherwise implementations will have a valid reason not to implement draft-ymbk-bgp-extended-messages. And for completeness here was my first option: * Shorter the message to make sure current code of parsing header will still work in this one single particular case. This will allow to leave other pieces of error detection to an _independent_ further study and move on. Cheers R. From jsw@inconcepts.biz Sun Apr 17 12:03:45 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15224E06EC for ; Sun, 17 Apr 2011 12:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=-2.369, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgBj2ongf32v for ; Sun, 17 Apr 2011 12:03:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id D2AABE071D for ; Sun, 17 Apr 2011 12:03:43 -0700 (PDT) Received: by vxg33 with SMTP id 33so3851936vxg.31 for ; Sun, 17 Apr 2011 12:03:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.125.102 with SMTP id x38mr1154775vcr.260.1303067023279; Sun, 17 Apr 2011 12:03:43 -0700 (PDT) Received: by 10.220.177.11 with HTTP; Sun, 17 Apr 2011 12:03:43 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <20110417145115.GH11808@slice> References: <20110417145115.GH11808@slice> Date: Sun, 17 Apr 2011 15:03:43 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] draft-ymbk-bgp-extended-messages implications on TCP windows X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 19:03:45 -0000 On Sun, Apr 17, 2011 at 10:51 AM, Jeffrey Haas wrote: > Caveat: I'm not a TCP protocol expert nor do I play one at my employer. > Like many people on this list, TCP looks like a socket to me and the This is hard to explain. From your perspective, the kernel TCP stack provides a buffer which is NOT RELATED TO THE TX WINDOW SIZE. This is crucial to understand. You can use setsockopt(2) or sysctl to tune the size of your kernel Tx buffer on a per-socket or system-wide basis, as desired, to relieve the user-space program ("rpd") of continually serving a user-space Tx buffer. In fact, it is a pretty good idea to raise the size of the kernel buffer and reduce the size of the user-space buffer, because the kernel can serve many sockets with pending Tx data in a single context swap and without consideration for the amount of time rpd may spend evaluating routing policy or doing other expensive operations, since you have a preemptive multi-tasking OS. The per-neighbor transmit buffer for BGP messages in "rpd" should be large enough to hold: * at least one message; and * maybe as large as however many messages as may be generated towards a single neighbor by one traversal of the event loop (which will initiate a context swap anyway whenever it serves write-able descriptors) + basically, as much memory as you want to trade for pre-computing outgoing messages - because this pre-computation and buffering might be prioritized in some way > What I'm a bit more concerned about isn't large window support as it is w= ith > the interaction of larger message sizes and one's peers. =A0When an > implementation slows down its read behavior for whatever reason, this is > experienced as throttling at the TCP level and thus blocked writes at the > sender. =A0Implementations for efficiency sake often have hooks into TCP = to If you familiarize yourself with the original TCP specification, you'll see that TCP Window is a flow-control mechanism. The receiving side has only so much kernel-space buffer (again, normally more than the Window size) and it ACKs segments as they go into that buffer, but scales down the Window size if user-space is not reading from the socket often enough to keep enough free receive buffer to receive an entire Window worth of data. This is how TCP avoids spurious retransmits because of the "kernel waiting on user-space" and it is the reason for TCP window scaling. On the transmitting side, the way you avoid the appearance of a "stalled" session is by raising the value of SO_SNDBUF to buffer more messages in the kernel, so they can be transmitted by the kernel as soon as the receiving neighbor is ready for them, instead of waiting for "rpd" to compute more outgoing updates. On the receiving side, the value of SO_RCVBUF can be raised so its kernel will buffer more incoming data, and send more ACKs, regardless of whether or not "rpd" has actually read them out of kernel-space yet. This allows the TCP Window to scale up as-needed and reduces the appearance of "stalls" on the transmit side, provided that the transmit side is regularly writing new messages into its kernel buffer. > watch for a given low water mark for purposes of even trying to do a writ= e > on the socket. This adds implementation complexity to user-space, or "rpd." The benefit is that you will have less expensive executions of the code that serves write-able descriptors, but the cost is you will execute some code anyway only to decide not to write anything at all from the user-space buffer to the kernel-space buffer. To be honest, it is not an optimization -- it is stupid. The reason why is those less-expensive executions of the "socket is write-able" code cause context swaps that don't actually do anything at all, where you could have fewer context swaps, which are slightly more expensive (write to socket and then manage user-space buffer), but cause the kernel-space buffer to become full again, preventing any more context swaps until some in-flight TCP segments have been ACKed and more kernel-space buffer is available. If your developers are really peeking into the TCP stack to find out how much more send buffer is available, they should learn a bit more about the underlying TCP stack in your OS and take advantage of its features. If the concern is that JUNOS is moving toward prioritizing route update computations and message transmissions, they should structure the user-space buffers as follows: * pointer to message fragment currently waiting to be sent (really a whole message but pointer may be mid-message) * list of high-priority messages pending transmission, some of which are already pre-computed * knowledge of whether high-priority route updates are pending computation * list of lower-priority messages pending transmission If they are concerned about a large number of low-priority messages being stored into the kernel-space buffer, thus the TCP stack will send them before new high-priority messages, they must realize that there is an intrinsic trade-off between a larger kernel-space buffer and lower-latency transmission of high-priority messages and buffer management complexity. In either case, though, peeking into the TCP stack is pretty foolish because it dials up the number of context swaps, and much more benefit can be found in terms of prioritizing updates in terms of the "rpd" "work list" than in tinkering around with the buffer manager and TCP stack. After all, the updates themselves are generated by rpd as it "does work" in an order which must be prioritized to see any practical gain. > To continue on Jakob Heitz's issue about hold timers expiring on slow rea= ds, > when one hooks into the TCP window state for purposes of determining whet= her > one can write or not, one now has to consider the need for larger windows= . No, you really do not need to consider TCP Window value at all. There are several kinds of BGP message type that do not satisfy the hold timer's need to receive a message before closing the session -- a buffer full of large NOTIFICATION messages would not do so. The specification should be altered as Jakob suggests to satisfy the hold timer upon receipt of either any message-type (IMO) or any data (Jakob's suggestion) for slow TCP sessions. I am not concerned about a session reset if 64KB has not been received yet, but I do understand why it is concerning if a bunch of NOTIFICATION messages have been buffered and are pending transmission, and no UPDATE or KEEPALIVE messages are being sent for a long period of time towards a slow neighbor. To put this in context, though, even a 64Kbit/sec leased-line can still receive a 64KB message in well under the default hold-time for BGP, as long as it does not need to receive several large NOTIFICATION messages in sequence. Either requiring receipt of any message type, or any data, would be satisfactory and avoid this problem. > We're unlikely to really require 65k packets. =A0However, we'll probably = want > to change those marks for something bigger - perhaps 8-16k. =A0I already = see > headaches in troubleshooting slow peers due to TCP stalling issues. =A0Th= is > will only exacerbate some of them. This is understandable if you are trying to "optimize" transmission by peeking into the TCP stack, and blowing up the number of CPU context swaps, instead of simply letting the TCP stack do its job -- which is to allow rpd to spend more time "working" and less time dealing with transmit buffers. Any TCP stalling issues you are encountering are a product of your own making. If you don't take advantage of the kernel-space transmit buffer, then the neighbor won't get more messages until rpd finishes "whatever it is working on" and returns to the event loop, where write-able descriptors can be serviced. On Sun, Apr 17, 2011 at 10:51 AM, Jeffrey Haas wrote: > Caveat: I'm not a TCP protocol expert nor do I play one at my employer. > Like many people on this list, TCP looks like a socket to me and the To come back to the first lines in your original message, if TCP looks like a socket to you, and you have stalling problems, all you need to do is grow the kernel transmit buffer (realizing that there is a trade-off if you try to prioritize messages) or return to the event loop more often (harder.) Really, in an ideal implementation, "work" evaluating policy would not block pending writes from the prioritized message queue to the kernel TCP buffer; but this really requires either more code complexity in a single-threaded program, or a thread/process dedicated to the queue/buffer manager. But if you don't care about prioritizing updates toward the kernel-level TCP buffer, this is a total non-issue. Anyone having TCP stalling *without* trying to prioritize update messages is just reaping what they sowed by trying to "optimize" something that was already optimal -- the kernel efficiently handling I/O with fewer context swaps. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jhaas@slice.pfrc.org Sun Apr 17 13:15:11 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 713C2E0734 for ; Sun, 17 Apr 2011 13:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxy+Yg+HCDoT for ; Sun, 17 Apr 2011 13:15:10 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id 983A0E0681 for ; Sun, 17 Apr 2011 13:15:10 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 276742241E3; Sun, 17 Apr 2011 20:15:10 +0000 (UTC) Date: Sun, 17 Apr 2011 20:15:10 +0000 From: Jeffrey Haas To: Jeff Wheeler Message-ID: <20110417201510.GO11808@slice> References: <20110417145115.GH11808@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages implications on TCP windows X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 20:15:11 -0000 On Sun, Apr 17, 2011 at 03:03:43PM -0400, Jeff Wheeler wrote: > On Sun, Apr 17, 2011 at 10:51 AM, Jeffrey Haas wrote: > > Caveat: I'm not a TCP protocol expert nor do I play one at my employer. > > Like many people on this list, TCP looks like a socket to me and the > > This is hard to explain. From your perspective, the kernel TCP stack > provides a buffer which is NOT RELATED TO THE TX WINDOW SIZE. This is > crucial to understand. I don't believe you just wrote this list TCP-101. For your clarification, I'm not an IETF TCP subject matter expert. I.e. I don't contribute to tcpm. I don't maintain our tcp stack. I'm well aware of how stream sockets work under the covers and what things look like on the wire, thankyouverymuch. Secondarily, this is not about Junos nor rpd. It's generically about TCP and BGP and the fact that BGP implementors get to see a lot of the transport level stupidity reflected at the socket level. And I see this stuff from the tcpdump analysis level as I get to prove out why some other implementation is stalling out for no good reason and why it only hands back window sizes in certain levels of chunking. And why in our implementation we have to take account of the to-and-fro of windowing based on that behavior. I'm going to trim a massive portion of your rpd speculation since some of it's right and some of it's very wrong. Mostly it's also largely irrelevant to my original point. > > watch for a given low water mark for purposes of even trying to do a write > > on the socket. [...] > In either case, though, peeking into the TCP stack is pretty foolish > because it dials up the number of context swaps, and much more benefit > can be found in terms of prioritizing updates in terms Not true. Unlike a web server or less PDU-oriented protocols, BGP speakers need to spend as much time making sure that there are entire BGP messages available for the peer. Partial messages in the kernel lead to partial messages on the wire which, if not drained in a timely fashion, stall the remote peer. It makes no sense to bother the routing process for a packet to transmit if there's either no packet to transmit or not enough room to transmit one. The dynamics of "enough room" are what will be changing with the extended message feature. > Either requiring receipt of any message type, or any data, would be > satisfactory and avoid this problem. You apparently haven't noticed that's not how 4271 is written. That said, the 4271 rev of the BGP FSM misses a lot of reasonable details for an implementation. > > We're unlikely to really require 65k packets. ?However, we'll probably want > > to change those marks for something bigger - perhaps 8-16k. ?I already see > > headaches in troubleshooting slow peers due to TCP stalling issues. ?This > > will only exacerbate some of them. > > This is understandable if you are trying to "optimize" transmission by > peeking into the TCP stack, and blowing up the number of CPU context > swaps, instead of simply letting the TCP stack do its job -- which is > to allow rpd to spend more time "working" and less time dealing with > transmit buffers. In any routing protocol implementation, if you have state you need to transmit, you want to get it to the remote side as quickly as possible with as little work as possible. The conditions of concern are when the kernel TCP buffers are mostly full. One way or the other, you will have to put your new work into them. The message sizes impact how often and how efficiently you can do the work to fill that buffer. In other words, message size impacts work done and its timeliness. This is the whole point of the thread. > Any TCP stalling issues you are encountering are a product of your own > making. If that were only true. I can fix my bugs, I can't fix other people's. I just have to deal with them. -- Jeff From jsw@inconcepts.biz Sun Apr 17 15:12:45 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38444E06B6 for ; Sun, 17 Apr 2011 15:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xclLoY-cq5+r for ; Sun, 17 Apr 2011 15:12:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 23D20E068B for ; Sun, 17 Apr 2011 15:12:43 -0700 (PDT) Received: by vxg33 with SMTP id 33so3915786vxg.31 for ; Sun, 17 Apr 2011 15:12:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.88.233 with SMTP id bj9mr2777832vdb.131.1303078362971; Sun, 17 Apr 2011 15:12:42 -0700 (PDT) Received: by 10.220.177.11 with HTTP; Sun, 17 Apr 2011 15:12:42 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <20110417201510.GO11808@slice> References: <20110417145115.GH11808@slice> <20110417201510.GO11808@slice> Date: Sun, 17 Apr 2011 18:12:42 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] draft-ymbk-bgp-extended-messages implications on TCP windows X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 22:12:45 -0000 On Sun, Apr 17, 2011 at 4:15 PM, Jeffrey Haas wrote: > I don't believe you just wrote this list TCP-101. I have been in equal disbelief each time I've seen a reference to TCP Window size in this context. It is abundantly clear that some posters do not know how TCP works. > Secondarily, this is not about Junos nor rpd. =A0It's generically about T= CP > and BGP and the fact that BGP implementors get to see a lot of the transp= ort > level stupidity reflected at the socket level. =A0And I see this stuff fr= om No, any "transport level stupidity" you see is not at the socket level. Again, if you are peeking into the TCP stack to find out how much more kernel-space buffer is available, instead of simply filling it up, you are adding context swaps and complexity. Unless your intent is to prioritize outbound messages, there is zero benefit to this. > the tcpdump analysis level as I get to prove out why some other > implementation is stalling out for no good reason and why it only hands b= ack > window sizes in certain levels of chunking. =A0And why in our implementat= ion > we have to take account of the to-and-fro of windowing based on that > behavior. No, you do not need to account for "some other implementation" stalling -- you only need to have data in the kernel buffer for transmission when the neighbor is ready to receive said data. Keeping a large user-space transmit buffer creates Tx stalls. Having a too-small kernel-space receive buffer gives the appearance of "Rx stalls," but in fact, the TCP Window is a flow-control mechanism and it is not incorrect to take advantage of it. > I'm going to trim a massive portion of your rpd speculation since some of > it's right and some of it's very wrong. Mostly it's also largely irreleva= nt to > my original point. What is irrelevant is your original post. TCP Window size has no bearing on maximum message size. My "rpd speculation" is for your benefit -- if you need to understand how prioritizing message transmission and avoiding stalls can be conflicting goals, it's in your inbox. This is the only reason you would have to poke around at the TCP stack from user-space. If this is not among your goals, then fooling with the TCP stack, and having an overly-large user-space buffer without understanding the function of the kernel-space buffer, is stupid. If you care to clarify how abstracting the function of rpd into "work" and "queue/buffer manager" to explain the program's interaction with the TCP stack, and remote neighbors, is "very wrong", please feel free to do so. Otherwise, I'm happy to write that off as defensive grand-standing, as it should be abundantly clear to anyone who does understand TCP that you are complaining about self-made stalling problems. My use of rpd as an example is also to make this explanation distinct from BGP speakers which choose to implement an independent TCP stack in the BGP speaker, such as IOS. In the case of IOS, the BGP Router process is already executing anyway, so there is not an additional performance penalty for the BGP speaker having intimate awareness of in-flight segments vs buffered data. There obviously is a complexity penalty, as we can see when troubleshooting things that look like "BGP bugs" which sometimes turn out to be "IOS BGP-speaker TCP bugs." >> In either case, though, peeking into the TCP stack is pretty foolish >> because it dials up the number of context swaps, and much more benefit >> can be found in terms of prioritizing updates in terms > > Not true. =A0Unlike a web server or less PDU-oriented protocols, BGP spea= kers > need to spend as much time making sure that there are entire BGP messages > available for the peer. =A0Partial messages in the kernel lead to partial > messages on the wire which, if not drained in a timely fashion, stall the > remote peer. The possibility of partial messages on the wire always exists. You can't get rid of partials without doing all of: * make BGP message smaller than MSS * turn off Nagle * turn off retransmit coalescing or use a different transport protocol than TCP. The next best way to avoid partial messages, which is just as effective as peeking into the TCP stack, is to use SO_SNDLOWAT. This does exactly what you describe, "ensure there is enough room to transmit an entire packet" into the kernel-space buffer, still without requiring the programmer to be concerned about the TCP Window. Obviously, the send buffer must be large enough to store one whole message, but again, this buffer is unrelated to the TCP Window size. It is a convenience to allow the user-space program to spend less time servicing a message buffer/queue and write-able descriptor, and more time "working." > It makes no sense to bother the routing process for a packet to transmit = if > there's either no packet to transmit or not enough room to transmit one. See above for how this is accomplished without fooling with the TCP stack. In either case, it is up to you whether or not you decide to buffer partial-messages in the kernel or not. They absolutely will go "on the wire" as partials no matter what you do. > In any routing protocol implementation, if you have state you need to > transmit, you want to get it to the remote side as quickly as possible wi= th > as little work as possible. =A0The conditions of concern are when the ker= nel > TCP buffers are mostly full. =A0One way or the other, you will have to pu= t > your new work into them. =A0The message sizes impact how often and how > efficiently you can do the work to fill that buffer. > > In other words, message size impacts work done and its timeliness. =A0Thi= s is > the whole point of the thread. Yes, but none of this is related in any way to TCP Window size. >> Any TCP stalling issues you are encountering are a product of your own >> making. > > If that were only true. =A0I can fix my bugs, I can't fix other people's. > I just have to deal with them. I do sympathize with your desire to only place whole-messages into the TCP stack Tx buffer. Unfortunately, since BGP messages can be larger than TCP MSS, there is no guarantee that partial messages won't be transmitted. You are lumping some unrelated issues into "TCP Window," which really has nothing to do with this. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jhaas@slice.pfrc.org Sun Apr 17 15:56:16 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 98B53E0744 for ; Sun, 17 Apr 2011 15:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.172 X-Spam-Level: X-Spam-Status: No, score=-102.172 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNc9vMmJBBBd for ; Sun, 17 Apr 2011 15:56:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id 251C4E0738 for ; Sun, 17 Apr 2011 15:56:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D65A622431E; Sun, 17 Apr 2011 22:56:15 +0000 (UTC) Date: Sun, 17 Apr 2011 22:56:15 +0000 From: Jeffrey Haas To: Jeffrey Haas Message-ID: <20110417225615.GU11808@slice> References: <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <20110417132345.GD11808@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110417132345.GD11808@slice> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: idr Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 22:56:16 -0000 Followup to my own comment. On Sun, Apr 17, 2011 at 01:23:45PM +0000, Jeffrey Haas wrote: > Jakob, > > On Sun, Apr 10, 2011 at 02:15:21PM -0400, Jakob Heitz wrote: > > The length field follows the marker. If the first byte of the length field can be 0xff, it reduces the value of the marker. The value of the marker is to validate the beginning of a message. This is good both in protocol operation as well as for debugging. > > > > To preserve the value of the marker, I propose the maximum message length to be 65279 (0xfeff). > > While I strongly sympathize with the usefulness of the marker field for > purposes of re-detecting lost framing in BGP PDUs in a TCP stream, I think > the property you're really looking for is predictability of value. As such, > I don't think we want to preclude any particular value for the message > length. Another observation is that if the trailing NLRI contains 0xff in the byte stream, we still have a variant of this issue. -- Jeff From jsw@inconcepts.biz Sun Apr 17 16:05:11 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7FD98E0744 for ; Sun, 17 Apr 2011 16:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sx4naBDWxmlh for ; Sun, 17 Apr 2011 16:05:10 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 99485E0740 for ; Sun, 17 Apr 2011 16:05:10 -0700 (PDT) Received: by vws12 with SMTP id 12so3945464vws.31 for ; Sun, 17 Apr 2011 16:05:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.125.102 with SMTP id x38mr1199110vcr.260.1303081510002; Sun, 17 Apr 2011 16:05:10 -0700 (PDT) Received: by 10.220.177.11 with HTTP; Sun, 17 Apr 2011 16:05:09 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: <4DAAAFD2.8040505@cisco.com> Date: Sun, 17 Apr 2011 19:05:09 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:05:11 -0000 On Sun, Apr 17, 2011 at 5:19 PM, Keyur Patel wrote: > NO That's NOT what I meant and I think you missed the point. But nevermin= d! > Why don't we just close this thread and agree to disagree on our POV. In > case any of you like to pursue this any further then it would be nice to > have a working C code which can: > > - Show what your trying to fix. > - Explain how it works with (multiple) corruption cases. > - Explain how it works deterministically for partial cases your trying to > solve without creating more issues if corruption happens in the same > message. This "working C code" to detect off-by-one or off-by-two errors exists in every single BGP implementation which, today, will catch an erroneous message length field which is > 4KB. #define BGP_MESSAGE_MAXLEN 4096 if (bgphdr.length > BGP_MESSAGE_MAXLEN) { /* either the current message is too big; or * the previous message length was off by 1 or 2 */ } In the case of #define BGP_MESSAGE_MAXLEN 0xFEFF the above snippet is still valid and still catches all of those errors. If you increase BGP_MESSAGE_MAXLEN to any value greater than 0xFEFF you can no longer catch off-by-one or off-by-two. Have you put any thought into what will happen, if indeed the remote neighbor sends an incorrect message length, and the parser thinks an incoming message will be > 0xFEFF octets long? I have. One of two things will happen: 1) 64KB of data will arrive before hold-timer expires, and a parser error will be thrown; or 2) routine KEEPALIVE messages will not be enough to complete a 64KB message, the parser will never even try to parse the message, and it will simply tear down the session with a hold-time expired message, leaving the operator confused as to why his BGP session failed without any good explanation. The issue isn't data corruption -- the underlying protocols (TCP, Ethernet, etc.) provide all desired defense against this. The issue is correctly detecting errors in the BGP implementation. Today, if the remote BGP speaker sends the wrong message size, it is very likely we will detect this. By changing the maximum message size to > 0xFEFF you lose the ability to detect off-by-one or off-by-two. This capability exists today. You propose to remove it. I realize you don't *understand* that you propose to remove it, but you do. It's dead simple and has been explained time and time again. I am truly sorry that this is over your head, as I am sure it is every bit as frustrating for you to (wrongly) think this is some kind of red herring as it is for me to repeatedly try to explain this problem to someone who lacks the background knowledge needed to understand the effects of his proposed change to the message header. I've spent 14 years deciding what routers to buy, operating routers, and developing software which must interact with routers. In that time I have had many occasions to play armchair policy-hawk, thinking "how could this become an industry standard?" "Why are obvious things that I need being overlooked?" "My job would be so much easier if these standards guys just realized [whatever I think should have been obvious.]" I'm not posting just to be argumentative and make your job harder; I'm posting because I have spent a very long time wondering why the occasional huge oversight, useless complexity, or specification language without regard to actual implementation makes it through these standards processes. I would hate to think the reason for that is the folks who drive the process are either purposefully ignorant of operational and implementation challenges, or lack the ability to recognize that they are sometimes not the smartest guy in the room on a particular issue, and should be open to input from different perspectives. I always assumed the reason was that "policy hawks" don't have as much exposure as they would like to operational / implementation concerns. I don't really care why BGP messages need to be larger -- security extensions, packing more NLRI, stuffing poems into KEEPALIVES, whatever the extra payload is, I'm not telling you there's anything wrong with it. All I'm telling you is you can extend the message size to 65,279 octets without really rocking the boat -- beyond that, you encounter a real, practical problem. Does the ultimate goal of your extension to the message size really suffer if you can only have 65,279 octets instead of 65,535 octets? You are getting more than 61,000 octets of new payload capacity either way -- an order of magnitude increase! --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From keyupate@cisco.com Sun Apr 17 16:22:34 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 00B48E0740 for ; Sun, 17 Apr 2011 16:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.407 X-Spam-Level: X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS1SZxOnKAsE for ; Sun, 17 Apr 2011 16:22:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id C8D7EE073E for ; Sun, 17 Apr 2011 16:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=2376; q=dns/txt; s=iport; t=1303082552; x=1304292152; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=mmer19iTp8u5la+HnsobhhlfHjVMBDaWw4KnakaSTKE=; b=Vpq+KeamE7JyxaOtHGox38/4Tq8iHsunmD3/+US650CEHcx05lXpl+NI zVHJExvgbgtGSpddp7BQR1WeuzB+5c+f3ndJfp59jWJcj2L7TiEus6IjR S/5xNUf5cFA3d2nlYRUpMJRPwodmluEUCZOM4ZX9dkzvEOLE/5CIgwb4I s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHZ1q02rRDoJ/2dsb2JhbAClW3eIb58MmxiFcQSFYoghg3w X-IronPort-AV: E=Sophos;i="4.64,229,1301875200"; d="scan'208";a="339355666" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 17 Apr 2011 23:22:32 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3HNMWJo027428; Sun, 17 Apr 2011 23:22:32 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Apr 2011 16:22:32 -0700 Received: from 10.21.112.179 ([10.21.112.179]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.32]) with Microsoft Exchange Server HTTP-DAV ; Sun, 17 Apr 2011 23:22:31 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Sun, 17 Apr 2011 16:21:52 -0700 From: Keyur Patel To: Jeff Wheeler , Message-ID: Thread-Topic: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 Thread-Index: Acv9Vjumelky7GlJEeCGfQAbY71bnA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Apr 2011 23:22:32.0144 (UTC) FILETIME=[53946500:01CBFD56] Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:22:34 -0000 Jeff, On 4/17/11 10:16 AM, "Jeff Wheeler" wrote: > Lengthy response to several posts... > > On Sat, Apr 16, 2011 at 1:05 AM, Keyur Patel wrote: >> Can you please explain what clear value it brings and how it helps solve >> error cases? And while your at it can you also explain how it can be solved >> in existing case of 4091 bytes? > > Keyur, I'm glad to explain this (again), but there's a basic > disconnect here between some list posters who have hands-on experience > implementing BGP and similar message protocols, and those who just > don't have that kind of in-depth background. I take it you don't know who all are involved on this list. And that's okay! For the future reference lets just avoid trash talk and stick to the technical points particularly if you have join this list to provide constructive feedback! > It keeps the existing solution, which is that the first octet of the > message length cannot be 0xFF, the constant value of all 16 octets of > the MARKER. This is how off-by-one errors are able to be detected > when the trailing octets of a message are 0xFF. > Quite simply, if the > parser mistakenly believes that a message begins within the trailing > octets of the payload of Message One, it will know with certainty that > Message One is in error if the length was "too low" by 1, 2, .. 16, no > matter what the trailing octets of Message One's payload contain. > > The parser will also know if the transmitted length value in Message > One was "too high" by 1 or 2 -- this is the guarantee that is lost if > the maximum message length may be > 0xFEFF. Errors from 3 .. 16 will > still be trapped in either case because there is no BGP message TYPE > 0xFF, and indeed that value should never be used for a BGP message > TYPE. It doesn't aid any other cases than mentioned above purely from verification perspective. Furthermore, some of these cases can be misinterpreted particularly where your former message is corrupted and if you trying to find a beginning of next message (false positives). That's why I find the Jakob's argument weak along with arguments you posted earlier (not that I don't understand the fix). Lastly if your off by one octet you are going to find out parsing of the message. Regards, Keyur From keyupate@cisco.com Sun Apr 17 16:23:54 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CF657E06B1 for ; Sun, 17 Apr 2011 16:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.426 X-Spam-Level: X-Spam-Status: No, score=-10.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amLCZ233q0j4 for ; Sun, 17 Apr 2011 16:23:54 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 14A1CE068B for ; Sun, 17 Apr 2011 16:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=2069; q=dns/txt; s=iport; t=1303082634; x=1304292234; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=8bxDQiElFmj4fXznk6GVyw9N5Xy6zqvyZTj2AHAfw5Q=; b=Xud6/6rJEY1ABEGmZ3uG3hjM1S+C8snaK8PHnKN4jNTvj1omjgNLWtVA FJFVaHas8BuyBBXo3WrszOge0Q3pD4higf15XCWnOSphTDsbxNHZun78/ lR9HSaNaSh9rK9kL+fesS2XoFqwCtrvdSd3w/kDtgP44e3wXZ2p8epK9G 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD51q02rRDoJ/2dsb2JhbAClW3eIb58LmxiEYYEQBIViiCGDfA X-IronPort-AV: E=Sophos;i="4.64,229,1301875200"; d="scan'208";a="296389863" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 17 Apr 2011 23:23:46 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3HNNkoi027779; Sun, 17 Apr 2011 23:23:46 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Apr 2011 16:23:46 -0700 Received: from 10.21.112.179 ([10.21.112.179]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.32]) with Microsoft Exchange Server HTTP-DAV ; Sun, 17 Apr 2011 23:23:46 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Sun, 17 Apr 2011 16:23:07 -0700 From: Keyur Patel To: Jeff Wheeler , Message-ID: Thread-Topic: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 Thread-Index: Acv9VmhapthCImlJEeCGfQAbY71bnA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Apr 2011 23:23:46.0459 (UTC) FILETIME=[7FDFF6B0:01CBFD56] Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:23:54 -0000 Jeff, On 4/17/11 4:05 PM, "Jeff Wheeler" wrote: > On Sun, Apr 17, 2011 at 5:19 PM, Keyur Patel wrote: >> NO That's NOT what I meant and I think you missed the point. But nevermind! >> Why don't we just close this thread and agree to disagree on our POV. In >> case any of you like to pursue this any further then it would be nice to >> have a working C code which can: >> >> - Show what your trying to fix. >> - Explain how it works with (multiple) corruption cases. >> - Explain how it works deterministically for partial cases your trying to >> solve without creating more issues if corruption happens in the same >> message. > > This "working C code" to detect off-by-one or off-by-two errors exists > in every single BGP implementation which, today, will catch an > erroneous message length field which is > 4KB. > > #define BGP_MESSAGE_MAXLEN 4096 > if (bgphdr.length > BGP_MESSAGE_MAXLEN) { > /* either the current message is too big; or > * the previous message length was off by 1 or 2 > */ > } > In the case of #define BGP_MESSAGE_MAXLEN 0xFEFF the above snippet is > still valid and still catches all of those errors. If you increase > BGP_MESSAGE_MAXLEN to any value greater than 0xFEFF you can no longer > catch off-by-one or off-by-two. > > Have you put any thought into what will happen, if indeed the remote > neighbor sends an incorrect message length, and the parser thinks an > incoming message will be > 0xFEFF octets long? I have. One of two > things will happen: And what makes you think that this cant happen today with the 4k limit when the message size listed is 4K while actual message was around 200 bytes? Do you think the current message length handles it? I cant even say that probability of happening with 65K is much higher considering the aggressive hold timers SPs configure for fast convergence! Regardless of what message limit you will be at, if the timers are aggressively configured you will time out. Regards, -Keyur From randy@psg.com Sun Apr 17 16:26:11 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6183CE0742 for ; Sun, 17 Apr 2011 16:26:11 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBNXI3po-2ek for ; Sun, 17 Apr 2011 16:26:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id D7FD5E06B1 for ; Sun, 17 Apr 2011 16:26:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QBbM1-000OYc-LA; Sun, 17 Apr 2011 23:26:09 +0000 Date: Mon, 18 Apr 2011 08:26:35 +0900 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20110417225615.GU11808@slice> References: <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <20110417132345.GD11808@slice> <20110417225615.GU11808@slice> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:26:11 -0000 >> While I strongly sympathize with the usefulness of the marker field for >> purposes of re-detecting lost framing in BGP PDUs in a TCP stream, I think >> the property you're really looking for is predictability of value. As such, >> I don't think we want to preclude any particular value for the message >> length. > > Another observation is that if the trailing NLRI contains 0xff in the byte > stream, we still have a variant of this issue. all the lessons of SLIP twenty years later. nancy reagan was right. randy From jsw@inconcepts.biz Sun Apr 17 17:16:10 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4EE6EE0687 for ; Sun, 17 Apr 2011 17:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbkzpMVY6h0b for ; Sun, 17 Apr 2011 17:16:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 7EF58E065F for ; Sun, 17 Apr 2011 17:16:09 -0700 (PDT) Received: by vxg33 with SMTP id 33so3955361vxg.31 for ; Sun, 17 Apr 2011 17:16:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.125.102 with SMTP id x38mr1210653vcr.260.1303085769101; Sun, 17 Apr 2011 17:16:09 -0700 (PDT) Received: by 10.220.177.11 with HTTP; Sun, 17 Apr 2011 17:16:08 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: Date: Sun, 17 Apr 2011 20:16:08 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 00:16:10 -0000 On Sun, Apr 17, 2011 at 7:21 PM, Keyur Patel wrote: > It doesn't aid any other cases than mentioned above purely from verificat= ion > perspective. Furthermore, some of these cases can be misinterpreted > particularly where your former message is corrupted and if you trying to > find a beginning of next message (false positives). > > That's why I find the Jakob's argument weak along with arguments you post= ed > earlier (not that I don't understand the fix). =A0Lastly if your off by o= ne > octet you are going to find out parsing of the message. I agree with you, the error cases that this change affects are limited to "previous message length off by 1 or 2." Do you think this is not worth defending against, at the known cost of "the fix?" You see, neither you nor any other list poster has said "I think I need 0.4% more payload more than I need to guard against off-by-one errors." If you oppose "the fix," please make your position on this clear -- that you understand the cost/benefit, have weighed your options with due care, and formed an opinion that you really want that 0.4%. On Sun, Apr 17, 2011 at 7:23 PM, Keyur Patel wrote: >> Have you put any thought into what will happen, if indeed the remote >> neighbor sends an incorrect message length, and the parser thinks an >> incoming message will be > 0xFEFF octets long? =A0I have. =A0One of two >> things will happen: > > And what makes you think that this cant happen today with the 4k limit wh= en > the message size listed is 4K while actual message was around 200 bytes? = Do > you think the current message length handles it? If a message length today is off by 1 or 2, it can be detected as soon as the next message header is received, regardless of any payload. The parser won't start at the wrong place when looking for the next message header, see 0xFF octets in the MARKER field, and thing those are actually the LENGTH, not trailing octets of the misplaced MARKER. So we won't actually think the message is huge -- we'll know the previous message header LENGTH field was incorrect and we'll throw a specific error right away, not sit around and wait for hold-time to expire or more octets to come in (and trick us into thinking a *later* message than the malformed one was in error, too!) On Sun, Apr 17, 2011 at 7:21 PM, Keyur Patel wrote: > That's why I find the Jakob's argument weak along with arguments you post= ed > earlier (not that I don't understand the fix). =A0Lastly if your off by o= ne If you "understand the fix," why did you state that you would have nothing more to discuss on this topic until someone posted "C code" implementing this fault detection? I have not written some novel 1-liner, I've only tried to make it (more) obvious that the proposed protocol change breaks an already existing fault detection measure. Again, if you "understand the fix," will you go ahead and state that you believe 0.4% more payload is of greater importance than guarding against off-by-one bugs? Alternately, would you explain why some work is jeopardized by whatever delay is needed to change the draft to replace 65535 octets with 65279 octets? I readily admit that I do not understand the standards process. If you need to say "secure BGP and long poems in NOTIFICATIONS will be delayed by one year if we make this change," I might think, gosh, I really do want secure BGP and delaying it is an unacceptable cost. However, my suspicion is that s/65535/65279/ is a pretty light-weight change that does not alter the scope of the draft, is getting quite thorough debate right now, and is an easy change to make. Finally, if neither of these is the case, is there some outstanding question on your mind? Are you simply not interested in making this change because no one(?) thought of it before Jakob wrote his first post on this issue? The obvious purpose of an open standards process is to get from concept to implementation in the best manner, with input considered to improve upon concept and specifics, catch gotchas (like this one), avoid duplication of work, and hear feedback from other vendors/implementors. That whole process is useless if people simply railroad their idea through it. I have yet to read any post that offers any remotely-legitimate reason why 0.4% of payload is a big deal -- yet you wish to essentially "close debate and move on." That is railroading, plain and simple, and whether it appears to be polite or not, I am calling it like I see it. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From keyupate@cisco.com Sun Apr 17 17:29:18 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 568F1E0687 for ; Sun, 17 Apr 2011 17:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.442 X-Spam-Level: X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSBDho-WyOsT for ; Sun, 17 Apr 2011 17:29:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 4FB1CE0674 for ; Sun, 17 Apr 2011 17:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=996; q=dns/txt; s=iport; t=1303086557; x=1304296157; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=i3FcYQxuyQsbBb42wIPkoXIP+frRz5Db8U644uMNddE=; b=jrxqTxk1dNIqIU4nL/vrvz/9R+gXhFYc1rdfisLgnz4Af7qne45CeCGv 1YBrBhQanF/IbZhInHmJAgBb6O5MZWcTL2NkkxrUmqUJlW+eIqjxDph0e U2rdljapLtFoLeAuEHCFoSe2gvDMk3kYubjXU93MlwReKwB7MqVDIryQX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALOEq02rRDoJ/2dsb2JhbAClWneIb55omxyEYYEQBIViiCCDfA X-IronPort-AV: E=Sophos;i="4.64,229,1301875200"; d="scan'208";a="339368923" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 18 Apr 2011 00:29:16 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3I0TGWS019854; Mon, 18 Apr 2011 00:29:16 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Apr 2011 17:29:16 -0700 Received: from 10.21.112.179 ([10.21.112.179]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2011 00:29:15 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Sun, 17 Apr 2011 17:28:36 -0700 From: Keyur Patel To: Jeff Wheeler , Message-ID: Thread-Topic: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 Thread-Index: Acv9X444zRIZyGlSEeCGfQAbY71bnA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 18 Apr 2011 00:29:16.0680 (UTC) FILETIME=[A6781880:01CBFD5F] Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 00:29:18 -0000 > On Sun, Apr 17, 2011 at 7:23 PM, Keyur Patel wrote: >>> Have you put any thought into what will happen, if indeed the remote >>> neighbor sends an incorrect message length, and the parser thinks an >>> incoming message will be > 0xFEFF octets long? =A0I have. =A0One of two >>> things will happen: >>=20 >> And what makes you think that this cant happen today with the 4k limit w= hen >> the message size listed is 4K while actual message was around 200 bytes?= Do >> you think the current message length handles it? >=20 > If a message length today is off by 1 or 2, it can be detected as soon > as the next message header is received, regardless of any payload. That is NOT the case in my example above. Message length is within 4096 bytes (say 4050 bytes) while the actual message was in few hundreds of bytes. With aggressive keepalive times or partial writes your going to hit such cases even with 4096 bytes. That was my point. -Keyur From jsw@inconcepts.biz Sun Apr 17 17:37:47 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D6083E06CF for ; Sun, 17 Apr 2011 17:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUO7XSGKt4a0 for ; Sun, 17 Apr 2011 17:37:47 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 3AD24E068B for ; Sun, 17 Apr 2011 17:37:47 -0700 (PDT) Received: by vxg33 with SMTP id 33so3962978vxg.31 for ; Sun, 17 Apr 2011 17:37:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.96.138 with SMTP id ds10mr2363677vdb.11.1303087066903; Sun, 17 Apr 2011 17:37:46 -0700 (PDT) Received: by 10.220.177.11 with HTTP; Sun, 17 Apr 2011 17:37:46 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: Date: Sun, 17 Apr 2011 20:37:46 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 00:37:48 -0000 On Sun, Apr 17, 2011 at 8:28 PM, Keyur Patel wrote: >> If a message length today is off by 1 or 2, it can be detected as soon >> as the next message header is received, regardless of any payload. > > That is NOT the case in my example above. Message length is within 4096 > bytes (say 4050 bytes) while the actual message was in few hundreds of > bytes. With aggressive keepalive times or partial writes your going to hi= t > such cases even with 4096 bytes. That was my point. Yes, but you fail to understand what induces the parser to be looking for a wrong-length message. Yes, the remote neighbor can say "4050 octets coming" and only send 200. We agree that this is bad and there just isn't anything to be done about it, except wait for the arrival of 3850 octets and then fail to parse the next header. The problem is if the remote neighbor says "199" octets are coming, and then transmits 200. What happens? Currently, the LENGTH of the next message will be, from the parser's perspective, in the wrong place -- it will see the most-significant-octet as 0xFF (last octet of MARKER), immediately detect this failure (because LENGTH is > 4096), and we will know right away that either the neighbor malfunctioned, or our parser malfunctioned. If we allow LENGTH to be > 0xFEFF then the above off-by-one case will NOT be immediately detected, the last octet of MARKER will mistakenly be seen as the most-significant-octet of LENGTH, and we will be waiting for at least 65280 octets of data to arrive from the neighbor. The issue isn't simply "the remote neighbor could compute or send the wrong length." I know it could. The issue is I don't want common off-by-one cases to be hard to detect/troubleshoot. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From glen.kent@gmail.com Sun Apr 17 18:36:07 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E5F1EE075D for ; Sun, 17 Apr 2011 18:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y60bxzNilZxe for ; Sun, 17 Apr 2011 18:36:07 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 48F96E0756 for ; Sun, 17 Apr 2011 18:36:07 -0700 (PDT) Received: by vws12 with SMTP id 12so3998072vws.31 for ; Sun, 17 Apr 2011 18:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NWIWY1mMfA/B4qfvtmifp4frvULDtyAqnR6JvojO1R0=; b=djRT7uwQXQnNX6xYm3yuWd6H99F7Rp+0niRy1YEaOpkCiv+IWoF9x1cttBOf+ltSZV EadUjlZGJ5sI7iJ9CFHzMja5wwq6NCOFZuXgtO10akEM9e/w4NNGJSZUX2BRcdEhwpGq eyl8rj+teZ9qJZCOLtzkGPakQIjdbtgxvtGec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wDxxiPHuDsm7ptVmuepsItsmD9sGA+VpXQccApdXr5GaqMvBZiwPc0CMaZpdD5h7Ya UgLco3U2/El/UJC3HNeEq/SOZnNAfQd4a62LFBtfmuZK1V0+sEMuXHFlZ1dE1cwpguSi BCZefrGgTF895kZtXlaCbqv3UVOf/EYg53LNQ= MIME-Version: 1.0 Received: by 10.52.174.38 with SMTP id bp6mr6466492vdc.90.1303090565795; Sun, 17 Apr 2011 18:36:05 -0700 (PDT) Received: by 10.52.166.193 with HTTP; Sun, 17 Apr 2011 18:36:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2011 07:06:05 +0530 Message-ID: From: Glen Kent To: Jeff Wheeler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 01:36:08 -0000 Jeff, > The problem is if the remote neighbor says "199" octets are coming, > and then transmits 200. =A0What happens? =A0Currently, the LENGTH of the Why will this ever happen? Glen > next message will be, from the parser's perspective, in the wrong > place -- it will see the most-significant-octet as 0xFF (last octet of > MARKER), immediately detect this failure (because LENGTH is > 4096), > and we will know right away that either the neighbor malfunctioned, or > our parser malfunctioned. > > If we allow LENGTH to be > 0xFEFF then the above off-by-one case will > NOT be immediately detected, the last octet of MARKER will mistakenly > be seen as the most-significant-octet of LENGTH, and we will be > waiting for at least 65280 octets of data to arrive from the neighbor. > > The issue isn't simply "the remote neighbor could compute or send the > wrong length." =A0I know it could. =A0The issue is I don't want common > off-by-one cases to be hard to detect/troubleshoot. > > -- > Jeff S Wheeler > Sr Network Operator=A0 /=A0 Innovative Network Concepts > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From randy@psg.com Sun Apr 17 20:14:47 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B161CE0765 for ; Sun, 17 Apr 2011 20:14:47 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBUCFueeWKso for ; Sun, 17 Apr 2011 20:14:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 3D0C0E075E for ; Sun, 17 Apr 2011 20:14:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QBevE-0000K5-F9; Mon, 18 Apr 2011 03:14:45 +0000 Date: Mon, 18 Apr 2011 12:15:10 +0900 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20110417225615.GU11808@slice> References: <20110322212324.GI9210@diehard.n-r-g.com> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> <20110324164219.GI11857@diehard.n-r-g.com> <20110417132345.GD11808@slice> <20110417225615.GU11808@slice> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 03:14:47 -0000 > Another observation is that if the trailing NLRI contains 0xff in the > byte stream, we still have a variant of this issue. cosmic ray hits length but misses next 2 megabytes! =A0news at 11. randy From jie.dong@huawei.com Mon Apr 18 00:50:12 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 571A4E079A for ; Mon, 18 Apr 2011 00:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h63e4m3QsTiE for ; Mon, 18 Apr 2011 00:50:11 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 2A753E078A for ; Mon, 18 Apr 2011 00:50:11 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJU006CC8ESQ3@szxga05-in.huawei.com> for idr@ietf.org; Mon, 18 Apr 2011 15:49:40 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJU00J7B8ERHB@szxga05-in.huawei.com> for idr@ietf.org; Mon, 18 Apr 2011 15:49:40 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Apr 2011 15:49:35 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.8.154]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Mon, 18 Apr 2011 15:49:39 +0800 Date: Mon, 18 Apr 2011 07:49:37 +0000 From: Jie Dong In-reply-to: <20110417162207.GM11808@slice> X-Originating-IP: [10.110.98.34] To: Jeffrey Haas Message-id: <76CD132C3ADEF848BD84D028D243C927AFB42E@szxeml508-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" Thread-index: AQHL/RvF29jCXeMx3kaaCRF/yLyrG5RjMfAg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> <20110417162207.GM11808@slice> Cc: "idr@ietf.org" Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 07:50:12 -0000 Hi Jeff, > I support adoption of this draft as a working group item. Thanks for your support. > However, I also strongly request that the IPv6 RTC be moved to a > different code point, whether AFI or SAFI. This would avoid muddying the > semantics of an 12 byte RTC vs. the 20 byte RTC. This could be one solution to achieve support of IPv6 RT, though IMO IPv6 RT may also be used for address families other than IPv6. We'd like to hear opinions on defining new code point for IPv6 RTC. FYI, the other part of the previous version (-00) includes specification of per AF RTC. This may be needed with the emergence of new VPN services, e.g. e-vpn etc. AFI/SAFI specific RT-constrain would be described later in a separate draft. We'd also like to hear feedbacks on defining AFI or AFI/SAFI specific RT-constrain. > As an example, the type and subtype fields of both regular AS-based route > targets are identical with the IPv6 route target. It's unclear if the RTC > prefix is /64 if the two octets not including the type/subtype are intended > to be IP address or AS. Yes this is an issue the authors had discussed. In current draft it defines aggregation rules of RTC prefix in section 3: "only the Local Administrator field of the Route Target can be aggregated. Route Target Type and the Global Administrator Route Target fields MUST not be aggregated." This way the length range of this two types of RTC prefix will not be overlapped, then length field could be used to distinguish the two RT types. Further comments would be appreciated. Many thanks, Jie From stephane.litkowski@orange-ftgroup.com Mon Apr 18 06:04:07 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AA02EE0693 for ; Mon, 18 Apr 2011 06:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.824 X-Spam-Level: * X-Spam-Status: No, score=1.824 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FRT_INTEREST=3.579, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xECdVo5439V1 for ; Mon, 18 Apr 2011 06:04:06 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfc.amsl.com (Postfix) with ESMTP id 5DEA6E0664 for ; Mon, 18 Apr 2011 06:04:06 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 1D8872AC36E for ; Mon, 18 Apr 2011 15:04:05 +0200 (CEST) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id E3A48180054 for ; Mon, 18 Apr 2011 15:04:04 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Apr 2011 15:04:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBFDC9.1778A159" Date: Mon, 18 Apr 2011 15:04:09 +0200 Message-ID: <5813_1303131845_4DAC36C5_5813_694222_1_4FC3556A36EE3646A09DAA60429F5335063AEF4B@PUEXCBL0.nanterre.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-l3vpn-ibgp-02.txt Thread-Index: Acv9yRsDmnE3MoNkRHapbHJEFtMhNw== From: To: X-OriginalArrivalTime: 18 Apr 2011 13:04:04.0788 (UTC) FILETIME=[1848F740:01CBFDC9] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.18.115416 Subject: [Idr] Comments on draft-ietf-l3vpn-ibgp-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:04:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFDC9.1778A159 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, =20 =20 * Regarding $7 : =20 If you consider a VPN that spans across multiple service provider ASes, when the egress PE is advertising the VPN route (coming from iBGP CE peer at ingress PE) towards an eBGP CE, does the PE prepends only his own AS after prepending customer origin AS (as it seems to be mentionned in the statement below), or do you think there is an interrest to prepend the all "backbone" ASPATH ? : =20 "When advertising the VRF route to an Exterior BGP peer, a PE router shall apply steps 1 to 3 defined above and subsequently prepend its own autonomous-system number to the AS_PATH attribute." =20 I'm wondering in some tricky scenarios , when a customer has multiple MPLS VPN providers (for backup purpose), if there is a need (like for eBGP PE-CE) to reflect the backbone ASPATH to prefer the provider with the shortest ASPATH length. =20 =20 * Regarding ATTR_SET attribute and BGP update storage/generation, I don't think that there is an impact on update generation (mainly packing) by Service Provider route-reflectors, but I would be interrested if someone see something bad in this area. But even if there is no impact (TBC) on generating updates by the Service Provider route-reflectors, I think there could be an impact : - on memory usage : mainly depending on how much informations are stored in ATTR_SET, moreover it would be hard to share datastructures between different customer routes (as attributes are "customer dependent") =20 - on size of BGP datas transmitted on the TCP session and so impact on time to transfer it =20 =20 * It is sometime useful that VPN CEs advertise special "Backbone" communities to the service provider to permit for example for a remote PE to select his own prefered egress PE (loadsharing scenario). With ATTR_SET, attributes from CE are tunneled and are no more visible from the service provider. Due to this, the previous scenario is no more achievable and customer can't anymore use Backbone communities to influence service provider backbone behavior. =20 =20=20=20=20 Regards, =20 Stephane =20 ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** ------_=_NextPart_001_01CBFDC9.1778A159 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
 
* Regardi= ng $7=20 :
 
If you co= nsider a=20 VPN that spans across multiple service provider ASes, when the egress = PE is=20 advertising the VPN route (coming from iBGP CE peer at ingress PE) towards = an=20 eBGP CE, does the PE prepends only his own AS after prepending custome= r=20 origin AS (as it seems to be mentionned in the statement below), or do= you=20 think there is an interrest to prepend the all "backbone" ASPATH=20 ? :
 
"When adv= ertising=20 the VRF route to an Exterior BGP peer, a PE
    &nbs= p;=20 router shall apply steps 1 to 3 defined above and=20 subsequently
      prepend its own autonomous-s= ystem=20 number to the AS_PATH attribute."
 
I'm wonde= ring =20 in some tricky scenarios , when a customer has multiple MPLS VPN provi= ders=20 (for backup purpose), if there is a need (like for eBGP PE-CE) to reflect t= he=20 backbone ASPATH to prefer the provider with the shortest ASPATH=20 length.
 
 
* Regardi= ng ATTR_SET=20 attribute and BGP update storage/generation,  I don't think that there= is=20 an impact on update generation (mainly packing) by Service Provider=20 route-reflectors, but I would be interrested if someone see something bad i= n=20 this area. But even if there is no impact (TBC) on generating updates by th= e=20 Service Provider route-reflectors, I think there could be an impact=20 :
    - on memory usage : main= ly=20 depending on how much informations are stored in ATTR_SET, moreover it= =20 would be hard to share datastructures between different customer=20 routes (as attributes are "customer dependent")
 
 &nb= sp;  -=20 on size of BGP datas transmitted on the TCP session and so impact on time t= o=20 transfer it
 
 
* It= is=20 sometime useful that VPN CEs  advertise special "Backbone" commun= ities=20 to the service provider to permit for example for a remote PE to select&nbs= p;his=20 own prefered egress PE (loadsharing scenario). With ATTR_SET, attribut= es=20 from CE are tunneled and are no more visible from the service provider. Due= to=20 this, the previous scenario is no more achievable and customer can't anymor= e use=20 Backbone communities to influence service provider backbone=20 behavior.
 
 &nb= sp; =20
Regards,
 
Stephane
 
*****************=
***************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris=
 les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) men=
tionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve=
uillez immediatement le signaler  a l expediteur et effacer ce message=20
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans=
 ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment=
 s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout vi=
rus.

IMPORTANT.This e-mail message and any attachments are strictly confidential=
 and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(=
s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not b=
e liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
***************************************************************************=
*****
------_=_NextPart_001_01CBFDC9.1778A159-- From jhaas@slice.pfrc.org Mon Apr 18 06:54:58 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 84A64E076B for ; Mon, 18 Apr 2011 06:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.881 X-Spam-Level: X-Spam-Status: No, score=-101.881 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkY-taSRDdOe for ; Mon, 18 Apr 2011 06:54:58 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfc.amsl.com (Postfix) with ESMTP id F1F84E0700 for ; Mon, 18 Apr 2011 06:54:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 900BE224329; Mon, 18 Apr 2011 13:54:57 +0000 (UTC) Date: Mon, 18 Apr 2011 13:54:57 +0000 From: Jeffrey Haas To: Jie Dong Message-ID: <20110418135457.GD7824@slice> References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> <20110417162207.GM11808@slice> <76CD132C3ADEF848BD84D028D243C927AFB42E@szxeml508-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76CD132C3ADEF848BD84D028D243C927AFB42E@szxeml508-mbs.china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "idr@ietf.org" Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:54:58 -0000 On Mon, Apr 18, 2011 at 07:49:37AM +0000, Jie Dong wrote: > > As an example, the type and subtype fields of both regular AS-based route > > targets are identical with the IPv6 route target. It's unclear if the RTC > > prefix is /64 if the two octets not including the type/subtype are intended > > to be IP address or AS. > > Yes this is an issue the authors had discussed. In current draft it defines aggregation rules of RTC prefix in section 3: > "only the Local Administrator field of the Route Target can be aggregated. Route Target Type and the Global Administrator Route Target fields MUST not be aggregated." > This way the length range of this two types of RTC prefix will not be overlapped, then length field could be used to distinguish the two RT types. As long as the l3vpn wg is willing to constrain future formats for route targets in a way that accommodates this, it might work. Have you asked them if they're willing to commit to such a restriction? As a more general statement, since formats may pop up faster than the matching RTC restriction on that type(/subtype), doesn't it make sense to simply make sure the spec be able to handle arbitrary lengths? The base RTC spec effectively does this already with the restriction on the prefix length being 0,32<=n<=96. While a number of such lengths are nonsensical from a global/local perspective, the protocol still deals with them. E.g. anything that matches on "all 2-byte AS RT" can be encoded, but it's silly. But it's certainly simpler than saying "if the first two octets of the RT portion of the RTC contain the following values, the prefix length is restricted to being between...." -- Jeff From jsw@inconcepts.biz Mon Apr 18 08:17:34 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8BD32E0776 for ; Mon, 18 Apr 2011 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X10mv2rF9W2k for ; Mon, 18 Apr 2011 08:17:34 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 0BE24E06DD for ; Mon, 18 Apr 2011 08:17:33 -0700 (PDT) Received: by vxg33 with SMTP id 33so4495103vxg.31 for ; Mon, 18 Apr 2011 08:17:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.176.98 with SMTP id ch2mr1116914vdc.51.1303139853345; Mon, 18 Apr 2011 08:17:33 -0700 (PDT) Received: by 10.220.177.11 with HTTP; Mon, 18 Apr 2011 08:17:33 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: Date: Mon, 18 Apr 2011 11:17:33 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:17:34 -0000 On Sun, Apr 17, 2011 at 9:36 PM, Glen Kent wrote: > Jeff, > >> The problem is if the remote neighbor says "199" octets are coming, >> and then transmits 200. =A0What happens? =A0Currently, the LENGTH of the > > Why will this ever happen? You've never heard vendors explain malfunctions as "oops, it was an off-by-one bug?" This happens in real-world, production code. We should not make that harder to debug. The proposed change does exactly that: makes a common protocol implementation bug harder to diagnose/debug. Again, Glen, the cost of keeping the existing fault detection mechanism is 256 octets of message length, or 0.4% of the proposed maximum. Do you think that 256 octets is essential? Is there anyone who believes we need 65535 octets instead of 65279 octets? You can talk this to death without understanding implementation issues, but the simple fact remains that this fault detection mechanism has always existed in BGP, and the draft proposes to remove it to gain an inconsequential amount of payload. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jie.dong@huawei.com Mon Apr 18 19:20:35 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 13518E0611 for ; Mon, 18 Apr 2011 19:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.858 X-Spam-Level: X-Spam-Status: No, score=-3.858 tagged_above=-999 required=5 tests=[AWL=2.141, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY-ewa1GmY3r for ; Mon, 18 Apr 2011 19:20:34 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 37438E0674 for ; Mon, 18 Apr 2011 19:20:34 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJV00IGINU7U0@szxga03-in.huawei.com> for idr@ietf.org; Tue, 19 Apr 2011 10:20:31 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJV00AN1NU7T8@szxga03-in.huawei.com> for idr@ietf.org; Tue, 19 Apr 2011 10:20:31 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Apr 2011 10:18:31 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.8.154]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 10:20:31 +0800 Date: Tue, 19 Apr 2011 02:20:30 +0000 From: Jie Dong In-reply-to: <20110418135457.GD7824@slice> X-Originating-IP: [10.110.98.34] To: Jeffrey Haas Message-id: <76CD132C3ADEF848BD84D028D243C927AFB8D6@szxeml508-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" Thread-index: AQHL/RvF29jCXeMx3kaaCRF/yLyrG5RjMfAg///uI4CAAUghoA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> <20110417162207.GM11808@slice> <76CD132C3ADEF848BD84D028D243C927AFB42E@szxeml508-mbs.china.huawei.com> <20110418135457.GD7824@slice> Cc: "idr@ietf.org" Subject: Re: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 02:20:35 -0000 Hi Jeff, Thanks for sharing your opinions on this. > As long as the l3vpn wg is willing to constrain future formats for route > targets in a way that accommodates this, it might work. Have you asked > them > if they're willing to commit to such a restriction? We will ask L3VPN on this after the adoption. AFAIK, currently the use of RTC prefix aggregation is only mentioned in MVPN, in which only the local administrator field is aggregated. > As a more general statement, since formats may pop up faster than the > matching RTC restriction on that type(/subtype), doesn't it make sense to > simply make sure the spec be able to handle arbitrary lengths? The base > RTC > spec effectively does this already with the restriction on the prefix length > being 0,32<=n<=96. While a number of such lengths are nonsensical from a > global/local perspective, the protocol still deals with them. If there is consensus, aggregation rule in the base RTC may also be updated to represent only reasonable prefix lengths. > E.g. anything that matches on "all 2-byte AS RT" can be encoded, but it's > silly. But it's certainly simpler than saying "if the first two octets of > the RT portion of the RTC contain the following values, the prefix length is > restricted to being between...." This may be true in specifying the rules. OTOH, more specific aggregation rule may make the matching process of RTC prefixes simpler. Regards, Jie From curtis@occnc.com Mon Apr 18 21:50:08 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AAD4BE0696 for ; Mon, 18 Apr 2011 21:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp59302sdGur for ; Mon, 18 Apr 2011 21:50:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 1B416E068E for ; Mon, 18 Apr 2011 21:50:07 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3J4o1ER019757; Tue, 19 Apr 2011 00:50:01 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104190450.p3J4o1ER019757@harbor.orleans.occnc.com> To: Jakob Heitz From: Curtis Villamizar In-reply-to: Your message of "Sat, 16 Apr 2011 00:04:32 EDT." <7309FCBCAE981B43ABBE69B31C8D21390E3F8D615D@EUSAACMS0701.eamcs.ericsson.se> Date: Tue, 19 Apr 2011 00:50:01 -0400 Sender: curtis@occnc.com Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 04:50:08 -0000 In message <7309FCBCAE981B43ABBE69B31C8D21390E3F8D615D@EUSAACMS0701.eamcs.ericsson.se> Jakob Heitz writes: > > Your point is that it's senseless to try to > fit the whole message into the error message. > I get that point. > > Now, do you get mine? > Never mind if you agree with it or not, do you get it? > > -- > Jakob Heitz. Yes we get it and to repeat a prior point, if the implementation is *that* brokend it doesn't belong on the Internet, return it to the vendor and demand a refund. Curtis > > -----Original Message----- > > From: Randy Bush [mailto:randy@psg.com] > > Sent: Friday, April 15, 2011 8:14 PM > > To: Jakob Heitz > > Cc: curtis@occnc.com; Keyur Patel; idr@ietf.org > > Subject: Re: [Idr] New Version Notification for > > draft-ymbk-bgp-extended-messages-02 > > > > > Say message 1 had the wrong length. I don't detect it. > > > Then message 2 breaks. I send a notification for malformed message, > > > including message 2. This will confuse the debugging effort, > > > because the real problem was message 1. > > > > what happens if it is ten times around? > > > > people don't seem to get it. the bgp message is X. if you need more > > for something else, make something else larger. use X+20k or > > whatever. > > > > randy From curtis@occnc.com Mon Apr 18 23:22:49 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8DFF5E06EF for ; Mon, 18 Apr 2011 23:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeio+g9CydSf for ; Mon, 18 Apr 2011 23:22:48 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 8F461E06CC for ; Mon, 18 Apr 2011 23:22:48 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3J6Mkqx021003; Tue, 19 Apr 2011 02:22:46 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104190622.p3J6Mkqx021003@harbor.orleans.occnc.com> To: Jeff Wheeler From: Curtis Villamizar In-reply-to: Your message of "Mon, 18 Apr 2011 11:17:33 EDT." Date: Tue, 19 Apr 2011 02:22:46 -0400 Sender: curtis@occnc.com Cc: idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 06:22:49 -0000 In message Jeff Wheeler writes: > > On Sun, Apr 17, 2011 at 9:36 PM, Glen Kent wrote: > > Jeff, > > > >> The problem is if the remote neighbor says "199" octets are coming, > >> and then transmits 200.  What happens?  Currently, the LENGTH of the > > > > Why will this ever happen? > > You've never heard vendors explain malfunctions as "oops, it was an > off-by-one bug?" This happens in real-world, production code. We > should not make that harder to debug. The proposed change does > exactly that: makes a common protocol implementation bug harder to > diagnose/debug. > > Again, Glen, the cost of keeping the existing fault detection > mechanism is 256 octets of message length, or 0.4% of the proposed > maximum. Do you think that 256 octets is essential? Is there anyone > who believes we need 65535 octets instead of 65279 octets? > > You can talk this to death without understanding implementation > issues, but the simple fact remains that this fault detection > mechanism has always existed in BGP, and the draft proposes to remove > it to gain an inconsequential amount of payload. > > -- > Jeff S Wheeler > Sr Network Operator  /  Innovative Network Concepts If you want to solve *that* problem, then don't try to solve it in extended-messages, start a whole new draft and solve it. Create a new capability that indicates that PPP style byte stuffing will take place, replacing all FF with FE FF and all FE with FE FE, excpet in the marker. Then you can always identify a correct marker as FF FF, because that can't occur in the payload. Then you can ask vendors to implement this and see if the number of off by one errors go up or go down. It is from a protocol design standpoint bulletproof. It adds a little complexity and the cure may be worse than the existing sympton, but you'll always be able to identify the symptom when it turns up. Curtis From jsw@inconcepts.biz Tue Apr 19 10:05:48 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2B7A5E079F for ; Tue, 19 Apr 2011 10:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXDGBDXeUoVM for ; Tue, 19 Apr 2011 10:05:47 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 690F6E0712 for ; Tue, 19 Apr 2011 10:05:47 -0700 (PDT) Received: by vws12 with SMTP id 12so5577182vws.31 for ; Tue, 19 Apr 2011 10:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.185.197 with SMTP id fe5mr792115vdc.131.1303232746893; Tue, 19 Apr 2011 10:05:46 -0700 (PDT) Received: by 10.220.177.11 with HTTP; Tue, 19 Apr 2011 10:05:46 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <201104190622.p3J6Mkqx021003@harbor.orleans.occnc.com> References: <201104190622.p3J6Mkqx021003@harbor.orleans.occnc.com> Date: Tue, 19 Apr 2011 13:05:46 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:05:48 -0000 On Tue, Apr 19, 2011 at 2:22 AM, Curtis Villamizar wrote= : > If you want to solve *that* problem, then don't try to solve it in > extended-messages, start a whole new draft and solve it. Curtis, again, BGP has had this protection against confusing the LENGTH field with the MARKER field since BGP version 1. This is not something that people are trying to sneak in to an unrelated draft. In fact, it's the opposite. Increasing the LENGTH upper-bound has header validation implications that are non-obvious. I'm pretty sure Randy still "doesn't get it" since his every post on this subject has, as yours does, referred to byte-stuffing. Do you know how many posts there have been that advocate increasing the message length to 0xFFFF, acknowledge that the existing fault detection mechanism for off-by-one/two is being removed, and state that 0.4% more payload (256 octets) is worth losing that *already existing, since BGP v1* header check? There are exactly zero posts advocating this position while acknowledging that they understand the cost/benefit. That's the issue here: this isn't that easy to understand, and the process is being driven by folks who haven't taken the time to read a little more carefully. Let me put it this way: Do you think, that if the draft authors knew they would affect header validation when they were originally writing this proposal, that they would have said "oh, no big deal," and gone ahead with 65,535 octets of message length? Or would they have said, "well, we can get to 65,279 octets without significant affect on the protocol or code, let's do that?" I'm pretty sure they would have gone with the smaller figure. What you see now is a bunch of folks going "I don't understand these implementation issues," or "you're asking for something new," (not true; the draft breaks something that exists). Except Randy, who has not contributed anything useful at all, unless you consider his "cosmic ray" and "SLIP" posts, which indicate he still does not understand that we're talking about things that happen as a result of common implementation bugs, not random bit-flips on the wire, as productive. If this is really over his head, so be it; but I think the true case is Randy is simply stubborn, does not want to do an s/65535/65279/ on the draft, does not have any good argument to defend his position (0.4% of payload, remember?), and so is playing stupid, and dragging some of you guys along for the ride. Again, any reference to SLIP, cosmic rays, etc. is foolish and outside the scope of this discussion. Go back and re-read my earlier posts if you are still confused on this. The issue is implementation bugs, and how this draft will make some of them more difficult to troubleshoot -- it has nothing at all to do with bit-flips on the wire. If you're saying "PPP" or anything remotely similar, the discussion is still going over your head. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From pedro.r.marques@gmail.com Tue Apr 19 10:14:55 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B80A8E0821; Tue, 19 Apr 2011 10:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n++tAMRCPIj0; Tue, 19 Apr 2011 10:14:55 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id DD4E4E079D; Tue, 19 Apr 2011 10:14:54 -0700 (PDT) Received: by iwn39 with SMTP id 39so6535500iwn.31 for ; Tue, 19 Apr 2011 10:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bc+elWflTtq7k9lgfJQpKgcJThwIFhlaMX8vJOuqdTk=; b=usR6L04yoO0ejGGaFkpJVh7b4G0TOK8jhMwcWYNcFkmXj1SE5qU3r70Gs0cNONXO/R I8RlAUgphB3XOesCM3DWDwXi9C2Mja7TRo6ROGpVeS3+CPjpYkk3u/5LgDl/uLYXx+2o aBHDpudJ7TsGpUCTzRNPWszfEQhnfOhQ2RF9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tiCrcQNOyaf++z9/KP+mpYRy5d20gr+GiZq6XNUcUkeGlt2Rh6UNJ7K82q0jgA1Rj7 2x4nWZFKk3gULpLOWaYeJuMmK4fBwE94FHCrWOFl99SaAHF8GrrbUKvE2QrO9nj58mdj cZNNYBWPoV9A8VjusNo02Ig61z5kxE3+F7PiM= MIME-Version: 1.0 Received: by 10.42.230.67 with SMTP id jl3mr2869958icb.512.1303233294476; Tue, 19 Apr 2011 10:14:54 -0700 (PDT) Received: by 10.42.164.137 with HTTP; Tue, 19 Apr 2011 10:14:54 -0700 (PDT) In-Reply-To: <5813_1303131845_4DAC36C5_5813_694222_1_4FC3556A36EE3646A09DAA60429F5335063AEF4B@PUEXCBL0.nanterre.francetelecom.fr> References: <5813_1303131845_4DAC36C5_5813_694222_1_4FC3556A36EE3646A09DAA60429F5335063AEF4B@PUEXCBL0.nanterre.francetelecom.fr> Date: Tue, 19 Apr 2011 10:14:54 -0700 Message-ID: From: Pedro Marques To: stephane.litkowski@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr@ietf.org, l3vpn@ietf.org Subject: Re: [Idr] Comments on draft-ietf-l3vpn-ibgp-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:14:55 -0000 Stephane, Thank you for your comments. Answers inline. On Mon, Apr 18, 2011 at 6:04 AM, w= rote: > Hi all, > > > * Regarding $7 : > > If you consider a VPN that spans=A0across multiple service provider ASes,= when > the egress PE is advertising the VPN route (coming from iBGP CE peer at > ingress PE) towards an eBGP CE,=A0does the PE prepends only his own AS af= ter > prepending customer origin AS (as it seems to be mentionned in the statem= ent > below), or=A0do you think there is an interrest to prepend the all "backb= one" > ASPATH ?=A0: > > "When advertising the VRF route to an Exterior BGP peer, a PE > =A0=A0=A0=A0=A0 router shall apply steps 1 to 3 defined above and subsequ= ently > =A0=A0=A0=A0=A0 prepend its own autonomous-system number to the AS_PATH a= ttribute." > > I'm wondering=A0 in some tricky scenarios , when a customer=A0has multipl= e MPLS > VPN providers (for backup purpose), if there is a need (like for eBGP PE-= CE) > to reflect the backbone ASPATH to prefer the provider with the shortest > ASPATH length. That is a good point. In order to be consistent with the eBGP behavior it is best to prepend both the AS_PATH of the VPN route and its own autonomous-system number, in case the AS_PATH is not empty. > > * Regarding ATTR_SET attribute and BGP update storage/generation,=A0 I do= n't > think that there is an impact on update generation (mainly packing) by > Service Provider route-reflectors, but I would be interrested if someone = see > something bad in this area. This mechanism has been deployed in production for over 5 years. I'm not aware of "something bad" happening. The ATTR_SET attribute doesn't significantly change the packing of updates. > But even if there is no impact (TBC) on > generating updates by the Service Provider route-reflectors, I think ther= e > could be an impact : > =A0=A0=A0=A0- on memory usage : mainly depending on how much informations= are stored > in ATTR_SET, moreover=A0it would be hard to share datastructures=A0betwee= n > different customer routes=A0(as attributes are "customer dependent") In the worst case scenario, each customer route has its own unique set of attributes. That worst case scenario can occur today via the use of communities. The common case is for different sets of CE route attributes to be providing useful information and be advertised through the VPN network, either with the current ebgp PE-CE interaction or with the method that is proposed in this document. > > =A0=A0=A0 - on size of BGP datas transmitted on the TCP session and so im= pact on > time to transfer it The added size to updates is statistically insignificant considering link bandwidth. > > > *=A0It is sometime useful that=A0VPN CEs=A0 advertise special "Backbone" > communities to the service provider to permit for example for a remote PE= to > select=A0his own=A0prefered egress PE (loadsharing scenario). With ATTR_S= ET, > attributes from CE are tunneled and are no more visible from the service > provider. Due to this, the previous scenario is no more achievable and > customer can't anymore use Backbone communities to influence service > provider backbone behavior. There is no reason to believe that the VPN export policies that compute the VPN network attributes cannot impose communities depending on the attributes of the CE routes. I also note that this document is not ment to replace but to complement the existing EBGP based PE-CE iteration. But contrary to the current mechanism, the default is to segregate attributes between the two networks. As the document explains there are several scenarios in which this proposal enables a simpler behavior. regards, Pedro. From curtis@occnc.com Tue Apr 19 13:33:24 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 594A1E087C for ; Tue, 19 Apr 2011 13:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YUiG7QKEeWf for ; Tue, 19 Apr 2011 13:33:23 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 72F21E086F for ; Tue, 19 Apr 2011 13:33:23 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3JKXL8T051434; Tue, 19 Apr 2011 16:33:21 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104192033.p3JKXL8T051434@harbor.orleans.occnc.com> To: raszuk@cisco.com From: Curtis Villamizar In-reply-to: Your message of "Sun, 17 Apr 2011 16:26:50 +0200." <4DAAF8AA.6060303@cisco.com> Date: Tue, 19 Apr 2011 16:33:21 -0400 Sender: curtis@occnc.com Cc: "idr@ietf.org List" Subject: Re: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 20:33:24 -0000 In message <4DAAF8AA.6060303@cisco.com> Robert Raszuk writes: > > Hi, > > Jakob and Jeff's emails triggered me to think if the overall approach > here to extending all BGP messages size is the right one. > > Let's realize that: > > - To send 4096 octets msg on 10 Mbit/s wire takes 3.28 sec > - To send 65535 octets msg on 10 Mbit/s wire takes 52.43 sec ! > > No congestion, no delays ... pure best case numbers. Robert, 65535 * 8 = 524,280 bits at 56kb/sec its under 10 sec, but grandma is now using DSL so her BGP is going a bit faster than that. You need to use faster-light. The real problem is the TCP default 3 sec after losing some packets. Then assuming a recent TCP that starts with 4 segments, it may take a quite a few RTT to get a packet across. With no loss, start with 4 segments and double each RTT. For a 100 msec RTT it is well under a second. So worst case is probably on the order of 5 seconds if loss is moderate, maybe 10 seconds or more if loss is really high. Curtis > Now add to this time for acks, some router CPU delay, some I/O > processing or worse some congestion or slow peer case and we are off the > cliff. > > I like the summary Jeff sent indicating a real consequences for implicit > bound on current BGP attributes. Do we want to redefine BGP spec and > subsequent specs so fundamentally now to try only one proposal of > available number of others in the BGP security area ? > > The answer I think is pretty obvious. > > So let me propose that all elements related to securing BGP would be > contain in a new message all together. (Perhaps new SAFI perhaps not .. > I am not sure yet). > > That would allow zero impact to Internet IPv4 and IPv6 routing as we > know it today, gradual deployment etc ... > > Here one also needs to keep in mind that all additional AS signatures as > proposed today would be duplicated or N-plicated for each AFI/SAFI > individually. > > You would use the same space amount of information to sign IPv4 updates > as IPv6 updates. Leave alone the encapsulation part .. but storing and > processing the same thing many times seems to me like really waist. > > The open issues are how to couple the secure BGP message with normal BGP > message if such coupling at all is needed. Even if we would duplicate > MP_REACH_NLRI into such Secure messages it still seems worth. > > Another advantage is processing ... If we combine the secure BGP > overhead with current BGP UPDATE message you like it or not it will have > to be handled by today's old fashion general BGP CPU processing. But if > this is defined as a separate message .. maybe even on separate session > (by enforcing multisession on it) it could be all together easily > processed by some other CPU/CPU core/programmable FPGA or ASIC without > causing any burden and delay to current BGP processing. That would very > nicely allow to decouple the functions and only pass final decision to > main core BGP as prefix X - valid .. prefix Y - invalid. > > Many thx, > R. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From curtis@occnc.com Tue Apr 19 15:01:13 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 02767E06C7 for ; Tue, 19 Apr 2011 15:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw9XnX+IxUDh for ; Tue, 19 Apr 2011 15:01:12 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id DD191E08BD for ; Tue, 19 Apr 2011 15:01:11 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3JM1BDJ053229; Tue, 19 Apr 2011 18:01:11 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104192201.p3JM1BDJ053229@harbor.orleans.occnc.com> To: Jeff Wheeler From: Curtis Villamizar In-reply-to: Your message of "Tue, 19 Apr 2011 13:05:46 EDT." Date: Tue, 19 Apr 2011 18:01:11 -0400 Sender: curtis@occnc.com Cc: idr@ietf.org Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:01:13 -0000 Jeff, Nice rant. :) Comments inline. In message Jeff Wheeler writes: > > On Tue, Apr 19, 2011 at 2:22 AM, Curtis Villamizar wrote: > > If you want to solve *that* problem, then don't try to solve it in > > extended-messages, start a whole new draft and solve it. > > Curtis, again, BGP has had this protection against confusing the > LENGTH field with the MARKER field since BGP version 1. > > This is not something that people are trying to sneak in to an > unrelated draft. In fact, it's the opposite. Increasing the LENGTH > upper-bound has header validation implications that are non-obvious. > I'm pretty sure Randy still "doesn't get it" since his every post on > this subject has, as yours does, referred to byte-stuffing. The marker field is of limited value. I was maintaining the NSFNET BGP code as far back as the version 2 days so yes I am familiar with the marker and I quite sure Randy is too. Randy and I have been butting heads for more than 15 years so we sort of know each other by now. We all get off by one. We also get using a signed integer instead of unsigned, etc. > Do you know how many posts there have been that advocate increasing > the message length to 0xFFFF, acknowledge that the existing fault > detection mechanism for off-by-one/two is being removed, and state > that 0.4% more payload (256 octets) is worth losing that *already > existing, since BGP v1* header check? > > There are exactly zero posts advocating this position while > acknowledging that they understand the cost/benefit. So apparently somebody doesn't get it. Maybe its you. Off by one may be about as common as using a signed integer or any of a number of other bugs which would result in off by a lot more than one. An FFFF could be anywhere in the data. That is the point of byte stuffing to have a rock solid marker. A length slip will always be picked up fairly quickly. It is very difficult for it not to be picked up on the next packet. With stuffing it is always picked up immediately. But I've already said that the marker field is of limited value, so I'm not advocating byte stuffing, just suggesting that if you want a more robust marker, consider writing a draft that proposes to use byte stuffing to make the marker completely robust. Otherwise, if there is a slip, find a *potential* marker, interpret a few other fields, like the length, and resync based on getting a full valid packet, not just a valid looking marker. > That's the issue here: this isn't that easy to understand, and the > process is being driven by folks who haven't taken the time to read a > little more carefully. Is the point you are trying to make that if we don't agree with you we can't possibly understand? > Let me put it this way: Do you think, that if the draft authors knew > they would affect header validation when they were originally writing > this proposal, that they would have said "oh, no big deal," and gone > ahead with 65,535 octets of message length? Or would they have said, > "well, we can get to 65,279 octets without significant affect on the > protocol or code, let's do that?" I'm pretty sure they would have > gone with the smaller figure. Yes. I fully believe that the possibility of FFFF in the length field is not considered an issue and that the draft authors fully understand that the marker field is of limited value and accept this. > What you see now is a bunch of folks going "I don't understand these > implementation issues," or "you're asking for something new," (not > true; the draft breaks something that exists). Except Randy, who has > not contributed anything useful at all, unless you consider his > "cosmic ray" and "SLIP" posts, which indicate he still does not > understand that we're talking about things that happen as a result of > common implementation bugs, not random bit-flips on the wire, as > productive. If this is really over his head, so be it; but I think > the true case is Randy is simply stubborn, does not want to do an > s/65535/65279/ on the draft, does not have any good argument to defend > his position (0.4% of payload, remember?), and so is playing stupid, > and dragging some of you guys along for the ride. Clearly somebody doesn't understand. I've understood Randy's sarcasm. Terse but to the point. Sometimes its the most funny when the person Randy is responding to just doesn't get it and can't see the sarcasm. I ageee that Randy is stubborn. No one will dispute that. Not even Randy. :) > Again, any reference to SLIP, cosmic rays, etc. is foolish and outside > the scope of this discussion. Go back and re-read my earlier posts if > you are still confused on this. The issue is implementation bugs, and > how this draft will make some of them more difficult to troubleshoot > -- it has nothing at all to do with bit-flips on the wire. If you're > saying "PPP" or anything remotely similar, the discussion is still > going over your head. As long as Grandma's dual homed connectivity woes are still in scope, I'm OK with dropping any discussion on cosmic rays. > -- > Jeff S Wheeler > Sr Network Operator  /  Innovative Network Concepts Cheers, Curtis From randy@psg.com Tue Apr 19 17:43:29 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8E901E0703 for ; Tue, 19 Apr 2011 17:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7253F0AGtl0 for ; Tue, 19 Apr 2011 17:43:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 01DFDE069C for ; Tue, 19 Apr 2011 17:43:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QCLVv-000B5o-KQ; Wed, 20 Apr 2011 00:43:27 +0000 Date: Wed, 20 Apr 2011 09:43:56 +0900 Message-ID: From: Randy Bush To: Curtis Villamizar In-Reply-To: <201104192201.p3JM1BDJ053229@harbor.orleans.occnc.com> References: <201104192201.p3JM1BDJ053229@harbor.orleans.occnc.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr list Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 00:43:29 -0000 > Nice rant. :) Comments inline. you are far too patient, curtis. > Yes. I fully believe that the possibility of FFFF in the length field > is not considered an issue and that the draft authors fully understand > that the marker field is of limited value and accept this. yep > I ageee that Randy is stubborn. No one will dispute that. Not even > Randy. :) i refuse to dispute it! randy From curtis@occnc.com Tue Apr 19 20:36:04 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3514FE06AB for ; Tue, 19 Apr 2011 20:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adbAB3l4Z8pF for ; Tue, 19 Apr 2011 20:36:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 33574E0660 for ; Tue, 19 Apr 2011 20:36:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3K3a2RC069546; Tue, 19 Apr 2011 23:36:02 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104200336.p3K3a2RC069546@harbor.orleans.occnc.com> To: Randy Bush From: Curtis Villamizar In-reply-to: Your message of "Wed, 20 Apr 2011 09:43:56 +0900." Date: Tue, 19 Apr 2011 23:36:02 -0400 Sender: curtis@occnc.com Cc: idr list Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 03:36:04 -0000 In message Randy Bush writes: > > > Nice rant. :) Comments inline. > > you are far too patient, curtis. Few people accuse me of that. > > Yes. I fully believe that the possibility of FFFF in the length field > > is not considered an issue and that the draft authors fully understand > > that the marker field is of limited value and accept this. > > yep > > > I ageee that Randy is stubborn. No one will dispute that. Not even > > Randy. :) > > i refuse to dispute it! > > randy I thnik he may eventaully get it. Curtis From randy@psg.com Tue Apr 19 20:38:23 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 20DEBE0690 for ; Tue, 19 Apr 2011 20:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gACgcD6NNkd5 for ; Tue, 19 Apr 2011 20:38:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 98A21E0660 for ; Tue, 19 Apr 2011 20:38:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QCOFB-000BfG-A3; Wed, 20 Apr 2011 03:38:21 +0000 Date: Wed, 20 Apr 2011 12:38:50 +0900 Message-ID: From: Randy Bush To: Curtis Villamizar In-Reply-To: <201104200336.p3K3a2RC069546@harbor.orleans.occnc.com> References: <201104200336.p3K3a2RC069546@harbor.orleans.occnc.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr list Subject: Re: [Idr] New Version Notification for draft-ymbk-bgp-extended-messages-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 03:38:23 -0000 >> you are far too patient, curtis. > Few people accuse me of that. well, i doubt we need an impatience contest :) i procmailed him a far while ago > I think he may eventaully get it. i don't. he is more interested in being 'right' than in the actual engineering. randy From jakob.heitz@ericsson.com Wed Apr 20 00:32:52 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CBB1CE0730 for ; Wed, 20 Apr 2011 00:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.68 X-Spam-Level: X-Spam-Status: No, score=-5.68 tagged_above=-999 required=5 tests=[AWL=0.919, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzE49qATGGt2 for ; Wed, 20 Apr 2011 00:32:52 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id F2417E05F5 for ; Wed, 20 Apr 2011 00:32:51 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3K7WnfU004931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Apr 2011 02:32:50 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 20 Apr 2011 03:32:49 -0400 From: Jakob Heitz To: "curtis@occnc.com" , "raszuk@cisco.com" Date: Wed, 20 Apr 2011 03:32:44 -0400 Thread-Topic: [Idr] A slightly different perspective .... Thread-Index: Acv+0RF2hOXpXSECSKu3qHlFpVBLlwAW3RkQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F931395@EUSAACMS0701.eamcs.ericsson.se> References: Your message of "Sun, 17 Apr 2011 16:26:50 +0200." <4DAAF8AA.6060303@cisco.com> <201104192033.p3JKXL8T051434@harbor.orleans.occnc.com> In-Reply-To: <201104192033.p3JKXL8T051434@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 07:32:52 -0000 Even this is uncomfortably close to the minimum 3 second hold time. suggestions: 1. If using extended message length, minimum hold time is 30 seconds. 2. reset hold timer when BGP receives any data, even if it's only part of a= message. any objections to (2) ? -- Jakob Heitz. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Curtis Villamizar > Sent: Tuesday, April 19, 2011 1:33 PM > To: raszuk@cisco.com > Cc: idr@ietf.org List > Subject: Re: [Idr] A slightly different perspective .... >=20 >=20 > In message <4DAAF8AA.6060303@cisco.com> > Robert Raszuk writes: > > =20 > > Hi, > > =20 > > Jakob and Jeff's emails triggered me to think if the=20 > overall approach=20 > > here to extending all BGP messages size is the right one. > > =20 > > Let's realize that: > > =20 > > - To send 4096 octets msg on 10 Mbit/s wire takes 3.28 sec > > - To send 65535 octets msg on 10 Mbit/s wire takes 52.43 sec ! > > =20 > > No congestion, no delays ... pure best case numbers. >=20 >=20 > Robert, >=20 > 65535 * 8 =3D 524,280 bits at 56kb/sec its under 10 sec, but grandma is > now using DSL so her BGP is going a bit faster than that. >=20 > You need to use faster-light. >=20 > The real problem is the TCP default 3 sec after losing some packets. > Then assuming a recent TCP that starts with 4 segments, it may take a > quite a few RTT to get a packet across. >=20 > With no loss, start with 4 segments and double each RTT. For a 100 > msec RTT it is well under a second. So worst case is probably on the > order of 5 seconds if loss is moderate, maybe 10 seconds or more if > loss is really high. >=20 > Curtis >=20 >=20 > > Now add to this time for acks, some router CPU delay, some I/O=20 > > processing or worse some congestion or slow peer case and=20 > we are off the=20 > > cliff. > > =20 > > I like the summary Jeff sent indicating a real consequences=20 > for implicit=20 > > bound on current BGP attributes. Do we want to redefine BGP=20 > spec and=20 > > subsequent specs so fundamentally now to try only one proposal of=20 > > available number of others in the BGP security area ? > > =20 > > The answer I think is pretty obvious. > > =20 > > So let me propose that all elements related to securing BGP=20 > would be=20 > > contain in a new message all together. (Perhaps new SAFI=20 > perhaps not ..=20 > > I am not sure yet). > > =20 > > That would allow zero impact to Internet IPv4 and IPv6=20 > routing as we=20 > > know it today, gradual deployment etc ... > > =20 > > Here one also needs to keep in mind that all additional AS=20 > signatures as=20 > > proposed today would be duplicated or N-plicated for each AFI/SAFI=20 > > individually. > > =20 > > You would use the same space amount of information to sign=20 > IPv4 updates=20 > > as IPv6 updates. Leave alone the encapsulation part .. but=20 > storing and=20 > > processing the same thing many times seems to me like really waist. > > =20 > > The open issues are how to couple the secure BGP message=20 > with normal BGP=20 > > message if such coupling at all is needed. Even if we would=20 > duplicate=20 > > MP_REACH_NLRI into such Secure messages it still seems worth. > > =20 > > Another advantage is processing ... If we combine the secure BGP=20 > > overhead with current BGP UPDATE message you like it or not=20 > it will have=20 > > to be handled by today's old fashion general BGP CPU=20 > processing. But if=20 > > this is defined as a separate message .. maybe even on=20 > separate session=20 > > (by enforcing multisession on it) it could be all together easily=20 > > processed by some other CPU/CPU core/programmable FPGA or=20 > ASIC without=20 > > causing any burden and delay to current BGP processing.=20 > That would very=20 > > nicely allow to decouple the functions and only pass final=20 > decision to=20 > > main core BGP as prefix X - valid .. prefix Y - invalid. > > =20 > > Many thx, > > R. > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From stephane.litkowski@orange-ftgroup.com Wed Apr 20 07:41:56 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2256DE0711; Wed, 20 Apr 2011 07:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.056 X-Spam-Level: X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[AWL=1.505, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je+7KVJqLhoL; Wed, 20 Apr 2011 07:41:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfc.amsl.com (Postfix) with ESMTP id 2FE51E0705; Wed, 20 Apr 2011 07:41:55 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id F0C58C03E5; Wed, 20 Apr 2011 16:41:53 +0200 (CEST) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id D69F218003E; Wed, 20 Apr 2011 16:41:53 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Apr 2011 16:41:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 16:41:51 +0200 Message-ID: <5813_1303310513_4DAEF0B1_5813_884147_1_4FC3556A36EE3646A09DAA60429F53350640FA2C@PUEXCBL0.nanterre.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Comments on draft-ietf-l3vpn-ibgp-02.txt Thread-Index: Acv+tU5slNA8wZESQ5mk1WBbJ1u77gArY8EAAAGJTjA= From: To: X-OriginalArrivalTime: 20 Apr 2011 14:41:54.0021 (UTC) FILETIME=[17725950:01CBFF69] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.20.140023 Cc: idr@ietf.org, l3vpn@ietf.org Subject: [Idr] TR: Comments on draft-ietf-l3vpn-ibgp-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 14:41:56 -0000 =20 Hi Pedro, Thanks for the feedback. Some addings ... >That is a good point. In order to be consistent with the eBGP behavior it is best to prepend both the AS_PATH of the VPN route and its own autonomous-system number, in case the AS_PATH is not empty. [SLI] ok >This mechanism has been deployed in production for over 5 years. I'm not aware of "something bad" happening. The ATTR_SET attribute doesn't significantly change the packing of updates. [SLI] I was not aware that this attribute was already used, seems that JUNOS implements it already. >In the worst case scenario, each customer route has its own unique set=20 >of attributes. That worst case scenario can occur today via the use of=20 >communities. The common case is for different sets of CE route attributes to be providing useful information and be advertised through the VPN network, either with the current ebgp PE-CE interaction or with the method that is proposed in this document. > The added size to updates is statistically insignificant considering link bandwidth. [SLI] Yes it could be compared to community combinations coming from CEs. If we do a quick comparison between eBGP and iBGP PE-CE in terms of size of BGP VPN update , we have the following (not detailled) : iBGP adds to the VPN route : - ATTR_SET attribute overhead (6-7 bytes) - iBGP specific attributes within the ATTR_SET : OID : 7 bytes (if any) ClusterList : from 7 bytes up to ... (if any) ASPATH : in fact the overhead is just the "header" because in case of eBGP AS numbers are transported in ASPATH attribute of VPN update : 3 bytes (we don't count the AS numbers size) Local preference : 7 bytes Origin : 4 bytes MED,Communities will be present also for eBGP in the VPN update path attributes (so there is no bug overhead in storing them in ATTR_SET).=20 So iBGP PE-CE adds (in case of OID/CL present) about 34 bytes to the VPN BGP update, I took a look at some BGP updates we have, and path attributes size (MP_(UN)REACH_NLRI removed) is about 100 bytes, so it adds 30% more overhead. If we talk only of "link bandwidth" clearly it's insignificant as you mentionned (but in fact due to TCP windows and potential RTDs between RR and PE, we are never using all the link BW for a specific session). But my concerns are ,today, time to transfer the RIB-OUT from the RR to the PE within is quite slow when the number of VPN routes is huge (PE CPU and BGP/TCP socket interactions are the bottlenecks -> mainly vendor implementation dependent :) ) and we need to take care to not introduce more unneeded overhead in this area. In case of limited deployment, no big deal, but in case of generalization of iBGP, maybe (some tests are needed to be sure) this overhead can reduce the scaling compared to eBGP. >There is no reason to believe that the VPN export policies that compute >the VPN network attributes cannot impose communities depending on the=20 >attributes >of the CE routes. I also note that this document is not ment to replace but to complement the existing EBGP based PE-CE iteration. But contrary to the current mechanism, the default is to segregate attributes between the two networks. As the document explains there are several scenarios in which this proposal enables a simpler behavior. [SLI] You are right, we could proceed in this way Best Regards, Stephane ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From pmohapat@cisco.com Wed Apr 20 08:00:41 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3C38DE06B6 for ; Wed, 20 Apr 2011 08:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co+UOB2Z2Vq5 for ; Wed, 20 Apr 2011 08:00:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 36DC8E06AD for ; Wed, 20 Apr 2011 08:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=181; q=dns/txt; s=iport; t=1303311640; x=1304521240; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5AO+P7tufQbfVqHeBfAayjhpeEGpPA9a/xfYCoexSGk=; b=FkoJCZ0hcy9h5nOVKB4MHs5/Cb00mYSrJ3vqnr0RMQsGAULwhq4V+5co 7q9lV7z3Nndy2nx+TKU0VDC+Q/c+BfyaNgbv7wlc9GDSHCMgKL0cJrYts IuCqrsLaCZf+Kfhkpnd2eAWT+j7c+8rysE/5D6itgRrOJ+9bca3AhhEAi 8=; X-IronPort-AV: E=Sophos;i="4.64,247,1301875200"; d="scan'208";a="298500679" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 20 Apr 2011 15:00:39 +0000 Received: from sjc-vpn6-1648.cisco.com (sjc-vpn6-1648.cisco.com [10.21.126.112]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3KF0dLu026539; Wed, 20 Apr 2011 15:00:39 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F931395@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 20 Apr 2011 08:01:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43B64451-A018-4AC9-A61D-F42F08E3FB91@cisco.com> References: Your message of "Sun, 17 Apr 2011 16:26:50 +0200." <4DAAF8AA.6060303@cisco.com> <201104192033.p3JKXL8T051434@harbor.orleans.occnc.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F931395@EUSAACMS0701.eamcs.ericsson.se> To: Jakob Heitz X-Mailer: Apple Mail (2.1081) Cc: "raszuk@cisco.com" , "idr@ietf.org List" Subject: Re: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 15:00:41 -0000 > 2. reset hold timer when BGP receives any data, even if it's only part = of a message. >=20 > any objections to (2) ? No. Most of the BGP implementations already do this.= From rjs@rob.sh Wed Apr 20 21:58:53 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DA182E0693 for ; Wed, 20 Apr 2011 21:58:53 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1RC34iX7BMF for ; Wed, 20 Apr 2011 21:58:53 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfc.amsl.com (Postfix) with ESMTP id ECEEEE067B for ; Wed, 20 Apr 2011 21:58:52 -0700 (PDT) Received: from [93.97.180.64] (helo=[192.168.1.89]) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1QClyP-0007DW-I5; Thu, 21 Apr 2011 05:58:37 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F931395@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 21 Apr 2011 05:58:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55542139-B425-4B06-BE1C-7E173A111B1E@rob.sh> References: Your message of "Sun, 17 Apr 2011 16:26:50 +0200." <4DAAF8AA.6060303@cisco.com> <201104192033.p3JKXL8T051434@harbor.orleans.occnc.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F931395@EUSAACMS0701.eamcs.ericsson.se> To: Jakob Heitz X-Mailer: Apple Mail (2.1082) Cc: "raszuk@cisco.com" , "idr@ietf.org List" Subject: Re: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 04:58:54 -0000 On 20 Apr 2011, at 08:32, Jakob Heitz wrote: > Even this is uncomfortably close to the minimum 3 second hold time. > suggestions: > 1. If using extended message length, minimum hold time is 30 seconds. > 2. reset hold timer when BGP receives any data, even if it's only part = of a message. >=20 > any objections to (2) ? Hi Jakob. I would very strongly advise against taking the course of action = described in point 1. There are numerous scenarios in which (although we would prefer not to) = we need to detect the failure of a BGP speaker in as short amount of = time as possible for reasons that the service over the top _needs_ to = converge in this time [0]. Where these might be in a private (e.g. VPN) = context, I do not think that we can discount the fact that one day they = might need to run extended message length (whilst we have a set of = applications for which we are extending the message length today, this = set is not bounded, and additional applications will surely come to = light). In the SIDR case, there are still BGP speakers, receiving Internet = routes (which would be signed) that require detection of a peer failure = within a short period of time. In numerous cases, 30s will break other = applications, and whilst the statement "there is no SLA on the Internet" = might be convenient, I don't think it is universally true. So, even for = the known application of extended messages, I think 30s is unacceptably = long for a hold-time _in some scenarios_. In addition, where we deploy single session with multiple = pairs down it, we might need to support extended message length for = IPv4, but also run VPNv4 down the same session. In this case, we have to = endure 30s hold-time for both even though we might have a requirement = for failure detection (at the BGP daemon level) quicker than this for = one of the AFIs (where sensitive services may be running in the VPNv4 = one for instance)). Running a single session is of benefit to scaling = and manageability. Whilst I see the intention here, and the suggestion appears to be = motivated out of ensuring robustness - is this really such a risk? Going = by Curtis' figures (100msec RTT, 4 segments, no loss being <1sec) whilst = this may be 'close' to the 3 second minimum, I would suggest that few = sessions configured with such low timers run over links with 50msec = one-way latency. I think changing this minimum is a removing functionality that some = deployments which cannot be discounted from requiring extended messages = rely on. Just my =A30.02, r. [0]: There are really two scenarios here, one is suboptimal due to = constraints of existing devices/deployments, but the other is more = general. 1. If we cannot run OAM/BFD etc end-to-end for a session then I have = seen numerous operators 'tune' BGP timers to provide some liveliness = detection mechanism on the session. Platform support for OAM is not = universal, and numerous hardware architectures do not support BFD in a = reliable manner - hence, I can't see this going away in the long term. = Whilst it's not "design intent" of the protocol, it is a current use, = and one that it is difficult to see any alternative to without = re-procuring hardware in some cases. 2. In the more general case, if my BGP daemon has failed or is failing, = and my application cannot tolerate being broken for N seconds - I want = to determine that this daemon is broken and hence routing might be stale = in < X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E33CE0748 for ; Thu, 21 Apr 2011 05:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.782 X-Spam-Level: X-Spam-Status: No, score=-5.782 tagged_above=-999 required=5 tests=[AWL=0.817, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwOQcPB3hDl1 for ; Thu, 21 Apr 2011 05:48:12 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id BCE23E06FD for ; Thu, 21 Apr 2011 05:48:12 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3LCmBYn020248 for ; Thu, 21 Apr 2011 07:48:12 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 21 Apr 2011 08:48:05 -0400 From: Jakob Heitz To: "idr@ietf.org List" Date: Thu, 21 Apr 2011 08:48:01 -0400 Thread-Topic: [Idr] A slightly different perspective .... Thread-Index: Acv/a70Dy9lWuxCWTVaF+5qsEHTWfgApqU5Q Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F931922@EUSAACMS0701.eamcs.ericsson.se> References: Your message of "Sun, 17 Apr 2011 16:26:50 +0200." <4DAAF8AA.6060303@cisco.com> <201104192033.p3JKXL8T051434@harbor.orleans.occnc.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F931395@EUSAACMS0701.eamcs.ericsson.se> <43B64451-A018-4AC9-A61D-F42F08E3FB91@cisco.com> In-Reply-To: <43B64451-A018-4AC9-A61D-F42F08E3FB91@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 12:48:13 -0000 > From: Pradosh Mohapatra [mailto:pmohapat@cisco.com]=20 > Sent: Wednesday, April 20, 2011 8:01 AM >=20 > > 2. reset hold timer when BGP receives any data, even if=20 > it's only part of a message. > >=20 > > any objections to (2) ? >=20 > No. Most of the BGP implementations already do this. Thanks Pradosh. Makes sense. So let's make it a rule. However... Now that we can not check a message length for sanity, if the parser accidentally hits a 0xFFFF for a length, it could take over 2 days to detect the error. If the sending speaker sends very little other than a keepalive every minute, it will take 65535/19 minutes to fill the supposed message before it gets parsed. Another possibility to restore the lost sanity checking of the length: Change the marker field to a different pattern. It just needs not to look the same if it's shifted. Use it like this: If the message length is 4096 or less, either the old or the new marker pattern is allowed before that length field. If the message length is greater than 4096, only the new marker pattern is allowed before that length field. -- Jakob Heitz.= From pmohapat@cisco.com Thu Apr 21 13:51:39 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3E1FDE076A for ; Thu, 21 Apr 2011 13:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLfLXOuBOCq5 for ; Thu, 21 Apr 2011 13:51:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 52749E06B9 for ; Thu, 21 Apr 2011 13:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=1054; q=dns/txt; s=iport; t=1303419098; x=1304628698; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Ns44viUYLvOtzwLSt6DpaBZWDpBipA6Jo2CVdZWymn0=; b=Agt+op0h9L9Kg2DI1paMqIGBEfU+OMS7nB3uEYpNSqlvWuAkWuzQkhwv 4VVbgFMW+Hm6MjF5CtUxvYXgojiUuvyanmuk2qIQaDJa0MmnSY29VKHbr zfqCzI6HRS8kGAmBLcounhpNqwVpCZlW0pJPhGyH9Ilc0PST5CF1bIvtu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANuXsE2rRDoH/2dsb2JhbAClVneIcJ8MnFKFdgSFdIg3 X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="685462945" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 21 Apr 2011 20:51:37 +0000 Received: from dhcp-171-71-139-171.cisco.com (dhcp-171-71-139-171.cisco.com [171.71.139.171]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3LKpbnc021115; Thu, 21 Apr 2011 20:51:37 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F931922@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 21 Apr 2011 13:52:29 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: Your message of "Sun, 17 Apr 2011 16:26:50 +0200." <4DAAF8AA.6060303@cisco.com> <201104192033.p3JKXL8T051434@harbor.orleans.occnc.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F931395@EUSAACMS0701.eamcs.ericsson.se> <43B64451-A018-4AC9-A61D-F42F08E3FB91@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F931922@EUSAACMS0701.eamcs.ericsson.se> To: Jakob Heitz X-Mailer: Apple Mail (2.1081) Cc: "idr@ietf.org List" Subject: Re: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 20:51:39 -0000 Hi Jakob, > However... > > Now that we can not check a message length for sanity, > if the parser accidentally hits a 0xFFFF for a length, and the type field is <= 5... > it could take over 2 days to detect the error. > If the sending speaker sends very little other than a keepalive > every minute, it will take 65535/19 minutes to fill > the supposed message before it gets parsed. > > Another possibility to restore the lost sanity checking of > the length: > > Change the marker field to a different pattern. > It just needs not to look the same if it's shifted. > Use it like this: > If the message length is 4096 or less, either the old > or the new marker pattern is allowed before that length > field. > If the message length is greater than 4096, only the > new marker pattern is allowed before that length field. What would you suggest as the new pattern? Wouldn't that also have the same issue? The unfortunate side-effect is that there is another variability now to the debugging process ;-( - Pradosh From warren@kumari.net Sun Apr 24 09:59:19 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C5B0AE06D3 for ; Sun, 24 Apr 2011 09:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j57qhh64yTC for ; Sun, 24 Apr 2011 09:59:19 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfc.amsl.com (Postfix) with ESMTP id 56EBAE05F5 for ; Sun, 24 Apr 2011 09:59:19 -0700 (PDT) Received: from [172.19.118.237] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id C6B731B40914; Sun, 24 Apr 2011 12:59:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Sun, 24 Apr 2011 12:59:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <469A364A-0786-40FB-9B55-A05A6AED0D29@kumari.net> References: To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 16:59:19 -0000 After integrating some (off-list) comments (and discussions with the = chairs) it was determined that we have enough changes that rev'ing the = doc and restarting LC is the right thing to do... By far the largest change in the doc is the addition of Appendix A = (helpfully provided by Sriram). There were also numerous wording changes, some nits, etc. For your clicking pleasure, the latest version is at: = https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-sets/ And the diff: = http://tools.ietf.org//rfcdiff?url1=3Dhttp://www.ietf.org/id/draft-ietf-id= r-deprecate-as-sets-02.txt&url2=3Dhttp://www.ietf.org/id/draft-ietf-idr-de= precate-as-sets-03.txt Please review this new version (-03) and: a: let us know if the draft is still acceptable and=20 b: if the addition of Appendix A helps or hurts the doc. I appreciate everyone's time and review on this -- I'm sure y'all are = almost as tired of this doc as I am :-P W On Mar 30, 2011, at 3:04 PM, John Scudder wrote: > Folks, >=20 > This is to start a working group last call for = draft-ietf-idr-deprecate-as-sets-02. Please send comments by April 13, = 2011. >=20 > http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-02 >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From Internet-Drafts@ietf.org Sun Apr 24 10:00:02 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D9EEE06E0; Sun, 24 Apr 2011 10:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SMArJ6ZAmVr; Sun, 24 Apr 2011 10:00:01 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E2AE3E06E1; Sun, 24 Apr 2011 10:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110424170001.26672.2832.idtracker@ietfc.amsl.com> Date: Sun, 24 Apr 2011 10:00:01 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-deprecate-as-sets-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 17:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Deprecation of the use of BGP AS_SET, AS_CONFED_SET. Author(s) : W. Kumari, K. Sriram Filename : draft-ietf-idr-deprecate-as-sets-03.txt Pages : 8 Date : 2011-04-24 This document deprecates the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of the BGP protocol and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-deprecate-as-sets-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-24095523.I-D@ietf.org> --NextPart-- From curtis@occnc.com Sun Apr 24 14:59:12 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1792BE068B for ; Sun, 24 Apr 2011 14:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4bhlEiC67nE for ; Sun, 24 Apr 2011 14:59:11 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 7546AE0613 for ; Sun, 24 Apr 2011 14:59:11 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3OLx5FC039954; Sun, 24 Apr 2011 17:59:05 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104242159.p3OLx5FC039954@harbor.orleans.occnc.com> To: Pradosh Mohapatra From: Curtis Villamizar In-reply-to: Your message of "Thu, 21 Apr 2011 13:52:29 PDT." Date: Sun, 24 Apr 2011 17:59:05 -0400 Sender: curtis@occnc.com Cc: "idr@ietf.org List" Subject: Re: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 21:59:12 -0000 In message Pradosh Mohapatra writes: > > Hi Jakob, > > > However... > > > > Now that we can not check a message length for sanity, > > if the parser accidentally hits a 0xFFFF for a length, > > and the type field is <= 5... > > > it could take over 2 days to detect the error. > > If the sending speaker sends very little other than a keepalive > > every minute, it will take 65535/19 minutes to fill > > the supposed message before it gets parsed. > > > > Another possibility to restore the lost sanity checking of > > the length: > > > > Change the marker field to a different pattern. > > It just needs not to look the same if it's shifted. > > Use it like this: > > If the message length is 4096 or less, either the old > > or the new marker pattern is allowed before that length > > field. > > If the message length is greater than 4096, only the > > new marker pattern is allowed before that length field. > > What would you suggest as the new pattern? Wouldn't > that also have the same issue? The unfortunate side-effect > is that there is another variability now to the debugging > process ;-( > > - Pradosh Changing the marker is a waste of effort. 4K/19 time 1 minute is already a big number yet there are no problems. When no completed packet arrives the keepalive timer fires. The 19 bytes every minutes (or less) doesn't count against the timer, only complete packets. Curtis From curtis@occnc.com Sun Apr 24 15:22:02 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A5BFBE068B for ; Sun, 24 Apr 2011 15:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJQ-Jk6fEEz7 for ; Sun, 24 Apr 2011 15:22:02 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id F00E9E0613 for ; Sun, 24 Apr 2011 15:22:01 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3OMM1kw040289; Sun, 24 Apr 2011 18:22:01 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104242222.p3OMM1kw040289@harbor.orleans.occnc.com> To: Warren Kumari From: Curtis Villamizar In-reply-to: Your message of "Sun, 24 Apr 2011 12:59:16 EDT." <469A364A-0786-40FB-9B55-A05A6AED0D29@kumari.net> Date: Sun, 24 Apr 2011 18:22:01 -0400 Sender: curtis@occnc.com Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 22:22:02 -0000 In message <469A364A-0786-40FB-9B55-A05A6AED0D29@kumari.net> Warren Kumari writes: > > After integrating some (off-list) comments (and discussions with the > chairs) it was determined that we have enough changes that rev'ing the > doc and restarting LC is the right thing to do... > > By far the largest change in the doc is the addition of Appendix A > (helpfully provided by Sriram). > > There were also numerous wording changes, some nits, etc. For your > clicking pleasure, the latest version is at: > https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-sets/ > > And the diff: > http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-idr-deprecate-as-sets-02.txt&url2=http://www.ietf.org/id/draft-ietf-idr-deprecate-as-sets-03.txt > > > Please review this new version (-03) and: > a: let us know if the draft is still acceptable and > b: if the addition of Appendix A helps or hurts the doc. > > > I appreciate everyone's time and review on this -- I'm sure y'all are > almost as tired of this doc as I am :-P > > W Warren, Please remove this sentence (which you just added to "Security Considerations") "Future work will update the protocol to remove support for the AS_SET path segment type of the AS_PATH attribute." This would consitute a change to WG charter that is not approved and therefore the draft cannot go forward with this sentence. The following sentence in the appendix is also inaccurate "An AS should proxy aggregate only prefixes which belong to its administrative domain." Consenting adults may aggregate prefixes for which they both have components of the aggregate, though you should word it differently in the next iteration. The key is to have agreement from the other party, exchange more specifics, and both aggregate only the more specifics to any peer but each other. This works for two or more administrative domains though the consenting adults analogy get a little wierd so we shouldn't go there. Proxy aggregation is by definition aggregating someone else's prefix, so the sentence "An AS should proxy aggregate only prefixes which belong to its administrative domain." contains a contradiction. The point is aggregate only more specifics. Proxy aggregation should be with consent of other parties and adequate consideration of consequences. It may be necessary to proxy aggregate without consent if some provider routinely leaks out tons of more specifics and has proven to be clueless and/or unresponsive. I'm also not fond of the title. The word "depricate" should be absent in the title or anywhere else. Curtis > On Mar 30, 2011, at 3:04 PM, John Scudder wrote: > > > Folks, > > > > This is to start a working group last call for draft-ietf-idr-deprecate-as-sets-02. Please send comments by April 13, 2011. > > > > http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-02 > > > > Thanks, > > > > --John > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From jsw@inconcepts.biz Sun Apr 24 15:50:34 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8105E0686 for ; Sun, 24 Apr 2011 15:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvPtn8Pre0sb for ; Sun, 24 Apr 2011 15:50:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 2E45CE0679 for ; Sun, 24 Apr 2011 15:50:34 -0700 (PDT) Received: by vws12 with SMTP id 12so1791122vws.31 for ; Sun, 24 Apr 2011 15:50:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.116.131 with SMTP id m3mr994954vcq.157.1303685433585; Sun, 24 Apr 2011 15:50:33 -0700 (PDT) Received: by 10.220.181.1 with HTTP; Sun, 24 Apr 2011 15:50:33 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <201104242159.p3OLx5FC039954@harbor.orleans.occnc.com> References: <201104242159.p3OLx5FC039954@harbor.orleans.occnc.com> Date: Sun, 24 Apr 2011 18:50:33 -0400 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 22:50:35 -0000 On Sun, Apr 24, 2011 at 5:59 PM, Curtis Villamizar wrote= : > Changing the marker is a waste of effort. I agree that limiting the message length to 0xFEFF is a much better solution, but I don't think I am against the idea of changing the marker. This has plenty of precedent in RFC1771 as well -- the marker was envisioned to contain authentication data. Later revisions took that (unnecessary, and AFAIK never implemented) capability away. If the marker octets were all 0x00 instead of 0xFF, what would be the impact, aside from requiring some changes to header validation code which may be driven by the extended message capability flag? Is it any more likely that future BGP message payload would contain 16 0x00 octets in a row, than 16 0xFF octets? I think it's easy to say "yes" to that, but the likelihood of either of these circumstances arising along with the necessary serializer/parser bugs needed to trigger bugs is quite low. On the other hand, the likelihood of off-by-one/off-by-two bugs causing a BGP session to (apparently) "stall" for a long period of time is IMO higher, and changing the marker octets from 0xFF to 0x00 would reduce the negative impact of that. Still, this is a fix requiring more code which would be totally unnecessary if the draft simply extended the maximum message length from 4096 octets to 65,279 octets instead of 65,535 octets. > 4K/19 time 1 minute is already a big number yet there are no problems. Again, there is virtually zero chance, given the current specifications, that you will ever think an incoming message will be 4K, or any other size than what the remote neighbor actually says it will be. Off-by-one/two errors which could affect the perceived length of the following message are currently guaranteed to be detectable. If the current draft is adopted, an off-by-one or off-by-two bug, combined with a previous message that has one or two trailing 0xFF octets, will definitely trick the parser into thinking a >=3D 65280 octet message should be expected. It does not require the remote neighbor to make a huge error in length calculation -- the common "off by one" can and will do it, and this bug will no longer manifest itself as an invalid message header, but will instead appear to the operator to be a "stalled BGP session" which cannot be diagnosed. In the case of this time-out issue, these problems become directly related to each-other, if the current header check mechanism is removed from BGP. It is not simple. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jakob.heitz@ericsson.com Mon Apr 25 06:21:02 2011 Return-Path: X-Original-To: idr@ietfc.amsl.com Delivered-To: idr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4FA53E0742 for ; Mon, 25 Apr 2011 06:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjcAKOvBB9yq for ; Mon, 25 Apr 2011 06:20:59 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 584C5E0743 for ; Mon, 25 Apr 2011 06:20:59 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3PDKvur014571; Mon, 25 Apr 2011 08:20:58 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 25 Apr 2011 09:20:51 -0400 From: Jakob Heitz To: Jeff Wheeler , "idr@ietf.org" Date: Mon, 25 Apr 2011 09:20:47 -0400 Thread-Topic: [Idr] A slightly different perspective .... Thread-Index: AcwC0gufwxloH7gWQlyGAjEABvJdrAAeHyJg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E40122025@EUSAACMS0701.eamcs.ericsson.se> References: <201104242159.p3OLx5FC039954@harbor.orleans.occnc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] A slightly different perspective .... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 13:21:02 -0000 What I had in mind was a marker that would look different if it was shifted. today, it is 16 of 0xFF. If the last byte of the previous message is also 0xFF, then there are 17 of 0xFF and an off-by-one error becomes possible. Same thing with 17 of 0x00. However, change just one byte and such a shifting can be detected. Having said that, I do acknowledge that the undetected error is rare, but the solution is also simple. I'm not going to push this anymore. It was a small thing to begin with anyway and in my view the solution was also small. I am astounded at the volume of controversy it caused. -- Jakob Heitz. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Jeff Wheeler > Sent: Sunday, April 24, 2011 3:51 PM > To: idr@ietf.org > Subject: Re: [Idr] A slightly different perspective .... >=20 > On Sun, Apr 24, 2011 at 5:59 PM, Curtis Villamizar=20 > wrote: > > Changing the marker is a waste of effort. >=20 > I agree that limiting the message length to 0xFEFF is a much better > solution, but I don't think I am against the idea of changing the > marker. This has plenty of precedent in RFC1771 as well -- the marker > was envisioned to contain authentication data. Later revisions took > that (unnecessary, and AFAIK never implemented) capability away. >=20 > If the marker octets were all 0x00 instead of 0xFF, what would be the > impact, aside from requiring some changes to header validation code > which may be driven by the extended message capability flag? Is it > any more likely that future BGP message payload would contain 16 0x00 > octets in a row, than 16 0xFF octets? I think it's easy to say "yes" > to that, but the likelihood of either of these circumstances arising > along with the necessary serializer/parser bugs needed to trigger bugs > is quite low. On the other hand, the likelihood of > off-by-one/off-by-two bugs causing a BGP session to (apparently) > "stall" for a long period of time is IMO higher, and changing the > marker octets from 0xFF to 0x00 would reduce the negative impact of > that. >=20 > Still, this is a fix requiring more code which would be totally > unnecessary if the draft simply extended the maximum message length > from 4096 octets to 65,279 octets instead of 65,535 octets. >=20 > > 4K/19 time 1 minute is already a big number yet there are=20 > no problems. >=20 > Again, there is virtually zero chance, given the current > specifications, that you will ever think an incoming message will be > 4K, or any other size than what the remote neighbor actually says it > will be. Off-by-one/two errors which could affect the perceived > length of the following message are currently guaranteed to be > detectable. >=20 > If the current draft is adopted, an off-by-one or off-by-two bug, > combined with a previous message that has one or two trailing 0xFF > octets, will definitely trick the parser into thinking a >=3D 65280 > octet message should be expected. It does not require the remote > neighbor to make a huge error in length calculation -- the common "off > by one" can and will do it, and this bug will no longer manifest > itself as an invalid message header, but will instead appear to the > operator to be a "stalled BGP session" which cannot be diagnosed. >=20 > In the case of this time-out issue, these problems become directly > related to each-other, if the current header check mechanism is > removed from BGP. It is not simple. >=20 > --=20 > Jeff S Wheeler > Sr Network Operator=A0 /=A0 Innovative Network Concepts > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From kotikalapudi.sriram@nist.gov Tue Apr 26 04:51:57 2011 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 95FCDE073B for ; Tue, 26 Apr 2011 04:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QUjed0apNmi for ; Tue, 26 Apr 2011 04:51:52 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfa.amsl.com (Postfix) with ESMTP id F263EE0737 for ; Tue, 26 Apr 2011 04:51:51 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p3QBpcha007445; Tue, 26 Apr 2011 07:51:38 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 26 Apr 2011 07:51:38 -0400 From: "Sriram, Kotikalapudi" To: Curtis Villamizar Date: Tue, 26 Apr 2011 07:51:17 -0400 Thread-Topic: WGLC for draft-ietf-idr-deprecate-as-sets Thread-Index: AQHMA/yoUerit4RfmUmLlKNeyZI9Ig== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "idr@ietf.org" Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 11:51:57 -0000 Thanks for catching the improper use of the term "administrative domain". When we said "administrative domain", we actually meant ASs within the same "address allocation hierarchy". It is in the sense of parent, child, grandchild, etc. in address allocation/suballocation chain. Of course, multiple ASs belonging to different entities are involved. For example, in the Figure in Appendix A, a large ISP with AS-G=20 suballocated address space to two smaller ISPs with AS-E and AS-F,=20 and also to four customer ASs A,B,C, and D (grand children). Therefore, AS-G is in a position to proxy aggregate the more specifics from ASs A through F, and also create a ROA for the aggregate prefix=20 with itself (AS-G) as the origin AS. Being able to create a ROA for the=20 aggregate is important when adoption of RPKI and origin validation=20 takes effect. Therefore, the suggestion is to aggregate only more specifics= =20 and only from ASs located in the same address allocation hierarchy. =20 In light of your comment, we will make the following change: Replace "An AS should proxy aggregate only prefixes which belong to its administrative domain."=20 with new sentence "An aggregating AS should proxy aggregate only more specific prefixes=20 from ASs which have address suballocations within the same=20 address allocation hierarchy (as that of the aggregating AS)." We will also edit related text elsewhere to be consistent with the above. Sriram >Date: Sun, 24 Apr 2011 18:22:01 -0400 >From: Curtis Villamizar curtis@occnc.com >-- snip =96 >The following sentence in the appendix is also inaccurate "An AS >should proxy aggregate only prefixes which belong to its >administrative domain. " Consenting adults may aggregate prefixes for >which they both have components of the aggregate, though you should >word it differently in the next iteration. The key is to have >agreement from the other party, exchange more specifics, and both >aggregate only the more specifics to any peer but each other. This >works for two or more administrative domains though the consenting >adults analogy get a little wierd so we shouldn't go there. > >Proxy aggregation is by definition aggregating someone else's prefix, >so the sentence "An AS should proxy aggregate only prefixes which >belong to its administrative domain." contains a contradiction. The >point is aggregate only more specifics. Proxy aggregation should be >with consent of other parties and adequate consideration of >consequences. It may be necessary to proxy aggregate without consent >if some provider routinely leaks out tons of more specifics and has >proven to be clueless and/or unresponsive. >-- Snip --> >Curtis> From bruno.decraene@orange-ftgroup.com Tue Apr 26 09:37:04 2011 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 818F6E07EC; Tue, 26 Apr 2011 09:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXGqFRqXEol8; Tue, 26 Apr 2011 09:37:03 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 98710E06A6; Tue, 26 Apr 2011 09:37:03 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0B9F0FC4002; Tue, 26 Apr 2011 18:37:10 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id F3AB4FC4001; Tue, 26 Apr 2011 18:37:09 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 18:37:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Apr 2011 18:37:00 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Thread-Index: Acv6AX72XFF5uHuUTU2mJkhlfrngIgJ+4uaA References: From: To: X-OriginalArrivalTime: 26 Apr 2011 16:37:01.0359 (UTC) FILETIME=[2B04FBF0:01CC0430] Cc: l3vpn@ietf.org, idr@ietf.org Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 16:37:04 -0000 Hi Pedro, all, 1) May be some additional text discussing the interaction with inter-AS option A could be useful. E.g.: - I guess both VPN SP should now configure the customer AS on their ASBR (instead of their own AS number). Or maybe this depend on whether both ASes support this extension. - how SP load balancing between multiple ASBRs is affected (given that SP LOCAL_PREF is not used anymore by ingress PE) 2) "In all cases where a route containing the ATTR_SET attribute is imported, attributes present on the VPN route other than the NEXT_HOP attribute are ignored, both from the point of view of route selection in the VRF Adj-RIB-in and route advertisement to a CE router. " The document mostly talks about PE. Could the document explicitly define how the ATTR_SET attribute is handled by VPN Route Reflector and ASBR option B? e.g. ATTR_SET is not to be considered by VPN RR and ASBR option B ? 3) In section 8 "Deployment considerations", IMHO it could be helpful for SP readers to indicate that in a given VPN, some sites can use iBGP while other sites can use eBGP.=20 Thanks, Best regards, Bruno > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > Sent: Wednesday, April 13, 2011 7:37 PM > To: l3vpn@ietf.org; idr@ietf.org > Subject: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 >=20 > L3VPNers & IDRers, >=20 > This e-mail is the start of a joint L3VPN & IDR WG Last Call for draft-ietf-l3vpn-ibgp-02. >=20 > Feedback should be provided to the mailing list(s) and/or the authors. >=20 > The Last Call ends midnight PDT 27th April 2011. >=20 > You can view the draft here: > http://tools.ietf.org/id/draft-ietf-l3vpn-ibgp-02.txt >=20 > Thanks > Ben (on behalf of the L3VPN & IDR chairs) > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From pedro.r.marques@gmail.com Tue Apr 26 10:25:21 2011 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 641F6E0811; Tue, 26 Apr 2011 10:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QH0PfI37Pb9; Tue, 26 Apr 2011 10:25:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2313CE07D9; Tue, 26 Apr 2011 10:25:20 -0700 (PDT) Received: by iyn15 with SMTP id 15so896480iyn.31 for ; Tue, 26 Apr 2011 10:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FYKxJN6xuxebWHqaEBGidRrBTqhErUNw1cjtQBmHXgY=; b=lN6ojCeHVo+QhjrOL2MbdSDik7bus50t8wnd46IXqiGnyFuPzZayCWf2W4Z/j6SCvL avsJxARdmbOK172TzdLx4HdQPKmXKItSuMK9qBrpUCcglxI/nYnM6rr98/AI9N80PSZb fTdxm1cYs911yeKJzqlYGbygg2ZLAvVIoLJrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i7IaTVGCT251rckUd0Tf2rZii4eKVfGg9zPgXuTvTMCCsCx9o9LbYINWlez7noPeLl frWvQzrFKmUksDTmOFj2R4LCPePgri50Am29ZJr/v3G8amJApu7dOKJvudC1EL0FbkOy uuHThREATFGwk9ZTrRysAXxfqAzl37nk24/OA= MIME-Version: 1.0 Received: by 10.43.48.130 with SMTP id uw2mr1193668icb.312.1303838719395; Tue, 26 Apr 2011 10:25:19 -0700 (PDT) Received: by 10.42.170.6 with HTTP; Tue, 26 Apr 2011 10:25:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Apr 2011 10:25:19 -0700 Message-ID: From: Pedro Marques To: bruno.decraene@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: l3vpn@ietf.org, idr@ietf.org Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 17:25:21 -0000 Bruno, Answers inline. On Tue, Apr 26, 2011 at 9:37 AM, wrote= : > Hi Pedro, all, > > 1) May be some additional text discussing the interaction with inter-AS > option A could be useful. E.g.: > =A0 =A0 =A0 =A0- I guess both VPN SP should now configure the customer AS= on > their ASBR (instead of their own AS number). Or maybe this depend on > whether both ASes support this extension. I'm not sure Inter-AS option A is relevant to this document. By definition option The document doesn't propose any modification in operation of option A. It does define procedures of how routes from a VRF in the customer AS interops with a VRF in the SP AS, such as the ones used in option A. > =A0 =A0 =A0 =A0- how SP load balancing between multiple ASBRs is affected > (given that SP LOCAL_PREF is not used anymore by ingress PE) The ATTR_SET attribute allows a solution to preserve the customer LOCAL_PREF; it doesn't and shouldn't (imho) prescribe policy mechanisms that may overwrite that LOCAL_PREF. The ATTR_SET attribute along with the ability of running VRFs on different ASes (e.g. the customer AS) are intended to address a particular set of scenarios which tend to be disjoint, as far as i know, from the scenarios where option A is used. The first is intended to allow customer managed inter-as route exchanges, while the later is a provider managed solution. They should inter-operate but not necessarily overlap for the same customer. Unless you do have a scenario in mind where it would be helpful to use ATTR_SET for SP managed inter-as with option A.... If so please describe the issue you are trying to address. I'd be more than happy to try to make the mechanism more useful but at the moment i'm not aware of an application. The only scenario i can think of is one where a provider is internally using multiple ASes and would like to make that irrelevant to the customer; but in that scenario option A has a significant number of issues which are beyond the scope of what we can address with this document, imho. By the time one addresses these you get option B, for which this document is relevant. > > 2) "In all cases where a route containing the ATTR_SET attribute is > =A0 imported, attributes present on the VPN route other than the NEXT_HOP > =A0 attribute are ignored, both from the point of view of route selection > =A0 in the VRF Adj-RIB-in and route advertisement to a CE router. " > > The document mostly talks about PE. Could the document explicitly define > how the ATTR_SET attribute is handled by VPN Route Reflector and ASBR > option B? e.g. ATTR_SET is not to be considered by VPN RR and ASBR > option B ? The ATTR_SET attribute is transparent to VPN Route Reflectors and ASBRs. > > 3) In section 8 "Deployment considerations", IMHO it could be helpful > for SP readers to indicate that in a given VPN, some sites can use iBGP > while other sites can use eBGP. They could as a transition mechanism, specially. Section 7 describes how this would work from a protocol standpoint. If you have concrete applications, i'd be happy to highlight them. In abstract i'm not sure that we would be adding value just by stating that one could have both iBGP (in customer-as VRFs) and eBGP (in provider-as VRFs) without the context of "why would that be a good idea ?"... > > Thanks, > Best regards, > Bruno > >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Ben Niven-Jenkins >> Sent: Wednesday, April 13, 2011 7:37 PM >> To: l3vpn@ietf.org; idr@ietf.org >> Subject: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 >> >> L3VPNers & IDRers, >> >> This e-mail is the start of a joint L3VPN & IDR WG Last Call for > draft-ietf-l3vpn-ibgp-02. >> >> Feedback should be provided to the mailing list(s) and/or the authors. >> >> The Last Call ends midnight PDT 27th April 2011. >> >> You can view the draft here: >> http://tools.ietf.org/id/draft-ietf-l3vpn-ibgp-02.txt >> >> Thanks >> Ben (on behalf of the L3VPN & IDR chairs) >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > From bruno.decraene@orange-ftgroup.com Wed Apr 27 02:21:54 2011 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 A10D2E068F; Wed, 27 Apr 2011 02:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJVQpw+zHUnn; Wed, 27 Apr 2011 02:21:50 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 26FF0E0717; Wed, 27 Apr 2011 02:21:49 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E0376C8002; Wed, 27 Apr 2011 11:22:24 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 00D326C0006; Wed, 27 Apr 2011 11:22:23 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 11:21:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Apr 2011 11:21:47 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Thread-Index: AcwENuxRvjUetwiVTjyTbIowFE5H6AAdOqIA References: From: To: X-OriginalArrivalTime: 27 Apr 2011 09:21:48.0597 (UTC) FILETIME=[89037650:01CC04BC] Cc: idr@ietf.org, l3vpn@ietf.org Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 09:21:54 -0000 Pedro, Thanks for your answer. Comments inline. > > 1) May be some additional text discussing the interaction with = inter-AS > > option A could be useful. E.g.: > > =A0 =A0 =A0 =A0- I guess both VPN SP should now configure the = customer AS on > > their ASBR (instead of their own AS number). Or maybe this depend on > > whether both ASes support this extension. >=20 > I'm not sure Inter-AS option A is relevant to this document. By > definition option The document doesn't propose any modification in > operation of option A. How do you handle the following topology: ? AS1 | AS10 | AS11 | AS1 CE1---PE1---ASBR1---ASBR2---PE2---CE2=09 CE1-PE1 and CE2-PE2 are iBGP sessions. ASBR1 use inter AS option A. Should they use an iBGP session compliant = with this document or a regular eBGP session? In the latter case, the = ATTR_SET attribute will be dropped by ASBR and hence will not be = propagated from PE1 to PE2. > It does define procedures of how routes from a VRF in the customer AS > interops with a VRF in the SP AS, such as the ones used in option A. >=20 > > =A0 =A0 =A0 =A0- how SP load balancing between multiple ASBRs is = affected > > (given that SP LOCAL_PREF is not used anymore by ingress PE) >=20 > The ATTR_SET attribute allows a solution to preserve the customer > LOCAL_PREF; Ok for the preservation. But in my understanding it goes beyond = preservation: =20 " In all cases where a route containing the ATTR_SET attribute is imported, attributes present on the VPN route other than the NEXT_HOP attribute are ignored, both from the point of view of route selection in the VRF Adj-RIB-in and route advertisement to a CE router. In order words, the information contained in ATTR_SET attribute overrides the VPN route attributes on "vrf-import". " I read that the PE does not use the VPN/SP LOCAL_PREF but the customer = one. Hence a SP could not influence the load balancing across its ASBR = option B. > it doesn't and shouldn't (imho) prescribe policy > mechanisms that may overwrite that LOCAL_PREF. >=20 > The ATTR_SET attribute along with the ability of running VRFs on > different ASes (e.g. the customer AS) are intended to address a > particular set of scenarios which tend to be disjoint, as far as i > know, from the scenarios where option A is used. >=20 > The first is intended to allow customer managed inter-as route > exchanges, while the later is a provider managed solution. They should > inter-operate but not necessarily overlap for the same customer. >=20 > Unless you do have a scenario in mind where it would be helpful to use > ATTR_SET for SP managed inter-as with option A.... If so please > describe the issue you are trying to address. I'd be more than happy > to try to make the mechanism more useful but at the moment i'm not > aware of an application. Let's take a SP A that cooperates with SP B to increase the geographic = coverage of its VPN service (in a cost effective way given that the low = demand in this location does not justify extending the VPN network of SP = A). SPs uses inter AS option A. Now a customer VPN having sites connected in both SP ask for iBGP = session between PE and CE. =20 > The only scenario i can think of is one where a provider is internally > using multiple ASes and would like to make that irrelevant to the > customer; but in that scenario option A has a significant number of > issues which are beyond the scope of what we can address with this > document, imho. By the time one addresses these you get option B, for > which this document is relevant. >=20 > > > > 2) "In all cases where a route containing the ATTR_SET attribute is > > =A0 imported, attributes present on the VPN route other than the = NEXT_HOP > > =A0 attribute are ignored, both from the point of view of route = selection > > =A0 in the VRF Adj-RIB-in and route advertisement to a CE router. " > > > > The document mostly talks about PE. Could the document explicitly = define > > how the ATTR_SET attribute is handled by VPN Route Reflector and = ASBR > > option B? e.g. ATTR_SET is not to be considered by VPN RR and ASBR > > option B ? >=20 > The ATTR_SET attribute is transparent to VPN Route Reflectors and = ASBRs. >=20 > > > > 3) In section 8 "Deployment considerations", IMHO it could be = helpful > > for SP readers to indicate that in a given VPN, some sites can use = iBGP > > while other sites can use eBGP. >=20 > They could as a transition mechanism, specially.=20 If you restrict this to a transition mechanism, should I understand that = you do not recommend that a VPN has both a set of sites in one AS using = iBGP and some other sites (in a different AS) using eBGP? > If you have concrete applications, i'd be happy to highlight them. In > abstract i'm not sure that we would be adding value just by stating > that one could have both iBGP (in customer-as VRFs) and eBGP (in > provider-as VRFs) without the context of "why would that be a good > idea ?"... As for the concrete application, I guess we could have a VPN customer = with multiple CE/site in one AS numbers but yet some other sites in a = different AS number. E.g. sites A1...Ai in AS A and sites B1...Bj in AS = B. Can a SP put all these VPN sites in the same VPN and the VPN network = will transparently handle this case? (i.e. interconnect Ai & Aj using = iBGP, interconnect Bi & Bj using iBGP, while interconnect Ai & Bi using = eBGP). Or should this be avoided? Or do we need anything special (config = / additional gateway) to handle this? Any answer (yes/ no / yes with X) is fine. The goal of the text is = simply to make it clear for SP whether such topology is in scope of the = document or not. (currently I believe it is not in scope) > Section 7 describes > how this would work from a protocol standpoint. "The desired result, in such a scenario is to present the internal peer (CE3) with a BGP advertisement that contains the same BGP Path Attributes received from CE1 and to the external peer (CE 2) a BGP advertisement that would correspond to a situation where AS 1 and 2 have an external BGP session between them." I agree that this is the desired result. The question is does this = document achieve this? " When importing a route without the ATTR_SET attribute to a VRF that support Interior BGP mode, a PE router MUST prepend its own as number to the AS_PATH." How such route is re-advertised in iBGP to the CE? Is a LOCAL_PREF = attribute sent? A priori yes as per RFC 4271 ("LOCAL_PREF is a = well-known attribute that SHALL be included in all UPDATE messages that = a given BGP speaker sends to other internal peers.") With which value?=20 Same question when the AS number in ATTR_SET does not match the local AS = configured in the VRF of the iBGP PE-CE session. Thanks, Regards, Bruno =20 > > > > Thanks, > > Best regards, > > Bruno > > > >> -----Original Message----- > >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf = Of > > Ben Niven-Jenkins > >> Sent: Wednesday, April 13, 2011 7:37 PM > >> To: l3vpn@ietf.org; idr@ietf.org > >> Subject: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 > >> > >> L3VPNers & IDRers, > >> > >> This e-mail is the start of a joint L3VPN & IDR WG Last Call for > > draft-ietf-l3vpn-ibgp-02. > >> > >> Feedback should be provided to the mailing list(s) and/or the = authors. > >> > >> The Last Call ends midnight PDT 27th April 2011. > >> > >> You can view the draft here: > >> http://tools.ietf.org/id/draft-ietf-l3vpn-ibgp-02.txt > >> > >> Thanks > >> Ben (on behalf of the L3VPN & IDR chairs) > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > From pedro.r.marques@gmail.com Wed Apr 27 09:19:17 2011 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 E7CE4E07DD; Wed, 27 Apr 2011 09:19:17 -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=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bnl7H39+YFQ; Wed, 27 Apr 2011 09:19:17 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8222CE0795; Wed, 27 Apr 2011 09:19:16 -0700 (PDT) Received: by iyn15 with SMTP id 15so1928624iyn.31 for ; Wed, 27 Apr 2011 09:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+U+gSp5agHOxhvtGr3yJBN2jv+H8tUF/LAoxYNSR3VU=; b=af32vAX6T/eptd39g4JgMsQlqh8VNw6gLBdA3P3MiFDGLq4Rn5gPrGYqKefMTCZ8MR KUQUiI4bo0KBdHY0LtB5iVuObj3OE97xUJSQ9E7IhYteAzIfjybn8fL629NDjiI94RK/ o8Sl6v9ILaC8FbWTKlmQl3w7OCT4tOV9cBq9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JueNH8RgXbqPpqr7Aq5NTfoUm5R+kxXpOVcXA0NLVX5lXtyFKVLcu/0KNYCKvTrkqq 0PPSDjmr7GIghD1a/nu2DSQj9EIAXq/rsVd7i23G/czNlkztuQuPfd1D3GrhItSZ/qnx Oo/Bol8ZRqKYtl2owfUI53tx1huamMNgi87YQ= MIME-Version: 1.0 Received: by 10.42.247.200 with SMTP id md8mr3160107icb.111.1303921156058; Wed, 27 Apr 2011 09:19:16 -0700 (PDT) Received: by 10.42.172.199 with HTTP; Wed, 27 Apr 2011 09:19:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Apr 2011 09:19:16 -0700 Message-ID: From: Pedro Marques To: bruno.decraene@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr@ietf.org, l3vpn@ietf.org Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 16:19:18 -0000 Please see inline. On Wed, Apr 27, 2011 at 2:21 AM, wrote= : > Pedro, > > How do you handle the following topology: ? > > AS1 | =A0 =A0AS10 =A0 =A0 | =A0 =A0AS11 =A0 =A0 | AS1 > CE1---PE1---ASBR1---ASBR2---PE2---CE2 > > CE1-PE1 and CE2-PE2 are iBGP sessions. > ASBR1 use inter AS option A. Should they use an iBGP session compliant wi= th this document or a regular eBGP session? They should use an eBGP session. > In the latter case, the ATTR_SET attribute will be dropped by ASBR and he= nce will not be propagated from PE1 to PE2. In both cases the ATTR_SET attribute will be "poped". The ATTR_SET attribute is only propagated as long as the route is an "inet-vpn" route... once imported into a VRF it disappears. > " In all cases where a route containing the ATTR_SET attribute is > =A0 imported, attributes present on the VPN route other than the NEXT_HOP > =A0 attribute are ignored, both from the point of view of route selection > =A0 in the VRF Adj-RIB-in and route advertisement to a CE router. =A0In > =A0 order words, the information contained in ATTR_SET attribute > =A0 overrides the VPN route attributes on "vrf-import". " > > I read that the PE does not use the VPN/SP LOCAL_PREF but the customer on= e. Hence a SP could not influence the load balancing across its ASBR option= B. An SP can influence load balancing across option B by using local pref in the inet-vpn space. ASBR1 <=3D=3D=3D=3D> ASBR3 PE1 -- [ AS 1 ] [ AS 2 ] -- PE2 -- VRF ASBR2 <=3D=3D=3D=3D> ASBR4 A RD1:IP-prefix "inet-vpn" route that originates in PE1 will appear in PE2 from both ASBR3 and 4 (assuming no reflection). Local-pref on the SP network can be used to influence the routing decision as to which of the paths to RD1:IP-prefix is preferable. If there is another route injected from a PE3 with prefix RD3:IP-prefix, it is the customer route local-pref that would influence the decision after the inet-vpn route is imported into the VRF and becomes an inet route. Also note that nothing prevents a vendors from adding extra policy mechanisms. What changes is that the customer local-pref used to always get squashed by protocol definition (not policy). > Let's take a SP A that cooperates with SP B to increase the geographic co= verage of its VPN service (in a cost effective way given that the low deman= d in this location does not justify extending the VPN network of SP A). SPs= uses inter AS option A. > > Now a customer VPN having sites connected in both SP ask for iBGP session= between PE and CE. > I don't think the question is put correctly. I believe the question should be: what it takes for cooperating providers to be able to provide a completely transparent service to the customer such that the VPN network appears as a core. My answer would be that you can achieve that with a combination of option B and this document. Note that with option B, ASBRs can as a matter of local policy look at the contents of the IP packets traversing the link if they so choose. > > If you restrict this to a transition mechanism, should I understand that = you do not recommend that a VPN has both a set of sites in one AS using iBG= P and some other sites (in a different AS) using eBGP? A "virtual private network" can consist of multiple ASes. I would recommend that one customer AS (AS 1) interconnects with iBGP with a given VPN provider in order to receive routes from both AS 1 and other ASes that could be ebgp interconnected. I would not recommend that an AS, AS 1, interconnects with a VPN provider both as iBGP and as eBGP (as AS1). There are some assumptions of connectivity in an AS. I would recommend that one would stick to these assumptions whenever possible. But extranets often use a VPN provider to exchange routes between multiple ASes with no known problems. > As for the concrete application, I guess we could have a VPN customer wit= h multiple CE/site in one AS numbers but yet some other sites in a differen= t AS number. E.g. sites A1...Ai in AS A and sites B1...Bj in AS B. Can a SP= put all these VPN sites in the same VPN and the VPN network will transpare= ntly handle this case? Yes. > (i.e. interconnect Ai & Aj using iBGP, interconnect Bi & Bj using iBGP, w= hile interconnect Ai & Bi using eBGP). Or should this be avoided? Or do we = need anything special (config / additional gateway) to handle this? > Any answer (yes/ no / yes with X) is fine. The goal of the text is simply= to make it clear for SP whether such topology is in scope of the document = or not. (currently I believe it is not in scope) Then the text should be modified to clarify this. > >> Section 7 describes >> how this would work from a protocol standpoint. > > "The desired result, in such a scenario is to present the internal > =A0 peer (CE3) with a BGP advertisement that contains the same BGP Path > =A0 Attributes received from CE1 and to the external peer (CE 2) a BGP > =A0 advertisement that would correspond to a situation where AS 1 and 2 > =A0 have an external BGP session between them." > > I agree that this is the desired result. The question is does this docume= nt achieve this? By the rules specified regarding how the vrf-import stage modifies BGP attributes. The AS of the importing VRF is compared to the Origin AS of the ATTR_SET attribute. CE1 and CE3 have the same "VRF AS" so the route is imported as-is (using the original attributes preserved in ATTR_SET). When a route from CE1 is imported into the VRF containing CE2 the VRF ASes do not match. This results in an implicit eBGP peering between AS 1 and AS 2. > > " =A0 =A0 =A0When importing a route without the ATTR_SET attribute to a V= RF > =A0 =A0 =A0that support Interior BGP mode, a PE router MUST prepend its o= wn > =A0 =A0 =A0as number to the AS_PATH." > > How such route is re-advertised in iBGP to the CE? The exact same behavior as if you had a CE that speaks to the PE using the current mechanisms (without this document) and that CE is then speaking iBGP to another CE (and using reflection to propagate routes). > Is a LOCAL_PREF attribute sent? A priori yes as per RFC 4271 ("LOCAL_PREF= is a well-known attribute that SHALL be included in all UPDATE messages th= at a given BGP speaker sends to other internal peers.") With which value? The default value. LOCAL_PREF is always initialized to the default value for an eBGP received route. > > Same question when the AS number in ATTR_SET does not match the local AS = configured in the VRF of the iBGP PE-CE session. > Same answer. There is an implicit eBGP peering between the Origin AS and the VRF AS of the importing VRF. Pedro. From curtis@occnc.com Wed Apr 27 18:41:52 2011 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 E945CE090A for ; Wed, 27 Apr 2011 18:41:52 -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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db8Tb0inQAnS for ; Wed, 27 Apr 2011 18:41:52 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3720CE0849 for ; Wed, 27 Apr 2011 18:41:52 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3S1fpuK076789; Wed, 27 Apr 2011 21:41:51 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201104280141.p3S1fpuK076789@harbor.orleans.occnc.com> To: "Sriram, Kotikalapudi" From: Curtis Villamizar In-reply-to: Your message of "Tue, 26 Apr 2011 07:51:17 EDT." Date: Wed, 27 Apr 2011 21:41:51 -0400 Sender: curtis@occnc.com Cc: "idr@ietf.org" Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 01:41:53 -0000 In message "Sriram, Kotikalapudi" writes: > > Thanks for catching the improper use of the term "administrative domain". > When we said "administrative domain", we actually meant > ASs within the same "address allocation hierarchy". > It is in the sense of parent, child, grandchild, etc. > in address allocation/suballocation chain. > Of course, multiple ASs belonging to different entities are involved. > For example, in the Figure in Appendix A, a large ISP with AS-G > suballocated address space to two smaller ISPs with AS-E and AS-F, > and also to four customer ASs A,B,C, and D (grand children). > Therefore, AS-G is in a position to proxy aggregate the more specifics > from ASs A through F, and also create a ROA for the aggregate prefix > with itself (AS-G) as the origin AS. Being able to create a ROA for the > aggregate is important when adoption of RPKI and origin validation > takes effect. Therefore, the suggestion is to aggregate only more specifics > and only from ASs located in the same address allocation hierarchy. > > In light of your comment, we will make the following change: > Replace > "An AS should proxy aggregate only prefixes which > belong to its administrative domain." > with new sentence > "An aggregating AS should proxy aggregate only more specific prefixes > from ASs which have address suballocations within the same > address allocation hierarchy (as that of the aggregating AS)." > > We will also edit related text elsewhere to be consistent with the above. > > Sriram Sriram, This limitation sounds specific to SIDR and if so you should either say so and describe the limitation or leave it out. Ultimately all addresses come from somewhere. Jon Postel maybe. So in a sense it is also meaningless. The further up the tree you have to go the harder it would be to coordinate, but all address allocations have a common root. Curtis > >Date: Sun, 24 Apr 2011 18:22:01 -0400 > >From: Curtis Villamizar curtis@occnc.com > >-- snip – > >The following sentence in the appendix is also inaccurate "An AS > >should proxy aggregate only prefixes which belong to its > >administrative domain. " Consenting adults may aggregate prefixes for > >which they both have components of the aggregate, though you should > >word it differently in the next iteration. The key is to have > >agreement from the other party, exchange more specifics, and both > >aggregate only the more specifics to any peer but each other. This > >works for two or more administrative domains though the consenting > >adults analogy get a little wierd so we shouldn't go there. > > > >Proxy aggregation is by definition aggregating someone else's prefix, > >so the sentence "An AS should proxy aggregate only prefixes which > >belong to its administrative domain." contains a contradiction. The > >point is aggregate only more specifics. Proxy aggregation should be > >with consent of other parties and adequate consideration of > >consequences. It may be necessary to proxy aggregate without consent > >if some provider routinely leaks out tons of more specifics and has > >proven to be clueless and/or unresponsive. > >-- Snip --> > >Curtis> From bruno.decraene@orange-ftgroup.com Thu Apr 28 05:41:39 2011 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 74434E06A7; Thu, 28 Apr 2011 05:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHGq7zJe9m-Q; Thu, 28 Apr 2011 05:41:38 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 40D5EE0674; Thu, 28 Apr 2011 05:41:37 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 51DE0858004; Thu, 28 Apr 2011 14:48:11 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 4943D858003; Thu, 28 Apr 2011 14:48:11 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 14:41:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Apr 2011 14:41:36 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Thread-Index: AcwE9ttGZhPFk0o6RO2lBoGkBg54WwAepAgQ References: From: To: X-OriginalArrivalTime: 28 Apr 2011 12:41:36.0631 (UTC) FILETIME=[9CDA0870:01CC05A1] Cc: idr@ietf.org, l3vpn@ietf.org Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 12:41:39 -0000 Please see inline. > > How do you handle the following topology: ? > > > > AS1 | =A0 =A0AS10 =A0 =A0 | =A0 =A0AS11 =A0 =A0 | AS1 > > CE1---PE1---ASBR1---ASBR2---PE2---CE2 > > > > CE1-PE1 and CE2-PE2 are iBGP sessions. > > ASBR1 use inter AS option A. Should they use an iBGP session = compliant with this document or a > regular eBGP session? >=20 > They should use an eBGP session. >=20 > > In the latter case, the ATTR_SET attribute will be dropped by ASBR = and hence will not be propagated > from PE1 to PE2. >=20 > In both cases the ATTR_SET attribute will be "poped". The ATTR_SET > attribute is only propagated as long as the route is an "inet-vpn" > route... once imported into a VRF it disappears. Yes. With iBGP, the ATTR_SET attribute will be "poped" but only after = copying the BGP attributes of the customer route (e.g. LOCAL_PREF) on = the regular iBGP attributes. Then the next ASBR would "push" them back = in a new ATTR_SET attribute. Hence BGP attributes of the customer are = propagated end to end. =20 > > " In all cases where a route containing the ATTR_SET attribute is > > =A0 imported, attributes present on the VPN route other than the = NEXT_HOP > > =A0 attribute are ignored, both from the point of view of route = selection > > =A0 in the VRF Adj-RIB-in and route advertisement to a CE router. = =A0In > > =A0 order words, the information contained in ATTR_SET attribute > > =A0 overrides the VPN route attributes on "vrf-import". " > > > > I read that the PE does not use the VPN/SP LOCAL_PREF but the = customer one. Hence a SP could not > influence the load balancing across its ASBR option B. >=20 > An SP can influence load balancing across option B by using local pref > in the inet-vpn space. >=20 > ASBR1 <=3D=3D=3D=3D> ASBR3 > PE1 -- [ AS 1 ] [ AS 2 ] > -- PE2 -- VRF > ASBR2 <=3D=3D=3D=3D> ASBR4 >=20 > A RD1:IP-prefix "inet-vpn" route that originates in PE1 will appear in > PE2 from both ASBR3 and 4 (assuming no reflection). Local-pref on the > SP network can be used to influence the routing decision as to which > of the paths to RD1:IP-prefix is preferable. >=20 > If there is another route injected from a PE3 with prefix > RD3:IP-prefix, it is the customer route local-pref that would > influence the decision after the inet-vpn route is imported into the > VRF and becomes an inet route. Ok. Thanks for the additional explanation. =20 > Also note that nothing prevents a vendors from adding extra policy > mechanisms. What changes is that the customer local-pref used to > always get squashed by protocol definition (not policy). >=20 > > Let's take a SP A that cooperates with SP B to increase the = geographic coverage of its VPN service > (in a cost effective way given that the low demand in this location = does not justify extending the VPN > network of SP A). SPs uses inter AS option A. > > > > Now a customer VPN having sites connected in both SP ask for iBGP = session between PE and CE. > > >=20 > I don't think the question is put correctly. I believe the question > should be: what it takes for cooperating providers to be able to > provide a completely transparent service to the customer such that the > VPN network appears as a core. >=20 > My answer would be that you can achieve that with a combination of > option B and this document. Note that with option B, ASBRs can as a > matter of local policy look at the contents of the IP packets > traversing the link if they so choose. Given that l3vpn-ibgp comes after inter AS, I would assume that inter AS = interconnection pre-exist when the first iBGP PE-CE customer comes. So = if the deployed VPN ASBR use option A, l3vpn-ibgp have to face it. = That's fine for me if l3vpn-ibgp does not work with inter AS option A, = but I still believe this should be indicated in the "deployment = considerations" section of the document. You can also add that to be = able to provide iBGP PE-CE, SP should favor inter AS option B (over A). =20 > > If you restrict this to a transition mechanism, should I understand = that you do not recommend that a > VPN has both a set of sites in one AS using iBGP and some other sites = (in a different AS) using eBGP? >=20 > A "virtual private network" can consist of multiple ASes. I would > recommend that one customer AS (AS 1) interconnects with iBGP with a > given VPN provider in order to receive routes from both AS 1 and other > ASes that could be ebgp interconnected. >=20 > I would not recommend that an AS, AS 1, interconnects with a VPN > provider both as iBGP and as eBGP (as AS1). >=20 > There are some assumptions of connectivity in an AS. I would recommend > that one would stick to these assumptions whenever possible. But > extranets often use a VPN provider to exchange routes between multiple > ASes with no known problems. >=20 >=20 > > As for the concrete application, I guess we could have a VPN = customer with multiple CE/site in one > AS numbers but yet some other sites in a different AS number. E.g. = sites A1...Ai in AS A and sites > B1...Bj in AS B. Can a SP put all these VPN sites in the same VPN and = the VPN network will > transparently handle this case? >=20 > Yes. >=20 > > (i.e. interconnect Ai & Aj using iBGP, interconnect Bi & Bj using = iBGP, while interconnect Ai & Bi > using eBGP). Or should this be avoided? Or do we need anything special = (config / additional gateway) > to handle this? > > Any answer (yes/ no / yes with X) is fine. The goal of the text is = simply to make it clear for SP > whether such topology is in scope of the document or not. (currently I = believe it is not in scope) >=20 > Then the text should be modified to clarify this. >=20 > > > >> Section 7 describes > >> how this would work from a protocol standpoint. > > > > "The desired result, in such a scenario is to present the internal > > =A0 peer (CE3) with a BGP advertisement that contains the same BGP = Path > > =A0 Attributes received from CE1 and to the external peer (CE 2) a = BGP > > =A0 advertisement that would correspond to a situation where AS 1 = and 2 > > =A0 have an external BGP session between them." > > > > I agree that this is the desired result. The question is does this = document achieve this? >=20 > By the rules specified regarding how the vrf-import stage modifies BGP > attributes. >=20 > The AS of the importing VRF is compared to the Origin AS of the > ATTR_SET attribute. CE1 and CE3 have the same "VRF AS" so the route is > imported as-is (using the original attributes preserved in ATTR_SET). > When a route from CE1 is imported into the VRF containing CE2 the VRF > ASes do not match. This results in an implicit eBGP peering between AS > 1 and AS 2. >=20 > > > > " =A0 =A0 =A0When importing a route without the ATTR_SET attribute = to a VRF > > =A0 =A0 =A0that support Interior BGP mode, a PE router MUST prepend = its own > > =A0 =A0 =A0as number to the AS_PATH." > > > > How such route is re-advertised in iBGP to the CE? >=20 > The exact same behavior as if you had a CE that speaks to the PE using > the current mechanisms (without this document) and that CE is then > speaking iBGP to another CE (and using reflection to propagate > routes). Ok. IMHO for some readers that would be a useful precision to add in the = document. In particular, this means that the CE will receive over an = iBGP session both "valid"/AS policy compliant BGP attributes, and = default BGP attributes (ala eBGP) that may need to be policed by a = routemap. =20 > > Is a LOCAL_PREF attribute sent? A priori yes as per RFC 4271 = ("LOCAL_PREF is a well-known attribute > that SHALL be included in all UPDATE messages that a given BGP speaker = sends to other internal > peers.") With which value? >=20 > The default value. LOCAL_PREF is always initialized to the default > value for an eBGP received route. >=20 > > > > Same question when the AS number in ATTR_SET does not match the = local AS configured in the VRF of > the iBGP PE-CE session. > > >=20 > Same answer. There is an implicit eBGP peering between the Origin AS > and the VRF AS of the importing VRF. >=20 > Pedro. From pedro.r.marques@gmail.com Thu Apr 28 13:29:40 2011 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 9547FE06D7; Thu, 28 Apr 2011 13:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SXr4uRnYFRz; Thu, 28 Apr 2011 13:29:39 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE72E06D2; Thu, 28 Apr 2011 13:29:39 -0700 (PDT) Received: by iyn15 with SMTP id 15so3260494iyn.31 for ; Thu, 28 Apr 2011 13:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JVsJPpF9sw+N4RbDt/u20emkku04E87pO65R+5VMd74=; b=TfD4JqGJJskqBgGg3mdDo6GQLWp0Ug1WwXJew0a75c0sraLuuvi3dcrGt6d5A5Rexx u5QVK15X/m4ZRjPtINdzOP4AIgmpoycfz8DgDyn2mxVKgK8aKWlO2MPF6eO0aowCi3co Ai3vYGYxjPkRqUu0sgW56OzZyVtowOKjqEXy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QxK+IxRzC3k9V3odNpc6mYl88oKFMrPjLYt3zXlwEMVAFzpaQgECNt3j1myQqIAKyo Y6OgQSoU6yBVBWKPB3Zls74wlpM30igPy6nBTStkShRVuwbZ8JchwW1bKg7kCFp+tVc2 xyetbxVisaA5NZY1lEfoAP+NT/OlyKz2FWbeA= MIME-Version: 1.0 Received: by 10.42.146.74 with SMTP id i10mr3148094icv.379.1304022578974; Thu, 28 Apr 2011 13:29:38 -0700 (PDT) Received: by 10.42.172.199 with HTTP; Thu, 28 Apr 2011 13:29:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2011 13:29:38 -0700 Message-ID: From: Pedro Marques To: bruno.decraene@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr@ietf.org, l3vpn@ietf.org Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 20:29:40 -0000 Bruno, On Thu, Apr 28, 2011 at 5:41 AM, wrote= : >> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET >> attribute is only propagated as long as the route is an "inet-vpn" >> route... once imported into a VRF it disappears. > > Yes. With iBGP, the ATTR_SET attribute will be "poped" but only after cop= ying the BGP attributes of the customer route (e.g. LOCAL_PREF) on the regu= lar iBGP attributes. Then the next ASBR would "push" them back in a new ATT= R_SET attribute. Hence BGP attributes of the customer are propagated end to= end. But that wouldn't be inter-as option A, would it ? Option A is defined as using eBGP on a per VRF basis. I believe that one needs to consider what is the design of the "customer" AS... while their may be topologies where you can get away with the scenario you suggest, i'm now aware of a generic scenario where this would work correctly. > > Given that l3vpn-ibgp comes after inter AS, I would assume that inter AS = interconnection pre-exist when the first iBGP PE-CE customer comes. > So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face it. Tha= t's fine for me if l3vpn-ibgp does not work with inter AS option A There is no way i'm aware off to achieve VPN network transparency when the provider interconnect is based on converting VPN routes to IP route passing it through an eBGP peering and back. The motivation to do iBGP is to provide VPN network transparency. In inter-as cases to achieve transparency iBGP is not the only requirement. You also need to exchange this customer routes via option B (or C). >, but I still believe this should be indicated in the "deployment consider= ations" section of the document. You can also add that to be able to provid= e iBGP PE-CE, SP should favor inter AS option B (over A). > Will do. Pedro. From bruno.decraene@orange-ftgroup.com Fri Apr 29 10:14:12 2011 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 38432E06A1; Fri, 29 Apr 2011 10:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.07 X-Spam-Level: X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+BLOwFP1VLe; Fri, 29 Apr 2011 10:14:11 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 728F8E06AD; Fri, 29 Apr 2011 10:14:11 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2BD6AFC400C; Fri, 29 Apr 2011 19:14:19 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 171E7FC4007; Fri, 29 Apr 2011 19:14:19 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Apr 2011 19:14:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Apr 2011 19:14:08 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 Thread-Index: AcwF4xMNaOSs+Mi2QQqHLdJ4+RW5JAArQrpg References: From: To: X-OriginalArrivalTime: 29 Apr 2011 17:14:10.0376 (UTC) FILETIME=[DADB3C80:01CC0690] Cc: idr@ietf.org, l3vpn@ietf.org Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 17:14:12 -0000 Pedro, Thanks for the clarification text that you have added on inter AS VPN. New draft (-04) addresses all my comments. Thanks, Regards, Bruno > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >=20 > Bruno, >=20 > On Thu, Apr 28, 2011 at 5:41 AM, wrote: >=20 > >> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET > >> attribute is only propagated as long as the route is an "inet-vpn" > >> route... once imported into a VRF it disappears. > > > > Yes. With iBGP, the ATTR_SET attribute will be "poped" but only after copying the BGP attributes of > the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes. Then the next ASBR would "push" > them back in a new ATTR_SET attribute. Hence BGP attributes of the customer are propagated end to end. >=20 > But that wouldn't be inter-as option A, would it ? Option A is defined > as using eBGP on a per VRF basis. >=20 > I believe that one needs to consider what is the design of the > "customer" AS... while their may be topologies where you can get away > with the scenario you suggest, i'm now aware of a generic scenario > where this would work correctly. >=20 >=20 > > > > Given that l3vpn-ibgp comes after inter AS, I would assume that inter AS interconnection pre-exist > when the first iBGP PE-CE customer comes. >=20 >=20 > > So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face it. That's fine for me if l3vpn- > ibgp does not work with inter AS option A >=20 > There is no way i'm aware off to achieve VPN network transparency when > the provider interconnect is based on converting VPN routes to IP > route passing it through an eBGP peering and back. >=20 > The motivation to do iBGP is to provide VPN network transparency. In > inter-as cases to achieve transparency iBGP is not the only > requirement. You also need to exchange this customer routes via option > B (or C). >=20 > >, but I still believe this should be indicated in the "deployment considerations" section of the > document. You can also add that to be able to provide iBGP PE-CE, SP should favor inter AS option B > (over A). > > >=20 > Will do. >=20 > Pedro. From ietfc@btconnect.com Sat Apr 30 04:41:53 2011 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 07A97E06F3 for ; Sat, 30 Apr 2011 04:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZhIFZ9v3U3S for ; Sat, 30 Apr 2011 04:41:52 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id EBB08E0697 for ; Sat, 30 Apr 2011 04:41:51 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2beaomr06.btconnect.com with SMTP id CWO29438; Sat, 30 Apr 2011 12:41:49 +0100 (BST) Message-ID: <00c501cc0723$0cd90220$4001a8c0@gateway.2wire.net> From: "t.petch" Cc: References: <20110424170001.26672.2832.idtracker@ietfc.amsl.com> Date: Sat, 30 Apr 2011 12:40:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4DBBF57D.006E, actions=TAG X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4DBBF57E.0022,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [Idr] I-D Action:draft-ietf-idr-deprecate-as-sets-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 11:41:53 -0000 Um. The trouble with tinkering is that the text may lose its coherence; I know, I've done it too often myself. Two points. "Without AS_SET aggregates must always contain only less specific prefixes (not less than or equal to), and must never aggregate an exact match. " I find a clear, easy to apply statement of what to do, whereas I easily get lost in Appendix A, so I would be happy not to have Appendix A. By contrast, I would like to give this sentence more emphasis and would do so by making it the start of a new paragraph. But " Route aggregation is possible under some conditions without the use of AS_SETs (please see Appendix A for relevant discussion and suggestions)." I think prone to mislead. OK, it is a part of a paragraph about using AS-SET but still think that it overstates the case. We don't want everyone to de-aggregate everything! Suggest " Route aggregation that was previously performed by proxy aggregation is still possible under some conditions without the use of AS_SETs (please see Appendix A for relevant discussion and suggestions)." Tom Petch ----- Original Message ----- From: To: Cc: Sent: Sunday, April 24, 2011 7:00 PM Subject: [Idr] I-D Action:draft-ietf-idr-deprecate-as-sets-03.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing Working Group of the IETF. > > > Title : Deprecation of the use of BGP AS_SET, AS_CONFED_SET. > Author(s) : W. Kumari, K. Sriram > Filename : draft-ietf-idr-deprecate-as-sets-03.txt > Pages : 8 > Date : 2011-04-24 > > This document deprecates the use of the AS_SET and AS_CONFED_SET > types of the AS_PATH in BGPv4. This is done to simplify the design > and implementation of the BGP protocol and to make the semantics of > the originator of a route more clear. This will also simplify the > design, implementation and deployment of ongoing work in the Secure > Inter-Domain Routing Working Group. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >