From jgs@juniper.net Tue Mar 1 07:29: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 5AB423A6915 for ; Tue, 1 Mar 2011 07:29:22 -0800 (PST) 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 qGFeTCmVPXZp for ; Tue, 1 Mar 2011 07:29:21 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id DD7C03A6912 for ; Tue, 1 Mar 2011 07:29:19 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTW0RDvP43/+y1l2EamDRKhr60irsJ70b@postini.com; Tue, 01 Mar 2011 07:30:24 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 1 Mar 2011 07:29:05 -0800 From: John Scudder To: "idr@ietf.org List" Date: Tue, 1 Mar 2011 07:29:49 -0800 Thread-Topic: IETF-80 agenda topics Thread-Index: AcvYJWaZM/OFVTBbSySvlk+2UlXo2g== Message-ID: <0E803B31-AC28-4DCB-9AD9-6A26746BB57C@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: [Idr] IETF-80 agenda topics 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, 01 Mar 2011 15:29:23 -0000 Folks, We're planning to meet at IETF-80. On the draft agenda we are scheduled fo= r Thursday, March 31 13:00 - 15:00. Please forward any IDR agenda items yo= u might have to Sue and myself. The deadline is two weeks from now -- Marc= h 15, 2011 by 13:00 U.S. Eastern Time. I apologize for the tardy call for = topics! If you plan to make a presentation, please keep in mind the IDR tradition, = "no Internet Draft - no time slot". You should also plan to send your slid= es to Sue and me no later than 24 hours prior to the meeting. --John & Sue From Internet-Drafts@ietf.org Tue Mar 8 19:30: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 069873A6817; Tue, 8 Mar 2011 19:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 BgqowBu2XtiQ; Tue, 8 Mar 2011 19:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61B33A6803; Tue, 8 Mar 2011 19:30:01 -0800 (PST) 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.12 Message-ID: <20110309033001.2857.94678.idtracker@localhost> Date: Tue, 08 Mar 2011 19:30:01 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-best-external-03.txt 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, 09 Mar 2011 03:30:03 -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 : Advertisement of the best external route in BGP Author(s) : P. Marques, et al. Filename : draft-ietf-idr-best-external-03.txt Pages : 11 Date : 2011-03-08 The base BGP specifications prevent a BGP speaker from advertising any route that is not the best route for a BGP destination. This document specifies a modification of this rule. Routes are divided into two categories, "external" and "internal". A specification is provided for choosing a "best external route" (for a particular value of the Network Layer Reachability Information). A BGP speaker is then allowed to advertise its "best external route" to its internal BGP peers, even if that is not the best route for the destination. The document explains why advertising the best external route can improve convergence time without causing routing loops. Additional benefits include reduction of inter-domain churn and avoidance of permanent route oscillation. The document also generalizes the notions of "internal" and "external" so that they can be applied to Route Reflector Clusters and Autonomous System Confederations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-best-external-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-best-external-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-08191814.I-D@ietf.org> --NextPart-- From jie.dong@huawei.com Wed Mar 9 00:24: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 2420F3A6879; Wed, 9 Mar 2011 00:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=1.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] 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 Y2Z3RMT8YdJA; Wed, 9 Mar 2011 00:24:15 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1FE5F3A6864; Wed, 9 Mar 2011 00:24:14 -0800 (PST) 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 <0LHS00KGR7CRSR@szxga03-in.huawei.com>; Wed, 09 Mar 2011 16:24:28 +0800 (CST) Received: from szxeml201-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 <0LHS005ZJ7CRKZ@szxga03-in.huawei.com>; Wed, 09 Mar 2011 16:24:27 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Mar 2011 16:24:20 +0800 Received: from SZXEML508-MBX.china.huawei.com ([169.254.6.65]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Wed, 09 Mar 2011 16:24:27 +0800 Date: Wed, 09 Mar 2011 08:24:26 +0000 From: Jie Dong In-reply-to: <4D64D25B.5040202@spakka.net> X-Originating-IP: [10.110.98.31] To: Colin Petrie , "idr@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C927AB319B@szxeml508-mbx.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] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 Thread-index: AQHL0zxp1jor0mUGsEqJyStv0bHc+JQkvqTg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4D64D25B.5040202@spakka.net> Cc: "grow@ietf.org" Subject: Re: [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-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: Wed, 09 Mar 2011 08:24:17 -0000 Support this work. Jie > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Colin > Petrie > Sent: Wednesday, February 23, 2011 5:25 PM > To: idr@ietf.org > Cc: grow@ietf.org > Subject: Re: [Idr] Fwd: New Version Notification for > draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 > > On 22/02/11 14:50, Neil J. McRae wrote: > > Rob, > > This is a great document and as a network operator I think this is > > something that I'd like to see implemented. The downsides of a minute > > inconsistency are not great enough compared to a complete BGP failure > with > > my organisations network* > > > > I totally agree. This document is a pretty good summary of the > requirements on this, and a reasonable suggested implementation to > mitigate the problems we have seen before too many times. > > Great work, thanks Rob :) > > Cheers > Colin > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From Internet-Drafts@ietf.org Wed Mar 9 11:15: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 D5D343A698B; Wed, 9 Mar 2011 11:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 JDIhhP6Svvj7; Wed, 9 Mar 2011 11:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EBAA3A680F; Wed, 9 Mar 2011 11:15:02 -0800 (PST) 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.12 Message-ID: <20110309191502.12679.70972.idtracker@localhost> Date: Wed, 09 Mar 2011 11:15:02 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-link-bandwidth-02.txt 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, 09 Mar 2011 19:15: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 : BGP Link Bandwidth Extended Community Author(s) : P. Mohapatra, R. Fernando Filename : draft-ietf-idr-link-bandwidth-02.txt Pages : 5 Date : 2011-03-09 This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-link-bandwidth-02.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-link-bandwidth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-09110813.I-D@ietf.org> --NextPart-- From bruno.decraene@orange-ftgroup.com Thu Mar 10 01:58: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 6B35F3A68FA for ; Thu, 10 Mar 2011 01:58:16 -0800 (PST) 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=[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 La694tKzvC0q for ; Thu, 10 Mar 2011 01:58:15 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 8D29B3A68C4 for ; Thu, 10 Mar 2011 01:58:15 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7CA88FC4010; Thu, 10 Mar 2011 10:59:38 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 6B068FC400F; Thu, 10 Mar 2011 10:59:38 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 10:59:32 +0100 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, 10 Mar 2011 10:59:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-idr-reserved-extended-communities Thread-Index: AcuE6ZZddKRGLZzeQ1KDF5bzoq8eoAAAPT+gFoZvILA= References: Your message of Sat, 13 Nov 2010 07:36:31 -0800. <7807.1289841699@erosen-linux> From: To: , X-OriginalArrivalTime: 10 Mar 2011 09:59:32.0245 (UTC) FILETIME=[DA6CBC50:01CBDF09] Cc: draft-decraene-idr-reserved-extended-communities@tools.ietf.org Subject: [Idr] draft-ietf-idr-reserved-extended-communities 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, 10 Mar 2011 09:58:16 -0000 Eric, all, > From: DECRAENE Bruno=20 > Sent: Monday, November 15, 2010 7:05 PM > Subject: RE: [Idr] draft-decraene-idr-reserved-extended-communities-00 [...]=20 > > I also think it's confusing to call these extended communities "reserved", > > as RFC 5226 ("Guidelines for Writing IANA Considerations") defines the term > > "reserved" as meaning "not to be assigned". >=20 > We can use a different name. Would you have any proposition? >=20 We could propose to use the name "Assigned extended communities". This seems valid according to RFC 5226 (Guidelines for Writing an IANA Considerations Section in RFCs point of view): "The binding or association of a specific value with a particular purpose within a namespace is called an assigned number (or assigned value, or sometimes a "code point", "protocol constant", or "protocol parameter"). Each assignment of a value in a namespace is called a registration" Would this be fine for you? / Any comment on this proposition? In the absence of any objections within the next two weeks I'll issue a revised version which reflects the above proposition. Thanks, Regards, Bruno From Internet-Drafts@ietf.org Mon Mar 14 01:30: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 97DC43A6C00; Mon, 14 Mar 2011 01:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 dFgqYFno77Sh; Mon, 14 Mar 2011 01:30:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD80F3A6BB8; Mon, 14 Mar 2011 01:30: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.12 Message-ID: <20110314083001.9053.91204.idtracker@localhost> Date: Mon, 14 Mar 2011 01:30:01 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-fsm-subcode-01.txt 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, 14 Mar 2011 08:30: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 : Subcodes for BGP Finite State Machine Error Author(s) : J. Dong, M. Chen Filename : draft-ietf-idr-fsm-subcode-01.txt Pages : 5 Date : 2011-03-14 This document defines several subcodes for BGP Finite State Machine Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-fsm-subcode-01.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-fsm-subcode-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14012158.I-D@ietf.org> --NextPart-- From raszuk@cisco.com Tue Mar 15 01:35: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 5E6AB3A6B07 for ; Tue, 15 Mar 2011 01:35:32 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siBFVYDH6yMB for ; Tue, 15 Mar 2011 01:35:30 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6FE433A6AB0 for ; Tue, 15 Mar 2011 01:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1442; q=dns/txt; s=iport; t=1300178215; x=1301387815; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=4UriLSVqielfq3H7yI+1k0eqhussu8B+b2edsQQnJmI=; b=BT8g/b++G0Q+Mh2HCUh7WM4ynEcIffWb/KSMBqpOZVf385fZsd7JhnNm 9naTrAy9cJszJM93rtzWpzcCyKY07TCnYQY0UET3tx/VsmNDaUi+EUWrz 70K3c59N+40V+RtaDnc+1g0DpYqtbXD9ediI2pVL7vHXMxDR7ChGbCxSw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFfCfk2tJV2a/2dsb2JhbACmDneleYJrDgGZfIViBIxdg08 X-IronPort-AV: E=Sophos;i="4.62,321,1297036800"; d="scan'208";a="346761092" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 08:36:54 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2F8arin005562 for ; Tue, 15 Mar 2011 08:36:54 GMT Message-ID: <4D7F2527.9090706@cisco.com> Date: Tue, 15 Mar 2011 09:36:55 +0100 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] 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: Tue, 15 Mar 2011 08:35:32 -0000 Hi, I would like to propose an amendment to the below document: Title : Extended Message support for BGP http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01 The document increases the max message size of BGP from 4096 octets to 65535 octets. I agree that this is a good general idea. However it follows the same notion as base spec and defines single max message size for all possible types of BGP messages. As it has been previously recognized during WG meetings as well as on the list there are number of legitimate cases where during an error condition (for example: malformed UPDATE Msg, malformed BGP Attribute within UPDATE Msg etc ...) we should maintain a session's liveness while in the same time report the error condition to a peer. Within the BGP build-in reporting facilities some operators found it valuable to be able to include the entire malformed UPDATE message to the peer who generated it to increase the awareness of the problem at hand as well as speed up the troubleshooting process. This will be only possible if we differentiate maximum size of BGP UPDATE Massage to be less then any other BGP message's maximum size to allow room for a new message header. For all practical purposes it seems sufficient to allow the header size of 128 octets. I welcome comments and opinions on the proposed above BGP messages size differentiation. Best regards, R. From elisa@jasinska.de Tue Mar 15 08:25: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 96A973A6D9F for ; Tue, 15 Mar 2011 08:25:58 -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 s9JVVvYgUBYd for ; Tue, 15 Mar 2011 08:25:55 -0700 (PDT) Received: from mail.dyinggiraffe.org (mail.dyinggiraffe.org [82.94.215.221]) by core3.amsl.com (Postfix) with ESMTP id B7D733A6D71 for ; Tue, 15 Mar 2011 08:25:55 -0700 (PDT) Received: from host77-62-158-177.kpn-gprs.nl (mail.dyinggiraffe.org [82.94.215.221]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.dyinggiraffe.org (Postfix) with ESMTPSA id C3D1045021 for ; Tue, 15 Mar 2011 16:27:17 +0100 (CET) Message-ID: <4D7F8552.3070703@jasinska.de> Date: Tue, 15 Mar 2011 16:27:14 +0100 From: Elisa Jasinska User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Idr] Fwd: New Version Notification for draft-jasinska-ix-bgp-route-server-02 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, 15 Mar 2011 15:25:58 -0000 Hi, this in an updated version of draft-jasinska-ix-bgp-route-server-01. As proposed at the last meeting, we split the document into two, separating operational and standards track content. The document posted with this email, draft-jasinska-ix-bgp-route-server-02, includes the standards track part: specification and protocol related considerations. Feedback would be much appreciated! Thanks and best regards Elisa -------- Original Message -------- Subject: New Version Notification for draft-jasinska-ix-bgp-route-server-02 Date: Mon, 14 Mar 2011 16:29:33 -0700 From: IETF I-D Submission Tool To: elisa@llnw.com CC: nick@inex.ie,raszuk@cisco.com,niels.bakker@ams-ix.net A new version of I-D, draft-jasinska-ix-bgp-route-server-02.txt has been successfully submitted by Elisa Jasinska and posted to the IETF repository. Filename: draft-jasinska-ix-bgp-route-server Revision: 02 Title: Internet Exchange Route Server Creation_date: 2011-03-15 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more exterior BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. The IETF Secretariat. From ilya@nobulus.com Thu Mar 17 05:27: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 58C713A6930 for ; Thu, 17 Mar 2011 05:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.151, 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 agm3h2Y+ZJu3 for ; Thu, 17 Mar 2011 05:27:41 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 288383A6875 for ; Thu, 17 Mar 2011 05:27:40 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 49CD217111; Thu, 17 Mar 2011 13:29:05 +0100 (CET) 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 Elp9IcIyjQmt; Thu, 17 Mar 2011 13:29:03 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:7c8c:ab51:f1d5:fba2]) by nobulus.com (Postfix) with ESMTPA id D9F65170BE; Thu, 17 Mar 2011 13:29:00 +0100 (CET) Message-ID: <0CCBDB35EB69471086A5845D3567C8BD@hnivarlas1> From: "iLya" To: , References: <4D7F2527.9090706@cisco.com> In-Reply-To: <4D7F2527.9090706@cisco.com> Date: Thu, 17 Mar 2011 13:28:58 +0100 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 Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (length) 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, 17 Mar 2011 12:27:42 -0000 -------------------------------------------------- > The document increases the max message size of BGP from 4096 octets to > 65535 octets. I agree that this is a good general idea. > [...] > This will be only possible if we differentiate maximum size of BGP UPDATE > Massage to be less then any other BGP message's maximum size to allow room > for a new message header. For all practical purposes it seems sufficient > to allow the header size of 128 octets. > >From operator's perspective ability to return complete UPDATE message inside a diagnostic message is essential. So I support the proposal of limiting UPDATE Message length to something smaller than general MAX_SIZE. Whether it should be less by 128 octects or by some other value I'm not yet sure. Kind regards, iLya From ilya@nobulus.com Thu Mar 17 05:33:05 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 DCF2C3A68BF for ; Thu, 17 Mar 2011 05:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 cFC0Da2ziNDL for ; Thu, 17 Mar 2011 05:33:02 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id E35E13A6875 for ; Thu, 17 Mar 2011 05:33:01 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 3A34B17128; Thu, 17 Mar 2011 13:34:29 +0100 (CET) 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 AuYssQ7O2kvf; Thu, 17 Mar 2011 13:34:27 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:7c8c:ab51:f1d5:fba2]) by nobulus.com (Postfix) with ESMTPA id 075F917117; Thu, 17 Mar 2011 13:34:27 +0100 (CET) Message-ID: From: "iLya" To: , References: <4D7F2527.9090706@cisco.com> In-Reply-To: <4D7F2527.9090706@cisco.com> Date: Thu, 17 Mar 2011 13:34:26 +0100 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 Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) 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, 17 Mar 2011 12:33:05 -0000 -------------------------------------------------- > Title : Extended Message support for BGP > http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01 > Section 2 reads: "...This is an asymmetric capability. I.e. one speaker could signal the capability and the other not..". If one side does not signal capability then it may not prepared to receive messages longer than original specification dictates. In other words, even for asymmetric flow of big (>4096) messages both sides need to have support and announce that. Perhaps having 'receive' and 'send' flags in capability value and requiring each side to advertise new capability would be better approach than sending big messages to a speaker that didn't advertise 'extended messages' capability. Kind regards, iLya From jakob.heitz@ericsson.com Thu Mar 17 06:40: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 55D4F3A69CD for ; Thu, 17 Mar 2011 06:40:42 -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 f5+PG2GPLByP for ; Thu, 17 Mar 2011 06:40:40 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id CA28A3A69B1 for ; Thu, 17 Mar 2011 06:40:40 -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 p2HDfMNa022262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Mar 2011 08:42:02 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 17 Mar 2011 09:40:10 -0400 From: Jakob Heitz To: iLya Date: Thu, 17 Mar 2011 09:40:03 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) Thread-Index: AcvkqNVmgY2QUlWOR6GRdFeip+Uc4A== Message-ID: References: <4D7F2527.9090706@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: "raszuk@cisco.com" , "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) 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, 17 Mar 2011 13:40:42 -0000 if one speaker can send long, but the peer can not, then that peer can not = include the (long) malformed update in his (short) notification.=20 -- Jakob Heitz. On Mar 17, 2011, at 5:34 AM, "iLya" wrote: > -------------------------------------------------- >> Title : Extended Message support for BGP >> http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01 >>=20 >=20 > Section 2 reads: "...This is an asymmetric capability. I.e. one speaker= =20 > could signal the capability and the other not..". >=20 > If one side does not signal capability then it may not prepared to receiv= e=20 > messages longer than original specification dictates. In other words, eve= n=20 > for asymmetric flow of big (>4096) messages both sides need to have suppo= rt=20 > and announce that. Perhaps having 'receive' and 'send' flags in capabilit= y=20 > value and requiring each side to advertise new capability would be better= =20 > approach than sending big messages to a speaker that didn't advertise=20 > 'extended messages' capability. >=20 > Kind regards, > iLya=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ilya@nobulus.com Thu Mar 17 06:59: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 193063A695B for ; Thu, 17 Mar 2011 06:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, STOX_REPLY_TYPE=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 8AEa4p87RU7N for ; Thu, 17 Mar 2011 06:59:08 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id D21EA3A68AD for ; Thu, 17 Mar 2011 06:59:07 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 1C5D717128; Thu, 17 Mar 2011 15:00:34 +0100 (CET) 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 y4oNtvepabFI; Thu, 17 Mar 2011 15:00:31 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:7c8c:ab51:f1d5:fba2]) by nobulus.com (Postfix) with ESMTPA id B73481712D; Thu, 17 Mar 2011 15:00:31 +0100 (CET) Message-ID: <3499DAA9F09F427D91A8440C8084A424@hnivarlas1> From: "iLya" To: "Jakob Heitz" References: <4D7F2527.9090706@cisco.com> In-Reply-To: Date: Thu, 17 Mar 2011 15:00:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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, idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) 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, 17 Mar 2011 13:59:09 -0000 -------------------------------------------------- > if one speaker can send long, but the peer can not, then that peer can not > include the (long) malformed update in his (short) notification. > indeed, so it makes asymmetric case kind of impossible. Cheers, iLya From jgs@juniper.net Thu Mar 17 09:03: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 F387E3A6996 for ; Thu, 17 Mar 2011 09:03:03 -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 3HBNOXGwe9BS for ; Thu, 17 Mar 2011 09:03:03 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 180003A6989 for ; Thu, 17 Mar 2011 09:03:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTYIxDjcXALsfogvBOheQF7cdkHbM6i3J@postini.com; Thu, 17 Mar 2011 09:04:31 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, 17 Mar 2011 09:01:11 -0700 From: John Scudder To: "idr@ietf.org List" Date: Thu, 17 Mar 2011 09:02:19 -0700 Thread-Topic: IDR agenda for IETF-80 Thread-Index: AcvkvIidKriW8XjQQuS97ZQK6o7jPg== Message-ID: <2C615A8A-28A9-4E00-9182-5BC6C188A053@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: [Idr] IDR agenda for IETF-80 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, 17 Mar 2011 16:03:04 -0000 Agenda has been posted: http://www.ietf.org/proceedings/80/agenda/idr.txt It is still subject to change although I don't anticipate any big changes. = =20 --John From jgs@juniper.net Thu Mar 17 09:18: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 B780E3A69DB for ; Thu, 17 Mar 2011 09:18:06 -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 4E0tsdf6m5eG for ; Thu, 17 Mar 2011 09:18:06 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id BE4B63A69D7 for ; Thu, 17 Mar 2011 09:18:05 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTYI0lQZqUeepUn1Gx02vcdN6JH2oBeoa@postini.com; Thu, 17 Mar 2011 09:19:34 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; Thu, 17 Mar 2011 09:13:13 -0700 From: John Scudder To: "idr@ietf.org List" Date: Thu, 17 Mar 2011 09:14:22 -0700 Thread-Topic: IDR meeting at IETF-80, call for volunteers Thread-Index: AcvkvjdoC3Co7Y0JTm+2Zsy02uBt9Q== Message-ID: <6340612B-4A33-4C5C-A950-FBE876E71604@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: [Idr] IDR meeting at IETF-80, call for volunteers 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, 17 Mar 2011 16:18:06 -0000 Folks, You will have noticed that our agenda for IETF-80 is very full again. In a= ddition, Sue will be unable to attend this time so I'll be the only chair. = With the help of the WG members we were able to get through a busy agenda = productively last time. I'd like to ask for help again this time! =20 Please: * Arrive on time. The meeting is scheduled to start at 13:00. Let's plan to start working then. * Consider volunteering to take notes. This is very important -- we can't start without at least one note-taker. Unlike previous meetings, the chair can't do it since I'll be the only one. Even if you can't take notes for the whole meeting (for example because you are presenting) taking some notes would help -- several sets of notes is very useful when preparing the minutes. * Consider volunteering as Jabber scribe. We do NOT need every presentatio= n transcribed to Jabber. The main need is for someone to relay Jabber Q&A to the mic. * If you are presenting, get me your slides as early as you can. You may=20 revise them if needed, up until 24 hours prior to the meeting. * If you are attending, review the drafts (and if the presenters have=20 made them available, the slides) so that you can be prepared to make good use of our limited Q&A time. Feel free to start Q&A on the list immediately -- no need to wait for the in-person meeting! Thanks in advance. If you are willing to volunteer as note taker or Jabber= scribe, please let me know. --John= From jie.dong@huawei.com Thu Mar 17 18:18: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 9E1623A6B03 for ; Thu, 17 Mar 2011 18:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.691 X-Spam-Level: X-Spam-Status: No, score=-3.691 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 bC7QM9E5JAF9 for ; Thu, 17 Mar 2011 18:18:40 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5C2983A6AB0 for ; Thu, 17 Mar 2011 18:18:40 -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 <0LI80070GBPAIJ@szxga03-in.huawei.com> for idr@ietf.org; Fri, 18 Mar 2011 09:19:58 +0800 (CST) Received: from szxeml206-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 <0LI800461BPA09@szxga03-in.huawei.com> for idr@ietf.org; Fri, 18 Mar 2011 09:19:58 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 18 Mar 2011 09:19:53 +0800 Received: from SZXEML508-MBX.china.huawei.com ([169.254.6.65]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 18 Mar 2011 09:19:57 +0800 Date: Fri, 18 Mar 2011 01:19:56 +0000 From: Jie Dong In-reply-to: X-Originating-IP: [10.110.98.31] To: iLya , "raszuk@cisco.com" , "idr@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C927AB5144@szxeml508-mbx.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] draft-ymbk-bgp-extended-messages-01 (capability code) Thread-index: AQHL5KA63eZRoOk9Gk6RFc3IjESj+ZQyRhFQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4D7F2527.9090706@cisco.com> Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) 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, 18 Mar 2011 01:18:42 -0000 Hi iLya, Section 2 says: "By advertising the BGP Extended message Capability to a peer, a BGP speaker conveys to that peer that the speaker is capable of receiving and properly handling BGP Extended Messages." Hence the big messages would only be sent to peers which advertised this capability. To my understanding, this asymmetric capability negotiation implicates that a speaker which did not advertise this capability could encapsulate and send big messages to peers which advertised this capability, while itself is not willing to receive big messages. Agree that using 'receive' and 'send' flags may make this negotiation clearer. Regards, Jie > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of iLya > Sent: Thursday, March 17, 2011 8:34 PM > To: raszuk@cisco.com; idr@ietf.org > Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) > > -------------------------------------------------- > > Title : Extended Message support for BGP > > http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01 > > > > Section 2 reads: "...This is an asymmetric capability. I.e. one speaker > could signal the capability and the other not..". > > If one side does not signal capability then it may not prepared to receive > messages longer than original specification dictates. In other words, even > for asymmetric flow of big (>4096) messages both sides need to have > support > and announce that. Perhaps having 'receive' and 'send' flags in capability > value and requiring each side to advertise new capability would be better > approach than sending big messages to a speaker that didn't advertise > 'extended messages' capability. > > Kind regards, > iLya > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Thu Mar 17 18:48:29 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 8236D3A6A5F for ; Thu, 17 Mar 2011 18: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.001, BAYES_00=-2.599, HTML_MESSAGE=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 DDUIzjydLl7T for ; Thu, 17 Mar 2011 18:48:28 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id ACCFF3A69CF for ; Thu, 17 Mar 2011 18:48:28 -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 p2I1nuBC020074 for ; Thu, 17 Mar 2011 20:49:57 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 17 Mar 2011 21:49:50 -0400 From: Jakob Heitz To: "idr@ietf.org" Date: Thu, 17 Mar 2011 21:49:49 -0400 Thread-Topic: draft-ymbk-bgp-extended-messages-01, size Thread-Index: AcvlDsRmxy7c92S8SY64zbEnEsZK+g== Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9EUSAACMS0701e_" MIME-Version: 1.0 Subject: [Idr] draft-ymbk-bgp-extended-messages-01, size 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, 18 Mar 2011 01:48:29 -0000 --_000_7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft states: > All BGP extended messages have maximum message size of 65535 octets. Could we make that just a little shorter, perhaps 65000 or 64000. It would make implementation a little more efficient when storing it or shunting it around in the code with headers on it. -- Jakob Heitz. --_000_7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The draft states:
>   All BGP extended messages hav= e maximum message size of 65535 octets.
 
Could we make that just a little shorter, perh= aps 65000 or 64000.
It would make implementation a little more eff= icient
when storing it or shunting it around in the c= ode with headers on it.
 
--
Jakob Heitz.
 
 
 --_000_7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9EUSAACMS0701e_-- From jeff.tantsura@ericsson.com Fri Mar 18 00:20: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 E83E33A6AEB for ; Fri, 18 Mar 2011 00:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.58 X-Spam-Level: X-Spam-Status: No, score=-4.58 tagged_above=-999 required=5 tests=[AWL=2.019, 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 PNBRJj2HQtSE for ; Fri, 18 Mar 2011 00:20:56 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 928C23A6A81 for ; Fri, 18 Mar 2011 00:20:56 -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 p2I7MNDa011595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Mar 2011 02:22:24 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 18 Mar 2011 03:22:23 -0400 From: Jeff Tantsura To: Jakob Heitz , iLya Date: Fri, 18 Mar 2011 03:22:22 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) Thread-Index: AcvkqNVmgY2QUlWOR6GRdFeip+Uc4AAkurig Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60AA21C4B82@EUSAACMS0701.eamcs.ericsson.se> References: <4D7F2527.9090706@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: "raszuk@cisco.com" , "idr@ietf.org" Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) 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, 18 Mar 2011 07:20:58 -0000 That's why capability split to send/receive would make sense Regards, Jeff =20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jakob= Heitz Sent: Thursday, March 17, 2011 06:40 To: iLya Cc: raszuk@cisco.com; idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) if one speaker can send long, but the peer can not, then that peer can not = include the (long) malformed update in his (short) notification.=20 -- Jakob Heitz. On Mar 17, 2011, at 5:34 AM, "iLya" wrote: > -------------------------------------------------- >> Title : Extended Message support for BGP >> http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01 >>=20 >=20 > Section 2 reads: "...This is an asymmetric capability. I.e. one speaker= =20 > could signal the capability and the other not..". >=20 > If one side does not signal capability then it may not prepared to receiv= e=20 > messages longer than original specification dictates. In other words, eve= n=20 > for asymmetric flow of big (>4096) messages both sides need to have suppo= rt=20 > and announce that. Perhaps having 'receive' and 'send' flags in capabilit= y=20 > value and requiring each side to advertise new capability would be better= =20 > approach than sending big messages to a speaker that didn't advertise=20 > 'extended messages' capability. >=20 > Kind regards, > iLya=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 raszuk@cisco.com Fri Mar 18 00:41:29 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 382D33A680D for ; Fri, 18 Mar 2011 00:41:29 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqkKZUBpsyDL for ; Fri, 18 Mar 2011 00:41:28 -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 514F43A67AE for ; Fri, 18 Mar 2011 00:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2602; q=dns/txt; s=iport; t=1300434177; x=1301643777; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=p5BPQeFpzH/nMt3NNn+wI69d2VUXpzTXm672rlgI+dQ=; b=ZsWKRt4SNWBWGZ8j1tDuSlplNxj0BMjr+6RN38GbJVUIR7xSrJEzxOz9 Us6nujxe+js76pbiJ7Og4aiX6RiPr29pR5barnOavn8Gg5b05UcSOwPlC fis301MCrXG21VrPIwwYg3MIaUUHAXEQRbSJFN8+oZROlbAcZW+HluYWj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGqpgk2tJXG8/2dsb2JhbAClZ3eITZ1agmwOAZkVhWMEjGODTw X-IronPort-AV: E=Sophos;i="4.63,204,1299456000"; d="scan'208";a="415711965" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-1.cisco.com with ESMTP; 18 Mar 2011 07:42:57 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2I7gtmu029416 for ; Fri, 18 Mar 2011 07:42:56 GMT Message-ID: <4D830D03.9070907@cisco.com> Date: Fri, 18 Mar 2011 08:42:59 +0100 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: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01, size and capability 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, 18 Mar 2011 07:41:29 -0000 Hello, Many thx for everyone's opinion so far. This was exactly the point of my question. Other people are welcome to express their opinion on the list reg the below three points: *A* Since we do agree that sending malformed UPDATE message back to a peer is a good thing what is really required is to make BGP UPDATE message smaller then any other message. How much smaller is debatable. For Diagnostic Message type 15 it would be 19 bytes (min BGP message size) + 12 (TLV header) so 31 extra octets would be needed. In the spec today we make it to be on the safe side for any future TLVs and recommend that Diag message is bigger then Update Msg of 128 octets. If you think that there are valid reasons to recommend even smaller value I have no opinion. *B* When defining any protocol's type or length (even going beyond routing) utilizing all usable fields to the original intended value is not to good of a practice. The bgp message length is encoded in 2 octets. That in dec is equal 65535. Allowing max massage size of that value closes doors for future extension. Value of 56535 should be reserved for future extension ! At most any BGP message size can be 65534. When BGP message size is 65535 it will have a special indication meaning to just like what is known in IPv6 world an entity called "Next Header". It will be fixed size by definition and would allow for including any subsequent header when needed. Each atomic header format will not change either. It will just allow flexible nesting of messages without any hard message boundary. So while we are at extending BGP message size I hope we will do it right. *C* I also agree with points that the capability should be symmetrical. Otherwise it will not be possible to replay back the bigger message. I am not sure I see a value of send/receive split here. What is defined in the draft is implicit "receive" and this seems what matters. But I should be sending bigger if I understand this capability from the peer which for all practical purposes mean I can parse bigger message too ;-) Many thx, R. > The draft states: > > All BGP extended messages have maximum message size of 65535 octets. > Could we make that just a little shorter, perhaps 65000 or 64000. > It would make implementation a little more efficient > when storing it or shunting it around in the code with headers on it. > -- > Jakob Heitz. > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From keyupate@cisco.com Fri Mar 18 08:03: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 C2C2E3A692D for ; Fri, 18 Mar 2011 08:03:45 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT1oXljyaEsn for ; Fri, 18 Mar 2011 08:03:44 -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 BA92D3A691C for ; Fri, 18 Mar 2011 08:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=1249; q=dns/txt; s=iport; t=1300460714; x=1301670314; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=EyytaU/s8CGxt3P9H+k4Cs12zNWAQNj5JsrsvMM61qI=; b=b9G0zqCfiVH40e8gy2JmJeq+MKN1aMl1KOykr4YqtYSQa9/Ozdgbd0/n Uv3NThgkfPfQR7Kcjdyzy9tmH9HmJnt19tMm7d6HsOCX/rpZyMYtjnHBX 7VDPYEP+ZmpK/XvuuQkuDQEkQxEZauJbrP9n42zvTFDzlXAzK1OdDXWIp 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD4Rg02tJV2Z/2dsb2JhbAClbHemTpwWhWMEhTGHMoNV X-IronPort-AV: E=Sophos;i="4.63,205,1299456000"; d="scan'208";a="668526778" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 18 Mar 2011 15:05:13 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2IF5DCv002055; Fri, 18 Mar 2011 15:05:13 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); Fri, 18 Mar 2011 08:05:05 -0700 Received: from 10.21.93.41 ([10.21.93.41]) 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, 18 Mar 2011 15:05:05 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 18 Mar 2011 08:04:22 -0700 From: Keyur Patel To: iLya , , Message-ID: Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) Thread-Index: AcvlfcNFAe4ytlFxEeCJTAAbY71bnA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Mar 2011 15:05:05.0669 (UTC) FILETIME=[DD4D3B50:01CBE57D] Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) 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, 18 Mar 2011 15:03:45 -0000 Ilya, I am not sure what we would gain by having "send" and "receive" flags. All you need to know is if your peer is capable of receiving longer messages or not so as to not drop the session! Regards, Keyur On 3/17/11 4:34 AM, "iLya" wrote: > -------------------------------------------------- >> Title : Extended Message support for BGP >> http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01 >> > > Section 2 reads: "...This is an asymmetric capability. I.e. one speaker > could signal the capability and the other not..". > > If one side does not signal capability then it may not prepared to receive > messages longer than original specification dictates. In other words, even > for asymmetric flow of big (>4096) messages both sides need to have support > and announce that. Perhaps having 'receive' and 'send' flags in capability > value and requiring each side to advertise new capability would be better > approach than sending big messages to a speaker that didn't advertise > 'extended messages' capability. > > Kind regards, > iLya > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From keyupate@cisco.com Fri Mar 18 08:05: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 ECAC03A692D for ; Fri, 18 Mar 2011 08:05:07 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 UkF0UlSaY862 for ; Fri, 18 Mar 2011 08:05:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F417B3A691C for ; Fri, 18 Mar 2011 08:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=2639; q=dns/txt; s=iport; t=1300460794; x=1301670394; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=rOT33lGZiTCkmc+JQZs5ikR7R4/oysJkVPwPA96zcnE=; b=UIyn2rRv0zjKqnn61hteudQ2Fsynt5CxUuFG1QFgfD/z7HB8/h4gPtN0 TnSszzDILo15FHjBOzgMvpm/rjLL3Ds3oXNWa+Es3az1/SWbMRd2j/jnq R+rN/1s1GPZQsB6SnfcogGTWAq1PrK5CEPcHbYqOcyL69taFcCV60WlrA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAC4Sg02tJV2b/2dsb2JhbACCYKI8UHeITZ4AnBaFYwSFMYcyg1U X-IronPort-AV: E=Sophos;i="4.63,205,1299456000"; d="scan'208,217";a="348791533" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-5.cisco.com with ESMTP; 18 Mar 2011 15:06:33 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2IF6XwD003445; Fri, 18 Mar 2011 15:06:33 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, 18 Mar 2011 08:06:33 -0700 Received: from 10.21.93.41 ([10.21.93.41]) 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, 18 Mar 2011 15:06:32 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 18 Mar 2011 08:05:49 -0700 From: Keyur Patel To: Jakob Heitz , "idr@ietf.org" Message-ID: Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01, size Thread-Index: AcvlDsRmxy7c92S8SY64zbEnEsZK+gAbzK5y In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@EUSAACMS0701.eamcs.ericsson.se> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3383280351_67653" X-OriginalArrivalTime: 18 Mar 2011 15:06:33.0163 (UTC) FILETIME=[1173C1B0:01CBE57E] Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01, size 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, 18 Mar 2011 15:05:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3383280351_67653 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Jakob, I am sorry I didn=B9t get it. What sort of implementation optimizations are w= e talking about? Regards, Keyur On 3/17/11 5:49 PM, "Jakob Heitz" wrote: > The draft states: >> > All BGP extended messages have maximum message size of 65535 octets. > =20 > Could we make that just a little shorter, perhaps 65000 or 64000. > It would make implementation a little more efficient > when storing it or shunting it around in the code with headers on it. > =20 > -- > Jakob Heitz. > =20 > =20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --B_3383280351_67653 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Idr] draft-ymbk-bgp-extended-messages-01, size Hi Ja= kob,

I am sorry I didn’t get it. What sort of implementation optimizations= are we talking about?

Regards,
Keyur


On 3/17/11 5:49 PM, "Jakob Heitz" <jakob.heitz@ericsson.com>= ; wrote:

The draft states:
>   All BGP extended messages have maximum message size of 655= 35 octets.
 
Could we make that just a little shorter, perhaps 65000 or 64000.
It would make implementation a little more efficient
when storing it or shunting it around in the code with headers on it.
 
--
Jakob Heitz.

 

____________________= ___________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 --B_3383280351_67653-- From keyupate@cisco.com Fri Mar 18 08:14: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 619A13A691C for ; Fri, 18 Mar 2011 08:14:48 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m2IcVuQEoZq for ; Fri, 18 Mar 2011 08:14:47 -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 378263A6916 for ; Fri, 18 Mar 2011 08:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=3464; q=dns/txt; s=iport; t=1300461376; x=1301670976; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=SnlUSXK+rQbTI+TQ+w6H3a+6KNozIBc5scKmSfmAdnQ=; b=G5VgftdUdQAaAlERbEvLs8Drm9MWVpTu7PPTC51HFwB4Qb31LpKMQ2ed cXt3lTtqEjZufoH37X6t0fb3ivmrZudcii/qpVjMvwJmy9aV4usghfu3B 9ktwl/kyT64p099CsXFjbsYeLA/NNogNznqQs2D/fGFrWs+kugAhjhNkq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKATg02tJV2Z/2dsb2JhbAClbHeITZ12nBKFYwSFMYcyg1U X-IronPort-AV: E=Sophos;i="4.63,205,1299456000"; d="scan'208";a="668530445" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 18 Mar 2011 15:16:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2IFFw77009197 for ; Fri, 18 Mar 2011 15:16:16 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, 18 Mar 2011 08:16:11 -0700 Received: from 10.21.93.41 ([10.21.93.41]) 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 ; Fri, 18 Mar 2011 15:16:11 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 18 Mar 2011 08:15:29 -0700 From: Keyur Patel To: , "idr@ietf.org" Message-ID: Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01, size and capability Thread-Index: Acvlf1DVjx1O0lFyEeCJTAAbY71bnA== In-Reply-To: <4D830D03.9070907@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Mar 2011 15:16:11.0633 (UTC) FILETIME=[6A3F4610:01CBE57F] Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01, size and capability 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, 18 Mar 2011 15:14:48 -0000 Robert, Comments inlined. #Keyur On 3/18/11 12:42 AM, "Robert Raszuk" wrote: > Hello, > > Many thx for everyone's opinion so far. This was exactly the point of my > question. Other people are welcome to express their opinion on the list > reg the below three points: > > *A* Since we do agree that sending malformed UPDATE message back to a > peer is a good thing what is really required is to make BGP UPDATE #Keyur: Malformed updates as sent today as well as part of notifications. They are truncated if required. > message smaller then any other message. How much smaller is debatable. > For Diagnostic Message type 15 it would be 19 bytes (min BGP message > size) + 12 (TLV header) so 31 extra octets would be needed. In the spec > today we make it to be on the safe side for any future TLVs and > recommend that Diag message is bigger then Update Msg of 128 octets. If > you think that there are valid reasons to recommend even smaller value I > have no opinion. > > *B* When defining any protocol's type or length (even going beyond > routing) utilizing all usable fields to the original intended value is > not to good of a practice. > > The bgp message length is encoded in 2 octets. That in dec is equal > 65535. Allowing max massage size of that value closes doors for future > extension. Value of 56535 should be reserved for future extension ! #Keyur: Umm future extensions wrt to message sizes? :) > > At most any BGP message size can be 65534. > > When BGP message size is 65535 it will have a special indication meaning > to just like what is known in IPv6 world an entity called "Next Header". > It will be fixed size by definition and would allow for including any > subsequent header when needed. Each atomic header format will not change > either. #Keyur: We can reserve 65535 value. However it would be best to have a new message type with its own length if you need to encap messages. That should achieve the same goal in a bit more cleaner way rather than looking at the message types. > > It will just allow flexible nesting of messages without any hard message > boundary. So while we are at extending BGP message size I hope we will > do it right. > > *C* I also agree with points that the capability should be symmetrical. > Otherwise it will not be possible to replay back the bigger message. #Keyur: If replay is required then capability should be exchanged both the ways. :) Regards, Keyur > I > am not sure I see a value of send/receive split here. What is defined in > the draft is implicit "receive" and this seems what matters. But I > should be sending bigger if I understand this capability from the peer > which for all practical purposes mean I can parse bigger message too ;-) > > Many thx, > R. > > >> The draft states: >>> All BGP extended messages have maximum message size of 65535 octets. >> Could we make that just a little shorter, perhaps 65000 or 64000. >> It would make implementation a little more efficient >> when storing it or shunting it around in the code with headers on it. >> -- >> Jakob Heitz. >> >> >> >> _______________________________________________ >> 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 jakob.heitz@ericsson.com Fri Mar 18 10:40: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 2D1713A69AF for ; Fri, 18 Mar 2011 10:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, 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 cdzBPEvAyN15 for ; Fri, 18 Mar 2011 10:40:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 431173A69AC for ; Fri, 18 Mar 2011 10:40:05 -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 p2IHfWUD023856; Fri, 18 Mar 2011 12:41:33 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 18 Mar 2011 13:41:29 -0400 From: Jakob Heitz To: Keyur Patel , "idr@ietf.org" Date: Fri, 18 Mar 2011 13:41:28 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01, size Thread-Index: AcvlDsRmxy7c92S8SY64zbEnEsZK+gAbzK5yAAVWZJA= Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909BA20D071@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@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: multipart/alternative; boundary="_000_7309FCBCAE981B43ABBE69B31C8D213909BA20D071EUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01, size 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, 18 Mar 2011 17:40:09 -0000 --_000_7309FCBCAE981B43ABBE69B31C8D213909BA20D071EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like to fit things nicely into memory pages. No big deal really. -- Jakob Heitz. ________________________________ From: Keyur Patel [mailto:keyupate@cisco.com] Sent: Friday, March 18, 2011 8:06 AM To: Jakob Heitz; idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01, size Hi Jakob, I am sorry I didn't get it. What sort of implementation optimizations are w= e talking about? Regards, Keyur On 3/17/11 5:49 PM, "Jakob Heitz" wrote: The draft states: > All BGP extended messages have maximum message size of 65535 octets. Could we make that just a little shorter, perhaps 65000 or 64000. It would make implementation a little more efficient when storing it or shunting it around in the code with headers on it. -- Jakob Heitz. ________________________________ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_7309FCBCAE981B43ABBE69B31C8D213909BA20D071EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Idr] draft-ymbk-bgp-extended-messages-01, size</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6002.18357" name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D701383817-18032011><FONT=20 face=3D"Lucida Console" color=3D#800080 size=3D2>I like to fit things nicel= y into=20 memory pages.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D701383817-18032011><FONT=20 face=3D"Lucida Console" color=3D#800080 size=3D2>No big deal=20 really.</FONT></SPAN></DIV><!-- Converted from text/rtf format --> <P><SPAN lang=3Den-us><FONT face=3DArial size=3D2>--</FONT></SPAN> <BR><SPA= N=20 lang=3Den-us><FONT face=3DArial size=3D2>Jakob Heitz.</FONT></SPAN></P> <DIV> </DIV><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800080 2px soli= d; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Keyur Patel [mailto:keyupate@ci= sco.com]=20 <BR><B>Sent:</B> Friday, March 18, 2011 8:06 AM<BR><B>To:</B> Jakob Heitz= ;=20 idr@ietf.org<BR><B>Subject:</B> Re: [Idr] draft-ymbk-bgp-extended-message= s-01,=20 size<BR></FONT><BR></DIV> <DIV></DIV><FONT face=3D"Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 12px">Hi Jakob,<BR><BR>I am sorry I didn’t get = it. What sort=20 of implementation optimizations are we talking=20 about?<BR><BR>Regards,<BR>Keyur<BR><BR><BR>On 3/17/11 5:49 PM, "Jakob Hei= tz"=20 <jakob.heitz@ericsson.com> wrote:<BR><BR></SPAN></FONT> <BLOCKQUOTE><SPAN style=3D"FONT-SIZE: 12px"><FONT color=3D#800080><FONT=20 face=3D"Lucida Console">The draft states:<BR>>   All BGP e= xtended=20 messages have maximum message size of 65535 octets.<BR> <BR>Could = we=20 make that just a little shorter, perhaps 65000 or 64000.<BR>It would ma= ke=20 implementation a little more efficient<BR>when storing it or shunting i= t=20 around in the code with headers on it.<BR> <BR></FONT></FONT><FONT= =20 face=3DArial>--<BR>Jakob Heitz.<BR><FONT=20 color=3D#800080><BR> <BR></FONT></FONT><FONT=20 face=3D"Verdana, Helvetica, Arial"><BR> <HR align=3Dcenter width=3D"95%" SIZE=3D3> </FONT></SPAN><FONT size=3D2><FONT face=3D"Monaco, Courier New"><SPAN=20 style=3D"FONT-SIZE: 10px">_____________________________________________= __<BR>Idr=20 mailing=20 list<BR>Idr@ietf.org<BR>https://www.ietf.org/mailman/listinfo/idr<BR></= SPAN></FONT></FONT></BLOCKQUOTE><FONT=20 size=3D2><FONT face=3D"Monaco, Courier New"><SPAN=20 style=3D"FONT-SIZE: 10px"><BR></BLOCKQUOTE></SPAN></FONT></FONT></BODY></HT= ML> --_000_7309FCBCAE981B43ABBE69B31C8D213909BA20D071EUSAACMS0701e_-- From jgs@juniper.net Fri Mar 18 11:45:29 2011 Return-Path: <jgs@juniper.net> 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 AFE9A3A69D0 for <idr@core3.amsl.com>; Fri, 18 Mar 2011 11:45:29 -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 XJFlRpqZB0Nr for <idr@core3.amsl.com>; Fri, 18 Mar 2011 11:45:29 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id C571B3A69B7 for <idr@ietf.org>; Fri, 18 Mar 2011 11:45:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTYOook/atjL7X+tUFDCJ0Aj32mQwvwn6@postini.com; Fri, 18 Mar 2011 11:46:58 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, 18 Mar 2011 11:41:48 -0700 From: John Scudder <jgs@juniper.net> To: "idr@ietf.org List" <idr@ietf.org> Date: Fri, 18 Mar 2011 11:42:57 -0700 Thread-Topic: [Idr] IDR agenda for IETF-80 Thread-Index: AcvlnCNixMm20b2xSEKVs99lTxPdKQ== Message-ID: <A223FB65-0575-443B-8C4E-8E4C2AF06C51@juniper.net> References: <2C615A8A-28A9-4E00-9182-5BC6C188A053@juniper.net> In-Reply-To: <2C615A8A-28A9-4E00-9182-5BC6C188A053@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] IDR agenda for IETF-80 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Mar 2011 18:45:29 -0000 Agenda updated to correct an omission. --John On Mar 17, 2011, at 6:02 PM, John Scudder wrote: > Agenda has been posted: >=20 > http://www.ietf.org/proceedings/80/agenda/idr.txt >=20 > It is still subject to change although I don't anticipate any big changes= . =20 >=20 > --John From enkechen@cisco.com Fri Mar 18 14:31:15 2011 Return-Path: <enkechen@cisco.com> 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 8CB2C3A6A28 for <idr@core3.amsl.com>; Fri, 18 Mar 2011 14:31:15 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKRqZyfaMvUg for <idr@core3.amsl.com>; Fri, 18 Mar 2011 14:31:14 -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 86EBF3A68FE for <idr@ietf.org>; Fri, 18 Mar 2011 14:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=2046; q=dns/txt; s=iport; t=1300483964; x=1301693564; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=idN1CerYzN2Dw2yRGRSqxEE9WmwB7LTQBxruZRMl6rE=; b=EHrV6CJD2qELfGLDAbN0fgLY9wxADjr80cHrgrSj3WEmQHZJ1O8ECSsG EUNHnj3l81gjhBV8RQ8CYuejWXfkhZoykXumvjEHppUi7WRU3GEofJMfv SmlhwodlyH2iH0aN+9QNCzKbZmUBekVBvipqNDW6q+PtUaDViU70IpYuZ E=; X-IronPort-AV: E=Sophos;i="4.63,207,1299456000"; d="scan'208";a="226999003" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2011 21:32:43 +0000 Received: from dhcp-171-71-139-27.cisco.com (dhcp-171-71-139-27.cisco.com [171.71.139.27]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2ILWhVx003033; Fri, 18 Mar 2011 21:32:43 GMT Message-ID: <4D83D02D.7070302@cisco.com> Date: Fri, 18 Mar 2011 14:35:41 -0700 From: Enke Chen <enkechen@cisco.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Lightning/1.0b1 Thunderbird/3.0.11 MIME-Version: 1.0 To: Keyur Patel <keyupate@cisco.com> References: <C9A8C286.1AC5C%keyupate@cisco.com> In-Reply-To: <C9A8C286.1AC5C%keyupate@cisco.com> 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 (capability code) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Mar 2011 21:31:15 -0000 Hi, folks: How about adding the some text to reconcile the possible size differences between an original message and any feedback messages: ---------------------------------- In order for a BGP speaker to be able to receive a notification or some other diagnostic message containing an original BGP message sent by the speaker, it is RECOMMEND that a BGP speaker limit the size to (65535 - 4096) for messages that it sends to a peer that has advertised the capability. --------------------------------- Regards, -- Enke On 3/18/11 8:04 AM, Keyur Patel wrote: > Ilya, > > I am not sure what we would gain by having "send" and "receive" flags. All > you need to know is if your peer is capable of receiving longer messages or > not so as to not drop the session! > > Regards, > Keyur > > > On 3/17/11 4:34 AM, "iLya"<ilya@nobulus.com> wrote: > > >> -------------------------------------------------- >> >>> Title : Extended Message support for BGP >>> http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01 >>> >>> >> Section 2 reads: "...This is an asymmetric capability. I.e. one speaker >> could signal the capability and the other not..". >> >> If one side does not signal capability then it may not prepared to receive >> messages longer than original specification dictates. In other words, even >> for asymmetric flow of big (>4096) messages both sides need to have support >> and announce that. Perhaps having 'receive' and 'send' flags in capability >> value and requiring each side to advertise new capability would be better >> approach than sending big messages to a speaker that didn't advertise >> 'extended messages' capability. >> >> Kind regards, >> iLya >> >> _______________________________________________ >> 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 Fri Mar 18 14:47:12 2011 Return-Path: <keyupate@cisco.com> 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 72FC63A6A4D for <idr@core3.amsl.com>; Fri, 18 Mar 2011 14:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.366 X-Spam-Level: X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 40cuLVWx9b3B for <idr@core3.amsl.com>; Fri, 18 Mar 2011 14:47:11 -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 58ADC3A6A2E for <idr@ietf.org>; Fri, 18 Mar 2011 14:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=2414; q=dns/txt; s=iport; t=1300484921; x=1301694521; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=ud3yFxOVhdXzmpdB/b6Er9ZbzUq34iYzmGk1s1JyZDM=; b=TKrORZpbKuqz3wEjjaOSuoq6uoqM4Zo3YHuQkp4Ab19jQPeYlkJMgMMC HHp113OTflVpUmmiFlYah+9VAX6YK1Acz7trMBD8BwVuHY2azhaWWqgOX i8DYQpbVQasQ0vts/+jj2Lh/TkIPlT8hvacnTAEdQX8G7AFPcK6l/rHUg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALxvg02tJXHA/2dsb2JhbAClcneITZ87nBSFYwSFMYcyg1U X-IronPort-AV: E=Sophos;i="4.63,207,1299456000"; d="scan'208";a="321984771" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2011 21:48:41 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2ILmZ43018614 for <idr@ietf.org>; Fri, 18 Mar 2011 21:48:40 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, 18 Mar 2011 14:48:39 -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.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 Mar 2011 21:48:39 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 18 Mar 2011 14:47:57 -0700 From: Keyur Patel <keyupate@cisco.com> To: Enke Chen <enkechen@cisco.com> Message-ID: <C9A9211D.1AD79%keyupate@cisco.com> Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) Thread-Index: AcvltiSJYy0nSFGpEeCJTAAbY71bnA== In-Reply-To: <4D83D02D.7070302@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Mar 2011 21:48:39.0491 (UTC) FILETIME=[3DDD4130:01CBE5B6] Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Mar 2011 21:47:12 -0000 Enke, Most definitely! This should cover Diagnostic message and any other message types that would require some kind of feedback mechanism back to the BGP speaker that originated the message. Regards, Keyur On 3/18/11 2:35 PM, "Enke Chen" <enkechen@cisco.com> wrote: > Hi, folks: > > How about adding the some text to reconcile the possible size > differences between an original message and any feedback messages: > > ---------------------------------- > In order for a BGP speaker to be able to receive a notification or some > other diagnostic message > containing an original BGP message sent by the speaker, it is RECOMMEND > that a BGP speaker > limit the size to (65535 - 4096) for messages that it sends to a peer > that has advertised the capability. > --------------------------------- > > Regards, -- Enke > > On 3/18/11 8:04 AM, Keyur Patel wrote: >> Ilya, >> >> I am not sure what we would gain by having "send" and "receive" flags. All >> you need to know is if your peer is capable of receiving longer messages or >> not so as to not drop the session! >> >> Regards, >> Keyur >> >> >> On 3/17/11 4:34 AM, "iLya"<ilya@nobulus.com> wrote: >> >> >>> -------------------------------------------------- >>> >>>> Title : Extended Message support for BGP >>>> http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01 >>>> >>>> >>> Section 2 reads: "...This is an asymmetric capability. I.e. one speaker >>> could signal the capability and the other not..". >>> >>> If one side does not signal capability then it may not prepared to receive >>> messages longer than original specification dictates. In other words, even >>> for asymmetric flow of big (>4096) messages both sides need to have support >>> and announce that. Perhaps having 'receive' and 'send' flags in capability >>> value and requiring each side to advertise new capability would be better >>> approach than sending big messages to a speaker that didn't advertise >>> 'extended messages' capability. >>> >>> Kind regards, >>> iLya >>> >>> _______________________________________________ >>> 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 jeff.tantsura@ericsson.com Fri Mar 18 15:08:45 2011 Return-Path: <jeff.tantsura@ericsson.com> 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 CDE3D3A6A6D for <idr@core3.amsl.com>; Fri, 18 Mar 2011 15:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[AWL=1.730, 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 h+tz64z4Fbc3 for <idr@core3.amsl.com>; Fri, 18 Mar 2011 15:08:44 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 586643A6A53 for <idr@ietf.org>; Fri, 18 Mar 2011 15:08:44 -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 p2IMAC0X032709; Fri, 18 Mar 2011 17:10:13 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 18 Mar 2011 18:10:05 -0400 From: Jeff Tantsura <jeff.tantsura@ericsson.com> To: Enke Chen <enkechen@cisco.com>, Keyur Patel <keyupate@cisco.com> Date: Fri, 18 Mar 2011 18:10:04 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) Thread-Index: AcvltBVYQeyS+wZRSIOzUdMrE0jAMQABRrcg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60AA21C50E2@EUSAACMS0701.eamcs.ericsson.se> References: <C9A8C286.1AC5C%keyupate@cisco.com> <4D83D02D.7070302@cisco.com> In-Reply-To: <4D83D02D.7070302@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" <idr@ietf.org> Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 18 Mar 2011 22:08:45 -0000 +1 Regards, Jeff =20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke = Chen Sent: Friday, March 18, 2011 14:36 To: Keyur Patel Cc: idr@ietf.org Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code) Hi, folks: How about adding the some text to reconcile the possible size=20 differences between an original message and any feedback messages: ---------------------------------- In order for a BGP speaker to be able to receive a notification or some=20 other diagnostic message containing an original BGP message sent by the speaker, it is RECOMMEND=20 that a BGP speaker limit the size to (65535 - 4096) for messages that it sends to a peer=20 that has advertised the capability. --------------------------------- Regards, -- Enke On 3/18/11 8:04 AM, Keyur Patel wrote: > Ilya, > > I am not sure what we would gain by having "send" and "receive" flags. Al= l > you need to know is if your peer is capable of receiving longer messages = or > not so as to not drop the session! > > Regards, > Keyur > > > On 3/17/11 4:34 AM, "iLya"<ilya@nobulus.com> wrote: > > =20 >> -------------------------------------------------- >> =20 >>> Title : Extended Message support for BGP >>> http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01 >>> >>> =20 >> Section 2 reads: "...This is an asymmetric capability. I.e. one speaker >> could signal the capability and the other not..". >> >> If one side does not signal capability then it may not prepared to recei= ve >> messages longer than original specification dictates. In other words, ev= en >> for asymmetric flow of big (>4096) messages both sides need to have supp= ort >> and announce that. Perhaps having 'receive' and 'send' flags in capabili= ty >> value and requiring each side to advertise new capability would be bette= r >> approach than sending big messages to a speaker that didn't advertise >> 'extended messages' capability. >> >> Kind regards, >> iLya >> >> _______________________________________________ >> 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From ray.saikat@ericsson.com Sun Mar 20 17:06:47 2011 Return-Path: <ray.saikat@ericsson.com> 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 6FC0F28C10A for <idr@core3.amsl.com>; Sun, 20 Mar 2011 17:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.044 X-Spam-Level: X-Spam-Status: No, score=-4.044 tagged_above=-999 required=5 tests=[AWL=2.555, 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 Go2ylpa5ijmv for <idr@core3.amsl.com>; Sun, 20 Mar 2011 17:06:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 794D728C100 for <idr@ietf.org>; Sun, 20 Mar 2011 17:06:46 -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 p2L08HUO008128 for <idr@ietf.org>; Sun, 20 Mar 2011 19:08:18 -0500 Received: from [155.53.129.97] (147.117.20.213) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.3.137.0; Sun, 20 Mar 2011 20:08:11 -0400 Message-ID: <4D8696EB.8030702@ericsson.com> Date: Sun, 20 Mar 2011 17:08:11 -0700 From: Saikat Ray <ray.saikat@ericsson.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: idr@ietf.org References: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] draft-ietf-idr-best-external-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Mar 2011 00:06:47 -0000 Hi All: I am seeking clarifications on the draft with respect to the proposed behavior of an RR (and Confed ASBR). ================ 1. A path from a non-client internal peer is considered "external". Is such a path considered a "path received via EBGP" in the step [9.1.2.2(d); RFC 4271] in overall (or "best internal" or "best external") bestpath computation? 2. Is there an assumption that an RR does not have a true eBGP peer? If an RR is allowed to have true EBGP peers: 3. Does the RR always send the overall-bestpath to a true EBGP peer? 4. If the overall-bestpath is a true EBGP path, is it sent to both RR clients and RR non-clients? 5. If the overall bestpath is an internal path received from an RR-client peer, does the "best external" path computation include true EBGP paths in its set of "external" paths? 6. If the overall bestpath is an internal path received from a non-client internal peer, does the "best internal" path computation include true EBGP paths in its set of "internal" paths (as the true EBGP paths are external to the set of non-client peers)? 7. Is there an assumption that RR's in the AS are fully meshed (no hierarchical RR)? 8. Is there an assumption that Confed ASBR's are fully meshed? If Confed ASBR's may not be fully meshed, then 9. Suppose we have three member AS - 1, 2, 3 - in a confederation; ASBRi is the Confed ASBR of member-AS i. At ASBR1, the path from ASBR2 is the overall-bestpath. Does ASBR1 send the overall bestpath to ASBR3 or does ASBR1 send the "best internal" path to ASBR3? Also does the computation for "best internal" path, that ASBR1 sends to ASBR2, include paths from ASBR3 in its set of "internal" paths? ================ The current draft language is open to interpretations. The previous drafts that seem to be basis of the current one also do not clarify the above points. http://tools.ietf.org/id/draft-chen-confed-oscillation-reduce-01.txt http://tools.ietf.org/id/draft-chen-rr-oscillation-reduce-01.txt http://tools.ietf.org/id/draft-chen-route-oscillation-avoid-00.txt Any pointers will be appreciated. Thanks. From pedro.r.marques@gmail.com Mon Mar 21 11:38:35 2011 Return-Path: <pedro.r.marques@gmail.com> 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 443A83A67ED for <idr@core3.amsl.com>; Mon, 21 Mar 2011 11:38:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8X99rzLU52t for <idr@core3.amsl.com>; Mon, 21 Mar 2011 11:38:34 -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 4213E3A67B5 for <idr@ietf.org>; Mon, 21 Mar 2011 11:38:34 -0700 (PDT) Received: by iyi12 with SMTP id 12so7777172iyi.31 for <idr@ietf.org>; Mon, 21 Mar 2011 11:40:06 -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=gwD9yoYxIQ13ufacBiRqPVznhTz7bk6224jDP132/OM=; b=guMtAx3vRDvt0aKrIXB1cqWDZyS4lC2XbYQc3QgbwZPRY1skXIPC/NJ5lITswJVbCo HxXnRE3t+A4SP1zmrhPHb29kMgq8aQVW92oAhd759q2brH3DF4Zrb2xt2eRnuvPLGPQP tqFpbgYhdG4b7hFs+kE8bQYE+JEwPfoZuqnGM= 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=l7QSt+XlHYHAG9+CdswqIhBpO1muVsT+GdawhYaOXKBab+38zzDvGXszR1jxzWSSS7 FnrkN1jwPJvFGs+Vpxcg05RKMud3ccWNiginzVeZ6nhStBz+1s/3RhWDcGXctGJPg8Qn SAGEJWc+aaQXJ5cHS2Q0pQuNqk4IeUhJRmol0= MIME-Version: 1.0 Received: by 10.43.54.200 with SMTP id vv8mr7326451icb.378.1300732806861; Mon, 21 Mar 2011 11:40:06 -0700 (PDT) Received: by 10.42.172.134 with HTTP; Mon, 21 Mar 2011 11:40:06 -0700 (PDT) In-Reply-To: <4D8696EB.8030702@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@EUSAACMS0701.eamcs.ericsson.se> <4D8696EB.8030702@ericsson.com> Date: Mon, 21 Mar 2011 11:40:06 -0700 Message-ID: <AANLkTin=g2wQxEOTnz5fU_u=t3asSSh=nU-8q=c6TV+T@mail.gmail.com> From: Pedro Marques <pedro.r.marques@gmail.com> To: Saikat Ray <ray.saikat@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-best-external-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Mar 2011 18:38:35 -0000 Saikat, On Sun, Mar 20, 2011 at 5:08 PM, Saikat Ray <ray.saikat@ericsson.com> wrote: > Hi All: > > I am seeking clarifications on the draft with respect to the proposed > behavior of an RR (and Confed ASBR). > > ================ > 1. A path from a non-client internal peer is considered "external". Is such > a path considered a "path received via EBGP" in the step [9.1.2.2(d); RFC > 4271] in overall (or "best internal" or "best external") bestpath > computation? A path received from a non-client peer is an IBGP path; thus not an EBGP path. > > 2. Is there an assumption that an RR does not have a true eBGP peer? No. RRs may have EBGP peers. The best-external doc modifies the behavior of an RR such that when an RR selects an IBGP path from another cluster it will also advertise out of the cluster its best cluster local route (including direct eBGP routes) rather than the current behavior of not advertising any information. > > If an RR is allowed to have true EBGP peers: > 3. Does the RR always send the overall-bestpath to a true EBGP peer? Yes. > > 4. If the overall-bestpath is a true EBGP path, is it sent to both RR > clients and RR non-clients? Yes. No modification in that behavior. > > 5. If the overall bestpath is an internal path received from an RR-client > peer, does the "best external" path computation include true EBGP paths in > its set of "external" paths? An EBGP path is considered to be local to the cluster; it was not received from an IBGP peer. > > 6. If the overall bestpath is an internal path received from a non-client > internal peer, does the "best internal" path computation include true EBGP > paths in its set of "internal" paths (as the true EBGP paths are external to > the set of non-client peers)? Yes. > > 7. Is there an assumption that RR's in the AS are fully meshed (no > hierarchical RR)? No. > > 8. Is there an assumption that Confed ASBR's are fully meshed? No. > If Confed ASBR's may not be fully meshed, then > 9. Suppose we have three member AS - 1, 2, 3 - in a confederation; ASBRi is > the Confed ASBR of member-AS i. > At ASBR1, the path from ASBR2 is the overall-bestpath. Does ASBR1 send the > overall bestpath to ASBR3 or does ASBR1 send the "best internal" path to > ASBR3? The best overall. > Also does the computation for "best internal" path, that ASBR1 sends > to ASBR2, include paths from ASBR3 in its set of "internal" paths? > ================ > > The current draft language is open to interpretations. The previous drafts > that seem to be basis of the current one also do not clarify the above > points. Would the document be clearer if one where to use the terms "intra-cluster" and "inter-cluster" route ? Pedro. From ray.saikat@ericsson.com Mon Mar 21 17:14:17 2011 Return-Path: <ray.saikat@ericsson.com> 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 A003928C1B8 for <idr@core3.amsl.com>; Mon, 21 Mar 2011 17:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.596 X-Spam-Level: X-Spam-Status: No, score=-4.596 tagged_above=-999 required=5 tests=[AWL=1.403, BAYES_00=-2.599, J_CHICKENPOX_26=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 2LWq-enV285f for <idr@core3.amsl.com>; Mon, 21 Mar 2011 17:14:16 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 9777A28C1B0 for <idr@ietf.org>; Mon, 21 Mar 2011 17:14:16 -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 p2M0Fb6O008272; Mon, 21 Mar 2011 19:15:46 -0500 Received: from [155.53.129.97] (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.3.137.0; Mon, 21 Mar 2011 20:15:41 -0400 Message-ID: <4D87EA2D.106@ericsson.com> Date: Mon, 21 Mar 2011 17:15:41 -0700 From: Saikat Ray <ray.saikat@ericsson.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Pedro Marques <pedro.r.marques@gmail.com> References: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@EUSAACMS0701.eamcs.ericsson.se> <4D8696EB.8030702@ericsson.com> <AANLkTin=g2wQxEOTnz5fU_u=t3asSSh=nU-8q=c6TV+T@mail.gmail.com> In-Reply-To: <AANLkTin=g2wQxEOTnz5fU_u=t3asSSh=nU-8q=c6TV+T@mail.gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" <idr@ietf.org> Subject: Re: [Idr] draft-ietf-idr-best-external-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 00:14:17 -0000 Hi Pedro: Thanks much for the response. It clears things up a lot. Could you please also answer the one question you missed ... 9. Suppose we have three member AS - 1, 2, 3 - in a confederation; ASBRi is the Confed ASBR of member-AS i. At ASBR1, the path from ASBR2 is the overall-bestpath. Does the computation for "best internal" path, that ASBR1 sends to ASBR2, include paths from ASBR3 in its set of "internal" paths? I think the document should define the terms it is using more clearly. Even terms like "AS Domain" and "RR Domain" are open to interpretations. E.g., a RR can have true EBGP peers. Then is it in an AS Domain or is it in an RR Domain? Maybe the best thing would be to have a paragraph in the appendix that describes the task of a given BGP speaker considering the full set of paths and all possible types of peers that can co-exist. E.g., a BGP speaker can have: (i) true EBGP peers, (ii) RR-client peers, (iii) non-client IBGP peers, (iv) member-AS IBGP peers, (v) non-member-AS confed EBGP peers. All such peers can co-exist (when the BGP speaker is both an RR and a Confed ASBR). If the behavior is undefined in some cases (e.g., RR+Confed ASBR combination), then that should be said. The total set of paths are divided similarly based on the peer that sends the path. Then the paragraph would describe, given the overall bestpath lies in set 'k', which path the BGP speaker sends to a peer in set 'j'. For non-overall-bestpath, e.g., denoting the set of true EBGP paths as 'E' and the set of RR-client paths as 'R', a notation like 'best(E U R)' may be clearer than calling it "internal". With regards, Saikat On 03/21/2011 11:40 AM, Pedro Marques wrote: > Saikat, > > On Sun, Mar 20, 2011 at 5:08 PM, Saikat Ray<ray.saikat@ericsson.com> wrote: >> Hi All: >> >> I am seeking clarifications on the draft with respect to the proposed >> behavior of an RR (and Confed ASBR). >> >> ================ >> 1. A path from a non-client internal peer is considered "external". Is such >> a path considered a "path received via EBGP" in the step [9.1.2.2(d); RFC >> 4271] in overall (or "best internal" or "best external") bestpath >> computation? > A path received from a non-client peer is an IBGP path; thus not an EBGP path. > >> 2. Is there an assumption that an RR does not have a true eBGP peer? > No. RRs may have EBGP peers. > > The best-external doc modifies the behavior of an RR such that when an > RR selects an IBGP path from another cluster it will also advertise > out of the cluster its best cluster local route (including direct eBGP > routes) rather than the current behavior of not advertising any > information. > >> If an RR is allowed to have true EBGP peers: >> 3. Does the RR always send the overall-bestpath to a true EBGP peer? > Yes. > >> 4. If the overall-bestpath is a true EBGP path, is it sent to both RR >> clients and RR non-clients? > Yes. No modification in that behavior. > >> 5. If the overall bestpath is an internal path received from an RR-client >> peer, does the "best external" path computation include true EBGP paths in >> its set of "external" paths? > An EBGP path is considered to be local to the cluster; it was not > received from an IBGP peer. > >> 6. If the overall bestpath is an internal path received from a non-client >> internal peer, does the "best internal" path computation include true EBGP >> paths in its set of "internal" paths (as the true EBGP paths are external to >> the set of non-client peers)? > Yes. > >> 7. Is there an assumption that RR's in the AS are fully meshed (no >> hierarchical RR)? > No. > >> 8. Is there an assumption that Confed ASBR's are fully meshed? > No. > >> If Confed ASBR's may not be fully meshed, then >> 9. Suppose we have three member AS - 1, 2, 3 - in a confederation; ASBRi is >> the Confed ASBR of member-AS i. >> At ASBR1, the path from ASBR2 is the overall-bestpath. Does ASBR1 send the >> overall bestpath to ASBR3 or does ASBR1 send the "best internal" path to >> ASBR3? > The best overall. > >> Also does the computation for "best internal" path, that ASBR1 sends >> to ASBR2, include paths from ASBR3 in its set of "internal" paths? >> ================ >> >> The current draft language is open to interpretations. The previous drafts >> that seem to be basis of the current one also do not clarify the above >> points. > > Would the document be clearer if one where to use the terms > "intra-cluster" and "inter-cluster" route ? > > Pedro. > From pedro.r.marques@gmail.com Mon Mar 21 18:46:16 2011 Return-Path: <pedro.r.marques@gmail.com> 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 56E2128C1A0 for <idr@core3.amsl.com>; Mon, 21 Mar 2011 18:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, 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 f9JdT0Si-WL4 for <idr@core3.amsl.com>; Mon, 21 Mar 2011 18:46:15 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 750AC3A6910 for <idr@ietf.org>; Mon, 21 Mar 2011 18:46:15 -0700 (PDT) Received: by iwl42 with SMTP id 42so8201988iwl.31 for <idr@ietf.org>; Mon, 21 Mar 2011 18:47:48 -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=joCc2NeQr1xSA16x4NITyNJtOobXmzZM4Ge6aTEZDyc=; b=eAb3fxuJklM2Tk2U82zAsp7V95flGOxrcN8wjprbgQdXnpSWyNjm0jNBK4l/nkg0oi yXpGCkB40gE9ca4CV9wvNQukNoyNGoMtYWB/x9ScvjKQ0+sptErnaFFXfosl5STagmmT QXu6dO2rTDIp3NdIAmQjzIylf5t/IKduZ9xGI= 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=cJpTjIagMkwKHGrtxDeCMjkEq+RNpoQg3edPs8s8KGgun954EEdyseilZzNHW5/3Uy laUImJOMipttKDKO3D+3eQGrGv9/nJZu4JEmUK6DoAuKTvQTL1PRgefNa0/WTljFijgY 9KSO4W0ffKDH7aQE2Z2z8mzDb/u+l3eWcmVcE= MIME-Version: 1.0 Received: by 10.42.37.199 with SMTP id z7mr4884706icd.110.1300758468119; Mon, 21 Mar 2011 18:47:48 -0700 (PDT) Received: by 10.42.172.134 with HTTP; Mon, 21 Mar 2011 18:47:48 -0700 (PDT) In-Reply-To: <4D87EA2D.106@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@EUSAACMS0701.eamcs.ericsson.se> <4D8696EB.8030702@ericsson.com> <AANLkTin=g2wQxEOTnz5fU_u=t3asSSh=nU-8q=c6TV+T@mail.gmail.com> <4D87EA2D.106@ericsson.com> Date: Mon, 21 Mar 2011 18:47:48 -0700 Message-ID: <AANLkTi=N6NQbaxG13KxE3fj0r5D+n=F=7voEpxckHNCA@mail.gmail.com> From: Pedro Marques <pedro.r.marques@gmail.com> To: Saikat Ray <ray.saikat@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org" <idr@ietf.org> Subject: Re: [Idr] draft-ietf-idr-best-external-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 01:46:16 -0000 Saikat, On Mon, Mar 21, 2011 at 5:15 PM, Saikat Ray <ray.saikat@ericsson.com> wrote= : > Hi Pedro: > > Thanks much for the response. It clears things up a lot. Could you please > also answer the one question you missed ... > > =A0 9. Suppose we have three member AS - 1, 2, 3 - in a confederation; > =A0 =A0 =A0ASBRi is the Confed ASBR of member-AS i. At ASBR1, the path fr= om > =A0 =A0 =A0ASBR2 is the overall-bestpath. > =A0 =A0 =A0 =A0 =A0 =A0Does the computation for "best internal" path, tha= t ASBR1 > =A0 =A0 =A0 =A0 =A0 =A0sends to ASBR2, include paths from ASBR3 in its se= t of > =A0 =A0 =A0 =A0 =A0 =A0"internal" paths? Yes. In this scenario, when ASBR1 generates an update to ASBR2 it is selecting the best of all its known paths that where not received from member AS 2. The same rule applies for route reflection. Consider the top level iBGP mesh to be cluster-id 0; When advertising to a specific set of peers, "best-external" selects the best route from the set of known routes that has not been received from the same cluster-id as the "target". > > I think the document should define the terms it is using more clearly. I agree. > Even > terms like "AS Domain" and "RR Domain" are open to interpretations. E.g.,= a > RR can have true EBGP peers. Then is it in an AS Domain or is it in an RR > Domain? Maybe the best thing would be to have a paragraph in the appendix > that describes the task of a given BGP speaker considering the full set o= f > paths and all possible types of peers that can co-exist. E.g., a BGP spea= ker > can have: (i) true EBGP peers, (ii) RR-client peers, (iii) non-client IBG= P > peers, (iv) member-AS IBGP peers, (v) non-member-AS confed EBGP peers. Al= l > such peers can co-exist (when the BGP speaker is both an RR and a Confed > ASBR). If the behavior is undefined in some cases (e.g., RR+Confed ASBR > combination), then that should be said. The behavior is easy to define in pseudo-code: eligible-routes =3D RIB-In routes Excluding { cluster-id and confed-as of peer } select the best of eligible routes. Assuming that cluster-id of a non-client peer is 0; confed-as of non confed eibgp peer is 0. I agree with you. The existing text sort of mumbles it all together. Pedro. From jakob.heitz@ericsson.com Mon Mar 21 19:39:01 2011 Return-Path: <jakob.heitz@ericsson.com> 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 795FD28C0F7 for <idr@core3.amsl.com>; Mon, 21 Mar 2011 19:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.965 X-Spam-Level: X-Spam-Status: No, score=-4.965 tagged_above=-999 required=5 tests=[AWL=1.034, BAYES_00=-2.599, J_CHICKENPOX_26=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 gKf-+fB1t3Qa for <idr@core3.amsl.com>; Mon, 21 Mar 2011 19:39:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 6F68E28C0DC for <idr@ietf.org>; Mon, 21 Mar 2011 19:38: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 p2M2eRH8014749; Mon, 21 Mar 2011 21:40:28 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.192]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 21 Mar 2011 22:40:21 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: Pedro Marques <pedro.r.marques@gmail.com> Date: Mon, 21 Mar 2011 22:40:20 -0400 Thread-Topic: [Idr] draft-ietf-idr-best-external-03 Thread-Index: AcvoMzEwxnI157WBRQGL2fgZSxioVgABgfOQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909BD36535C@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@EUSAACMS0701.eamcs.ericsson.se> <4D8696EB.8030702@ericsson.com> <AANLkTin=g2wQxEOTnz5fU_u=t3asSSh=nU-8q=c6TV+T@mail.gmail.com> <4D87EA2D.106@ericsson.com> <AANLkTi=N6NQbaxG13KxE3fj0r5D+n=F=7voEpxckHNCA@mail.gmail.com> In-Reply-To: <AANLkTi=N6NQbaxG13KxE3fj0r5D+n=F=7voEpxckHNCA@mail.gmail.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" <idr@ietf.org> Subject: Re: [Idr] draft-ietf-idr-best-external-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 02:39:01 -0000 Pedro, Suppose 3 RR clusters in an AS. Overall bestpath is in cluster 2. Cluster 1 will calculate the best-external to send to cluster 2. He will use the paths from cluster 3 and cluster 1 to calculate the best external. If the best from that set is in cluster 3, he will send nothing to cluster 2. Is that right? -- Jakob Heitz. 510-566-2901 =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Pedro Marques > Sent: Monday, March 21, 2011 6:48 PM > To: Ray Saikat > Cc: idr@ietf.org > Subject: Re: [Idr] draft-ietf-idr-best-external-03 >=20 > Saikat, >=20 > On Mon, Mar 21, 2011 at 5:15 PM, Saikat Ray=20 > <ray.saikat@ericsson.com> wrote: > > Hi Pedro: > > > > Thanks much for the response. It clears things up a lot.=20 > Could you please > > also answer the one question you missed ... > > > > =A0 9. Suppose we have three member AS - 1, 2, 3 - in a confederation; > > =A0 =A0 =A0ASBRi is the Confed ASBR of member-AS i. At ASBR1, the=20 > path from > > =A0 =A0 =A0ASBR2 is the overall-bestpath. > > =A0 =A0 =A0 =A0 =A0 =A0Does the computation for "best internal" path, t= hat ASBR1 > > =A0 =A0 =A0 =A0 =A0 =A0sends to ASBR2, include paths from ASBR3 in its = set of > > =A0 =A0 =A0 =A0 =A0 =A0"internal" paths? >=20 > Yes. In this scenario, when ASBR1 generates an update to ASBR2 it is > selecting the best of all its known paths that where not received from > member AS 2. >=20 > The same rule applies for route reflection. Consider the top level > iBGP mesh to be cluster-id 0; When advertising to a specific set of > peers, "best-external" selects the best route from the set of known > routes that has not been received from the same cluster-id as the > "target". >=20 > > > > I think the document should define the terms it is using=20 > more clearly. >=20 > I agree. >=20 > > Even > > terms like "AS Domain" and "RR Domain" are open to=20 > interpretations. E.g., a > > RR can have true EBGP peers. Then is it in an AS Domain or=20 > is it in an RR > > Domain? Maybe the best thing would be to have a paragraph=20 > in the appendix > > that describes the task of a given BGP speaker considering=20 > the full set of > > paths and all possible types of peers that can co-exist.=20 > E.g., a BGP speaker > > can have: (i) true EBGP peers, (ii) RR-client peers, (iii)=20 > non-client IBGP > > peers, (iv) member-AS IBGP peers, (v) non-member-AS confed=20 > EBGP peers. All > > such peers can co-exist (when the BGP speaker is both an RR=20 > and a Confed > > ASBR). If the behavior is undefined in some cases (e.g.,=20 > RR+Confed ASBR > > combination), then that should be said. >=20 > The behavior is easy to define in pseudo-code: > eligible-routes =3D RIB-In routes Excluding { cluster-id and > confed-as of peer } > select the best of eligible routes. >=20 > Assuming that cluster-id of a non-client peer is 0; confed-as of non > confed eibgp peer is 0. >=20 > I agree with you. The existing text sort of mumbles it all together. >=20 > Pedro. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From pedro.r.marques@gmail.com Mon Mar 21 22:28:42 2011 Return-Path: <pedro.r.marques@gmail.com> 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 064A33A672F for <idr@core3.amsl.com>; Mon, 21 Mar 2011 22:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, 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 POCC4YrwAvar for <idr@core3.amsl.com>; Mon, 21 Mar 2011 22:28:37 -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 6C4D53A65A5 for <idr@ietf.org>; Mon, 21 Mar 2011 22:28:37 -0700 (PDT) Received: by iyi12 with SMTP id 12so8280376iyi.31 for <idr@ietf.org>; Mon, 21 Mar 2011 22:30:09 -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=qhLxbHD8Rf1ZtFvqs9F/MWXm+C5bVG+AAos/QBbnGL4=; b=tRkVokJqEqAb7otrjnNqpAilkqoiDqAO7pcy70smXWhKa3+W4moBbdzpBLd12LdeJP r2en71EaFIA6bubV+JVg31RhhigB5K0a0SREEXxSCZRB8lsUlO8q/85CfQBANKmvQxIX 1LOF24nnF6sltlCD6x7RjtdcptLqK8mCbfiME= 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=kP1vSx/wQvDwLhOfKU4VPHymJbsYbIKHTXHO//ensojwVGw79sh26+XUMN0jOuunD6 PtIvtOfQfS4JvjA4R57whLhzjduliJdhDH+WrweyZU3S6XB7rypquqm9to5o6jP1T3vX G9h6/BxjVGGuwQmDHROqcagn3H6XRBv7oAj5g= MIME-Version: 1.0 Received: by 10.43.134.4 with SMTP id ia4mr5917108icc.445.1300771808154; Mon, 21 Mar 2011 22:30:08 -0700 (PDT) Received: by 10.42.172.134 with HTTP; Mon, 21 Mar 2011 22:30:08 -0700 (PDT) In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909BD36535C@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D213909BA20CDB9@EUSAACMS0701.eamcs.ericsson.se> <4D8696EB.8030702@ericsson.com> <AANLkTin=g2wQxEOTnz5fU_u=t3asSSh=nU-8q=c6TV+T@mail.gmail.com> <4D87EA2D.106@ericsson.com> <AANLkTi=N6NQbaxG13KxE3fj0r5D+n=F=7voEpxckHNCA@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D213909BD36535C@EUSAACMS0701.eamcs.ericsson.se> Date: Mon, 21 Mar 2011 22:30:08 -0700 Message-ID: <AANLkTindn_LcDN-WV6Et9h5hLUY7idRKS4C7QERGg7Cw@mail.gmail.com> From: Pedro Marques <pedro.r.marques@gmail.com> To: Jakob Heitz <jakob.heitz@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org" <idr@ietf.org> Subject: Re: [Idr] draft-ietf-idr-best-external-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 05:28:42 -0000 On Mon, Mar 21, 2011 at 7:40 PM, Jakob Heitz <jakob.heitz@ericsson.com> wro= te: > Pedro, > > Suppose 3 RR clusters in an AS. > Overall bestpath is in cluster 2. > Cluster 1 will calculate the best-external > to send to cluster 2. > He will use the paths from cluster 3 and > cluster 1 to calculate the best external. > If the best from that set is in cluster 3, > he will send nothing to cluster 2. > > Is that right? That is a feasible and correct approach. It will provide a overall second best path across the AS in a scenario where the intent is to have a failover path ready and routes are being selected on MED/local-pref. It is also possible to eliminate from consideration all the iBGP received paths before selecting the best-external (among routes that have been received from the cluster only); this would yield a scenario where each cluster advertises its local path. Which may be an overkill in many deployments. The current language of the draft suggests the latter approach. Which doesn't necessarily mean it is the most adequate in all situations. Pedro. > > -- > Jakob Heitz. 510-566-2901 > > >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On >> Behalf Of Pedro Marques >> Sent: Monday, March 21, 2011 6:48 PM >> To: Ray Saikat >> Cc: idr@ietf.org >> Subject: Re: [Idr] draft-ietf-idr-best-external-03 >> >> Saikat, >> >> On Mon, Mar 21, 2011 at 5:15 PM, Saikat Ray >> <ray.saikat@ericsson.com> wrote: >> > Hi Pedro: >> > >> > Thanks much for the response. It clears things up a lot. >> Could you please >> > also answer the one question you missed ... >> > >> > =A0 9. Suppose we have three member AS - 1, 2, 3 - in a confederation; >> > =A0 =A0 =A0ASBRi is the Confed ASBR of member-AS i. At ASBR1, the >> path from >> > =A0 =A0 =A0ASBR2 is the overall-bestpath. >> > =A0 =A0 =A0 =A0 =A0 =A0Does the computation for "best internal" path, = that ASBR1 >> > =A0 =A0 =A0 =A0 =A0 =A0sends to ASBR2, include paths from ASBR3 in its= set of >> > =A0 =A0 =A0 =A0 =A0 =A0"internal" paths? >> >> Yes. In this scenario, when ASBR1 generates an update to ASBR2 it is >> selecting the best of all its known paths that where not received from >> member AS 2. >> >> The same rule applies for route reflection. Consider the top level >> iBGP mesh to be cluster-id 0; When advertising to a specific set of >> peers, "best-external" selects the best route from the set of known >> routes that has not been received from the same cluster-id as the >> "target". >> >> > >> > I think the document should define the terms it is using >> more clearly. >> >> I agree. >> >> > Even >> > terms like "AS Domain" and "RR Domain" are open to >> interpretations. E.g., a >> > RR can have true EBGP peers. Then is it in an AS Domain or >> is it in an RR >> > Domain? Maybe the best thing would be to have a paragraph >> in the appendix >> > that describes the task of a given BGP speaker considering >> the full set of >> > paths and all possible types of peers that can co-exist. >> E.g., a BGP speaker >> > can have: (i) true EBGP peers, (ii) RR-client peers, (iii) >> non-client IBGP >> > peers, (iv) member-AS IBGP peers, (v) non-member-AS confed >> EBGP peers. All >> > such peers can co-exist (when the BGP speaker is both an RR >> and a Confed >> > ASBR). If the behavior is undefined in some cases (e.g., >> RR+Confed ASBR >> > combination), then that should be said. >> >> The behavior is easy to define in pseudo-code: >> =A0 =A0eligible-routes =3D RIB-In routes Excluding { cluster-id and >> confed-as of peer } >> =A0 =A0select the best of eligible routes. >> >> Assuming that cluster-id of a non-client peer is 0; confed-as of non >> confed eibgp peer is 0. >> >> I agree with you. The existing text sort of mumbles it all together. >> >> =A0 Pedro. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> From randy@psg.com Tue Mar 22 10:34:19 2011 Return-Path: <randy@psg.com> 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 7954B28C13D for <idr@core3.amsl.com>; Tue, 22 Mar 2011 10:34:19 -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 4d4hwOxTNQyv for <idr@core3.amsl.com>; Tue, 22 Mar 2011 10:34:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 6693D28C0E3 for <idr@ietf.org>; Tue, 22 Mar 2011 10:34:18 -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 <randy@psg.com>) id 1Q25TY-000LZR-6z for idr@ietf.org; Tue, 22 Mar 2011 17:34:36 +0000 Date: Tue, 22 Mar 2011 10:34:35 -0700 Message-ID: <m2bp13ukic.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: idr@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 17:34:19 -0000 the following text has been added to sec 3 of the unpublished -02 Applications generating messages which might be encapsulated within BGP messages MUST be aware of the maximum message size and all encapsulation overheads on the path the encapsulated data are expected to traverse. randy From cjeker@diehard.n-r-g.com Tue Mar 22 10:53:11 2011 Return-Path: <cjeker@diehard.n-r-g.com> 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 4B1A03A68BF for <idr@core3.amsl.com>; Tue, 22 Mar 2011 10:53: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=[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 282HlII+QTmf for <idr@core3.amsl.com>; Tue, 22 Mar 2011 10:53:10 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id 2F12A3A68BC for <idr@ietf.org>; Tue, 22 Mar 2011 10:53:10 -0700 (PDT) Received: (qmail 19009 invoked by uid 1001); 22 Mar 2011 17:54:41 -0000 Date: Tue, 22 Mar 2011 18:54:40 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: idr@ietf.org Message-ID: <20110322175440.GF20670@diehard.n-r-g.com> References: <m2bp13ukic.wl%randy@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <m2bp13ukic.wl%randy@psg.com> 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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 17:53:11 -0000 On Tue, Mar 22, 2011 at 10:34:35AM -0700, Randy Bush wrote: > the following text has been added to sec 3 of the unpublished -02 > > Applications generating messages which might be encapsulated within > BGP messages MUST be aware of the maximum message size and all > encapsulation overheads on the path the encapsulated data are > expected to traverse. > What does the "path the encapsulated data are expected to traverse" matter here? BGP is still using TCP and TCP is a byte stream. There is no encapsulation overheads other then the BGP message encodeing itself. Do we really need to make everything much more complex than it actually is? -- :wq Claudio From keyupate@cisco.com Tue Mar 22 10:58:39 2011 Return-Path: <keyupate@cisco.com> 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 5629628C0E5 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 10:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 aVUJXnwGVi+R for <idr@core3.amsl.com>; Tue, 22 Mar 2011 10:58:38 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6ABA828C14C for <idr@ietf.org>; Tue, 22 Mar 2011 10:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=812; q=dns/txt; s=iport; t=1300816812; x=1302026412; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=REqeTv5nTSdJpAasQfZX9rlpg3gdwp9qXY+PCXBLFtw=; b=I0GPhx0mBeGaqDfirv4CmS1/45MpHWfZCBYHSmScgSjreRdFmPln7YMx Cc5le7Bbgbc31Q9fYxDR5RE9BmdPIpzn+d7eRHP3ensjIuWrLKIdqM0cn yDBriNezL+tgzBodGkoHkT4gF2RsAq4o9DmC2cVhDJ2sHW/kI0TkQwFrN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMWAiE2rRDoJ/2dsb2JhbAClO3eITZ5RnD6FaASFNYc2g1g X-IronPort-AV: E=Sophos;i="4.63,226,1299456000"; d="scan'208";a="279507386" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2011 18:00:11 +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 p2MI0Bdo002056; Tue, 22 Mar 2011 18:00:11 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, 22 Mar 2011 11:00:11 -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.32]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Mar 2011 18:00:11 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 22 Mar 2011 10:59:30 -0700 From: Keyur Patel <keyupate@cisco.com> To: Claudio Jeker <cjeker@diehard.n-r-g.com>, <idr@ietf.org> Message-ID: <C9AE3192.1B1C2%keyupate@cisco.com> Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: AcvouuQuIs0UbFSuEeCjUgAbY71bnA== In-Reply-To: <20110322175440.GF20670@diehard.n-r-g.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2011 18:00:11.0601 (UTC) FILETIME=[FCFA3C10:01CBE8BA] 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 17:58:39 -0000 Claudio, On 3/22/11 10:54 AM, "Claudio Jeker" <cjeker@diehard.n-r-g.com> wrote: > On Tue, Mar 22, 2011 at 10:34:35AM -0700, Randy Bush wrote: >> the following text has been added to sec 3 of the unpublished -02 >> >> Applications generating messages which might be encapsulated within >> BGP messages MUST be aware of the maximum message size and all >> encapsulation overheads on the path the encapsulated data are >> expected to traverse. >> > > What does the "path the encapsulated data are expected to traverse" matter > here? BGP is still using TCP and TCP is a byte stream. There is no > encapsulation overheads other then the BGP message encodeing itself. > We have Notification and Diagnostic messages that could contain a BGP update message. Regards, Keyur From randy@psg.com Tue Mar 22 11:08:31 2011 Return-Path: <randy@psg.com> 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 6E33D28C159 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 11:08:31 -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 cfFZOfFewVOE for <idr@core3.amsl.com>; Tue, 22 Mar 2011 11:08:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 961A328C153 for <idr@ietf.org>; Tue, 22 Mar 2011 11:08:30 -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 <randy@psg.com>) id 1Q261r-000MFC-4w; Tue, 22 Mar 2011 18:10:03 +0000 Date: Tue, 22 Mar 2011 11:10:02 -0700 Message-ID: <m24o6vuiv9.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Claudio Jeker <cjeker@diehard.n-r-g.com> In-Reply-To: <20110322175440.GF20670@diehard.n-r-g.com> References: <m2bp13ukic.wl%randy@psg.com> <20110322175440.GF20670@diehard.n-r-g.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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 18:08:31 -0000 >> Applications generating messages which might be encapsulated within >> BGP messages MUST be aware of the maximum message size and all >> encapsulation overheads on the path the encapsulated data are >> expected to traverse. > > What does the "path the encapsulated data are expected to traverse" > matter here? i expect to see suggestions of mpls label stacks within bgp that are expected to traverse multiple bgp speakers on this list any day now. this wording anticipates them. > BGP is still using TCP and TCP is a byte stream. There is no > encapsulation overheads other then the BGP message encodeing itself. bgp does not encode itself. some people have an application of a bgp hack that then encapsulates a bgp message. all this change says is the blatantly obvious (one would have thought), if you think your sour cream might be encapsulated in a bgp message, then use less sour cream. > Do we really need to make everything much more complex than it actually > is? hey, i did not come up with this encapsulation stuff. i am just trying not to let every flavor of dairy causing changes in the basic message. randy From raszuk@cisco.com Tue Mar 22 13:20:35 2011 Return-Path: <raszuk@cisco.com> 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 2BDE028C176 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 13:20:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az7jzoI8S5JB for <idr@core3.amsl.com>; Tue, 22 Mar 2011 13:20:31 -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 E5EA428C166 for <idr@ietf.org>; Tue, 22 Mar 2011 13:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1266; q=dns/txt; s=iport; t=1300825322; x=1302034922; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NidzgyNCkpfoGhINSvKbVwe/BVHApcYRybBqyH5zhVU=; b=K3WQapZ2jQ8td3ddrAXqzBwPssz8lm647542frCN5oS/KCCNQfAp0yOm uaBBisgGGM/kENi8zZnAaZvG3CgJyfgvRL/9pNYsvUvz6YAMhMnYxZ0O/ eoAbsSOBHjaZVvK8A5J/nIIJc6gQuGd76O7j0LPrX0bfA11tLbOGkAa+V w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAOiiE2rRDoG/2dsb2JhbAClQHeITZ8bgm4OAZkkhWgEjGuDUg X-IronPort-AV: E=Sophos;i="4.63,226,1299456000"; d="scan'208";a="323143796" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2011 20:22:02 +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 p2MKM0I3022946; Tue, 22 Mar 2011 20:22:01 GMT Message-ID: <4D8904EA.8040106@cisco.com> Date: Tue, 22 Mar 2011 21:22:02 +0100 From: Robert Raszuk <raszuk@cisco.com> 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 <randy@psg.com> References: <m2bp13ukic.wl%randy@psg.com> In-Reply-To: <m2bp13ukic.wl%randy@psg.com> 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.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 20:20:35 -0000 Hi Randy, The text below does not reflect the proposal from Enke nor does it fix the issue. This is not the point for application to be aware of max BGP message size. This is about allowing one BGP message from SAFI X to contain entire BGP message from SAFI Y. If you make SAFI Y massage as big as it is possible with two octet length field it effectively means that SAFI X may include it only by cutting it into two pieces. And how do you cut malformed update which you can not parse in the first place ? Then you need to worry about reassemble on the other side. Sure everything is possible, but I think we should choose the easiest solutions. Reducing max BGP message size of just few octets to allow extra header seems quite a reasonable suggestion. Many thx, R. > the following text has been added to sec 3 of the unpublished -02 > > Applications generating messages which might be encapsulated within > BGP messages MUST be aware of the maximum message size and all > encapsulation overheads on the path the encapsulated data are > expected to traverse. > > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From raszuk@cisco.com Tue Mar 22 13:29:02 2011 Return-Path: <raszuk@cisco.com> 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 C0BC628C17D for <idr@core3.amsl.com>; Tue, 22 Mar 2011 13:29:02 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOrMpS92PTgf for <idr@core3.amsl.com>; Tue, 22 Mar 2011 13:29:01 -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 89AA628C170 for <idr@ietf.org>; Tue, 22 Mar 2011 13:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=673; q=dns/txt; s=iport; t=1300825835; x=1302035435; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=MRqxfQcA6RVRgi3m7fFxooLrjfjcR5IEh31xvWJoPro=; b=c0845PzzbZjWuhVHSgpuOZ5jv5AJezy0VxjvvsHh4dLLsAKyjtoazNNc eepMYqy4izSBCSJzqlLacpyAKb4V3ByYo46gGQZ+QR0U98TweuhSbOaBX KoZggsaGO3lKRsQBfV3+8yYqWAH+XcTd/CN2OfijSh+RFDsehj/cuxq1p E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMHAC+jiE2rRDoG/2dsb2JhbACYSYx3d4hNnyKCbg4BmSSFaASMa4NS X-IronPort-AV: E=Sophos;i="4.63,226,1299456000"; d="scan'208";a="417004861" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 22 Mar 2011 20:30:34 +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 p2MKUXYD032671 for <idr@ietf.org>; Tue, 22 Mar 2011 20:30:33 GMT Message-ID: <4D8906EB.2060305@cisco.com> Date: Tue, 22 Mar 2011 21:30:35 +0100 From: Robert Raszuk <raszuk@cisco.com> 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: <m2bp13ukic.wl%randy@psg.com> <20110322175440.GF20670@diehard.n-r-g.com> <m24o6vuiv9.wl%randy@psg.com> In-Reply-To: <m24o6vuiv9.wl%randy@psg.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.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 20:29:02 -0000 Hi Randy, > bgp does not encode itself. some people have an application of a bgp > hack that then encapsulates a bgp message. all this change says is the > blatantly obvious (one would have thought), if you think your sour cream > might be encapsulated in a bgp message, then use less sour cream. I agree with this very much. But this is not about some other applications proposing to carry Eiffel Tower of MPLS label bricks in BGP nor put Brittanica inside one BGP message. It would be blatantly obvious indeed that such application better handle it - it has no choice anyway. The problem is different as described in the other mail. Many thx, R. From randy@psg.com Tue Mar 22 13:29:22 2011 Return-Path: <randy@psg.com> 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 90FF928C189 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 13:29: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=[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 3Siakq8FqVrh for <idr@core3.amsl.com>; Tue, 22 Mar 2011 13:29:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id EDB6F28C13D for <idr@ietf.org>; Tue, 22 Mar 2011 13:29:21 -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 <randy@psg.com>) id 1Q28Cy-000MhW-9I; Tue, 22 Mar 2011 20:29:40 +0000 Date: Tue, 22 Mar 2011 13:29:39 -0700 Message-ID: <m2hbauucek.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Robert Raszuk <raszuk@cisco.com> In-Reply-To: <4D8904EA.8040106@cisco.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 20:29:22 -0000 > If you make SAFI Y massage as big as it is possible with two octet > length field it effectively means that SAFI X may include it only by > cutting it into two pieces. then don't do that. randy From raszuk@cisco.com Tue Mar 22 13:32:10 2011 Return-Path: <raszuk@cisco.com> 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 7807E28C18E for <idr@core3.amsl.com>; Tue, 22 Mar 2011 13:32:09 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3DdcEZIql18 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 13:32:08 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 65DA328C18F for <idr@ietf.org>; Tue, 22 Mar 2011 13:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=521; q=dns/txt; s=iport; t=1300826021; x=1302035621; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tT9ss0AFEcy6FEl4SeFNg4UX+VyYYjvgEsi7RBXW//A=; b=ia8WFxmTeyKO+r9wFr9P3lnXdqiAGhOgKAHwKdh9j0Nml7JjFMVSt5bu 6K5NqcmAqWhTa3TnCkxpJnTQXKqrqXe3y/uyHGKY/Lfpmg/z8mdT0qCyE znPg1LWigefz0+Gg4RWCsImO7rY18Up4UjhSs4o22gJWJqvUt+VAziOfF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJekiE2rRDoJ/2dsb2JhbAClQHeITZ8ugm4OAZkkhWgEjGuDUg X-IronPort-AV: E=Sophos;i="4.63,227,1299456000"; d="scan'208";a="350740303" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2011 20:33:40 +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 p2MKXcRw013357; Tue, 22 Mar 2011 20:33:39 GMT Message-ID: <4D8907A5.30702@cisco.com> Date: Tue, 22 Mar 2011 21:33:41 +0100 From: Robert Raszuk <raszuk@cisco.com> 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 <randy@psg.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> In-Reply-To: <m2hbauucek.wl%randy@psg.com> 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.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 20:32:10 -0000 We have IP operators asking to send them back malformed update within BGP (no new protocol to establish between ASes). Should the answer be: Sorry dear ISP - No - since Randy said so ? I am personnaly fine either way .. let's just make it clearly documented on the list and move on. R. >> If you make SAFI Y massage as big as it is possible with two octet >> length field it effectively means that SAFI X may include it only by >> cutting it into two pieces. > > then don't do that. > > randy > From randy@psg.com Tue Mar 22 13:39:53 2011 Return-Path: <randy@psg.com> 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 8E2B628C121 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 13:39:53 -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 CzSrwg7mTds3 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 13:39:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id F04E528C0D7 for <idr@ietf.org>; Tue, 22 Mar 2011 13:39:50 -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 <randy@psg.com>) id 1Q28OK-000MkS-Ig; Tue, 22 Mar 2011 20:41:24 +0000 Date: Tue, 22 Mar 2011 13:41:24 -0700 Message-ID: <m2d3liubuz.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Robert Raszuk <raszuk@cisco.com> In-Reply-To: <4D8907A5.30702@cisco.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 20:39:54 -0000 > We have IP operators asking to send them back malformed update within > BGP (no new protocol to establish between ASes). > > Should the answer be: Sorry dear ISP - No - since Randy said so ? i am beginning to suspect that you place a different value on time than i. if you want to encaps, that which is encapsulated will have to be smaller than the transport limit. what you propose to to is pretend the transport limit is the limit-<encaps overhead>, which is just a play on words. if you want to be able to encaps something later, make it small enough to fit. you can rename it all you want, but you ain't gonna escape it. randy From cjeker@diehard.n-r-g.com Tue Mar 22 14:10:04 2011 Return-Path: <cjeker@diehard.n-r-g.com> 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 4D4F728C0D9 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 14:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5] 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 BdWJ8OpEAvfO for <idr@core3.amsl.com>; Tue, 22 Mar 2011 14:10:03 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id 1AB193A67CC for <idr@ietf.org>; Tue, 22 Mar 2011 14:10:02 -0700 (PDT) Received: (qmail 10758 invoked by uid 1001); 22 Mar 2011 21:11:31 -0000 Date: Tue, 22 Mar 2011 22:11:31 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: Randy Bush <randy@psg.com> Message-ID: <20110322211131.GH9210@diehard.n-r-g.com> References: <m2bp13ukic.wl%randy@psg.com> <20110322175440.GF20670@diehard.n-r-g.com> <m24o6vuiv9.wl%randy@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <m24o6vuiv9.wl%randy@psg.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 21:10:04 -0000 On Tue, Mar 22, 2011 at 11:10:02AM -0700, Randy Bush wrote: > >> Applications generating messages which might be encapsulated within > >> BGP messages MUST be aware of the maximum message size and all > >> encapsulation overheads on the path the encapsulated data are > >> expected to traverse. > > > > What does the "path the encapsulated data are expected to traverse" > > matter here? > > i expect to see suggestions of mpls label stacks within bgp that are > expected to traverse multiple bgp speakers on this list any day now. > this wording anticipates them. > But that's the same with AS_PATH attributes or extended communities. Yes, if you plan to prepend 1024 times your AS then you will hit a brick wall. Nothing new here. > > BGP is still using TCP and TCP is a byte stream. There is no > > encapsulation overheads other then the BGP message encodeing itself. > > bgp does not encode itself. some people have an application of a bgp > hack that then encapsulates a bgp message. all this change says is the > blatantly obvious (one would have thought), if you think your sour cream > might be encapsulated in a bgp message, then use less sour cream. Yes, realized that I used the wrong word. s/encoding/encapsulating/ In the end it should be obvious that the sum of attributes must stay below the bgp message limit. I just don't see why there is this fuzzy notion of overheads ... expected to traverse. What should an implementor do with such unspecific informations? In which case would I need to reduce the message size to leave room for additional overhead and how much is needed? > > > Do we really need to make everything much more complex than it actually > > is? > > hey, i did not come up with this encapsulation stuff. i am just trying > not to let every flavor of dairy causing changes in the basic message. I guess it is the duty of the dairy queen to ensure that all flavors fit into a bgp message (be it 4k or 64k). -- :wq Claudio From randy@psg.com Tue Mar 22 14:13:33 2011 Return-Path: <randy@psg.com> 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 2934B28C120 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 14:13:33 -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 II0CkTEX3rF9 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 14:13:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 746D428C11E for <idr@ietf.org>; Tue, 22 Mar 2011 14:13:32 -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 <randy@psg.com>) id 1Q28uu-000Mrs-Ct; Tue, 22 Mar 2011 21:15:05 +0000 Date: Tue, 22 Mar 2011 14:15:02 -0700 Message-ID: <m262rauaax.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Claudio Jeker <cjeker@diehard.n-r-g.com> In-Reply-To: <20110322211131.GH9210@diehard.n-r-g.com> References: <m2bp13ukic.wl%randy@psg.com> <20110322175440.GF20670@diehard.n-r-g.com> <m24o6vuiv9.wl%randy@psg.com> <20110322211131.GH9210@diehard.n-r-g.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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 21:13:33 -0000 > I guess it is the duty of the dairy queen to ensure that all flavors > fit into a bgp message (be it 4k or 64k). bingo! and, if you think the person with whom you are sharing the cone might add chocolate, nuts, whipped cream, a cherry, ... then you can guess how much less to put in. i don't want to guess. i think this is all way too kinky. i am from the pacific northwest, not complexifornica. randy From cjeker@diehard.n-r-g.com Tue Mar 22 14:21:52 2011 Return-Path: <cjeker@diehard.n-r-g.com> 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 E9AC528C0D9 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 14:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=1.250, 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 ml1TtLzd91SD for <idr@core3.amsl.com>; Tue, 22 Mar 2011 14:21:52 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id B2C5F3A67CC for <idr@ietf.org>; Tue, 22 Mar 2011 14:21:51 -0700 (PDT) Received: (qmail 9201 invoked by uid 1001); 22 Mar 2011 21:23:24 -0000 Date: Tue, 22 Mar 2011 22:23:24 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: idr@ietf.org Message-ID: <20110322212324.GI9210@diehard.n-r-g.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D8907A5.30702@cisco.com> 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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 21:21:53 -0000 On Tue, Mar 22, 2011 at 09:33:41PM +0100, Robert Raszuk wrote: > > We have IP operators asking to send them back malformed update > within BGP (no new protocol to establish between ASes). > > Should the answer be: Sorry dear ISP - No - since Randy said so ? No the answer is, we try our best but maybe part of the message is truncated because it exceeds the message boundary. This is needed anyway since the proposed Extended Message support is asymetric. It is a diagnostic message and so truncation is acceptable. > I am personnaly fine either way .. let's just make it clearly > documented on the list and move on. > > R. > > >>If you make SAFI Y massage as big as it is possible with two octet > >>length field it effectively means that SAFI X may include it only by > >>cutting it into two pieces. > > > >then don't do that. > > Actually I don't see how this would be possible with the current MP spec (at least the NLRI encoding is limited to 256bits and so way smaller then the current limit). -- :wq Claudio From raszuk@cisco.com Tue Mar 22 14:25:47 2011 Return-Path: <raszuk@cisco.com> 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 B0D0228C169 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 14:25:47 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l093ZAuGOg2C for <idr@core3.amsl.com>; Tue, 22 Mar 2011 14:25:46 -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 AA63928C166 for <idr@ietf.org>; Tue, 22 Mar 2011 14:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=363; q=dns/txt; s=iport; t=1300829240; x=1302038840; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vzqes7TnBDyioEsME7kQFnlK0U3vHQRDQOY1ni10Pmw=; b=NorhdQa9STbVVV1BImtMbwyFL8RtX6cSsJjnUpJrxM644dlZJqlv/1CS Tb/+TMkb1vAG+lxUgyyQ8bHJPIma5qMeKI9tKgUP19Bh//7CbuWmsGVFr lauWTm9+jQLt9BF7EW2V02KClNFdFB+jUHFo6btRF5H5yBrxNd79r46ov g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHqxiE2rRDoG/2dsb2JhbAClQneITaAggm4OAZkbhWgEjGuDUg X-IronPort-AV: E=Sophos;i="4.63,227,1299456000"; d="scan'208";a="669602351" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 22 Mar 2011 21:27:05 +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 p2MLR4vb023391; Tue, 22 Mar 2011 21:27:04 GMT Message-ID: <4D89142A.7010607@cisco.com> Date: Tue, 22 Mar 2011 22:27:06 +0100 From: Robert Raszuk <raszuk@cisco.com> 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: Claudio Jeker <cjeker@diehard.n-r-g.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> In-Reply-To: <20110322212324.GI9210@diehard.n-r-g.com> 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.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 21:25:47 -0000 Hi Claudio, > Actually I don't see how this would be possible with the current MP spec > (at least the NLRI encoding is limited to 256bits and so way smaller then > the current limit). I do not put it into MP_REACH :) See http://tools.ietf.org/html/draft-raszuk-bgp-diagnostic-message-02 for encoding details of new message format. Many thx, R. From ilya@nobulus.com Tue Mar 22 15:49:46 2011 Return-Path: <ilya@nobulus.com> 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 C42FC3A6808 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 15:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 QEAcOZLG6xAy for <idr@core3.amsl.com>; Tue, 22 Mar 2011 15:49:26 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 5261D3A6803 for <idr@ietf.org>; Tue, 22 Mar 2011 15:49:26 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id BD76417330; Tue, 22 Mar 2011 23:50:57 +0100 (CET) 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 8GA+ffiS1eQu; Tue, 22 Mar 2011 23:50:55 +0100 (CET) Received: from c3b41984.dsl.de.easynet.net (C3B41984.dsl.de.easynet.net [195.180.25.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 2A79717159; Tue, 22 Mar 2011 23:50:55 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ilya Varlashkin <ilya@nobulus.com> In-Reply-To: <20110322212324.GI9210@diehard.n-r-g.com> Date: Tue, 22 Mar 2011 23:50:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> To: IETF IDR <idr@ietf.org>, Claudio Jeker <cjeker@diehard.n-r-g.com> X-Mailer: Apple Mail (2.1082) 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 22:49:46 -0000 On Mar 22, 2011, at 22:23 , Claudio Jeker wrote: > On Tue, Mar 22, 2011 at 09:33:41PM +0100, Robert Raszuk wrote: >>=20 >> We have IP operators asking to send them back malformed update >> within BGP (no new protocol to establish between ASes). >>=20 >> Should the answer be: Sorry dear ISP - No - since Randy said so ? >=20 > No the answer is, we try our best but maybe part of the message is > truncated because it exceeds the message boundary. This is needed = anyway > since the proposed Extended Message support is asymetric. > It is a diagnostic message and so truncation is acceptable. >=20 I don't share view that truncation is acceptable. As an operator I would = like to see whole message that caused the problem. And my understanding = of current situation regarding message size is that coder of = non-diagnostic message has two choices: a) feel free to send MAX_SIZEd message and expect that other side will = just truncate, or b) be aware that his/her message can be encapsulated inside other = message at some point and therefore he/her MUST leave room for those = possible encapsulations and at the moment going either way will be compliant with specification. = So we may end up with some implementations in the field that don't leave = room for secondary encapsulation and some that do, and some that do it = by a switch. With operator's hat on I would rather have specification = clearly saying that we want option (b) in all compliant implementations. If we can agree on the above, then second issue to resolve is which = messages are allowed to be MAX_SIZEd and which should allow room for = other encapsulations. And finally we need to agree how much room exactly = to leave. Kind regards, iLya From jakob.heitz@ericsson.com Tue Mar 22 16:11:37 2011 Return-Path: <jakob.heitz@ericsson.com> 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 E426C28C16D for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=1.075, 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 4NM8oEHaiR5k for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:11:36 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id AF43028C0F8 for <idr@ietf.org>; Tue, 22 Mar 2011 16:11:36 -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 p2MND3CN001946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Mar 2011 18:13:05 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 22 Mar 2011 19:13:03 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: Ilya Varlashkin <ilya@nobulus.com>, IETF IDR <idr@ietf.org> Date: Tue, 22 Mar 2011 19:13:01 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acvo462uPxdeMU0jQNO0h++0uKB+fQAANDyQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> In-Reply-To: <BC6441F3-DA49-47CC-A97A-B348729721BE@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 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:11:38 -0000 I agree with Ilya. It's not going to hurt anyone to shave a hundred or two bytes off the end. I don't even like the maximum size of 65535. No concrete reason, I just feel nervous pushing things to the red line. -- Jakob Heitz. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Ilya Varlashkin > Sent: Tuesday, March 22, 2011 3:51 PM > To: IETF IDR; Claudio Jeker > Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 >=20 >=20 > On Mar 22, 2011, at 22:23 , Claudio Jeker wrote: >=20 > > On Tue, Mar 22, 2011 at 09:33:41PM +0100, Robert Raszuk wrote: > >>=20 > >> We have IP operators asking to send them back malformed update > >> within BGP (no new protocol to establish between ASes). > >>=20 > >> Should the answer be: Sorry dear ISP - No - since Randy said so ? > >=20 > > No the answer is, we try our best but maybe part of the message is > > truncated because it exceeds the message boundary. This is=20 > needed anyway > > since the proposed Extended Message support is asymetric. > > It is a diagnostic message and so truncation is acceptable. > >=20 >=20 > I don't share view that truncation is acceptable. As an=20 > operator I would like to see whole message that caused the=20 > problem. And my understanding of current situation regarding=20 > message size is that coder of non-diagnostic message has two choices: >=20 > a) feel free to send MAX_SIZEd message and expect that other=20 > side will just truncate, or > b) be aware that his/her message can be encapsulated inside=20 > other message at some point and therefore he/her MUST leave=20 > room for those possible encapsulations >=20 > and at the moment going either way will be compliant with=20 > specification. So we may end up with some implementations in=20 > the field that don't leave room for secondary encapsulation=20 > and some that do, and some that do it by a switch. With=20 > operator's hat on I would rather have specification clearly=20 > saying that we want option (b) in all compliant implementations. >=20 > If we can agree on the above, then second issue to resolve is=20 > which messages are allowed to be MAX_SIZEd and which should=20 > allow room for other encapsulations. And finally we need to=20 > agree how much room exactly to leave. >=20 >=20 > Kind regards, > iLya >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From randy@psg.com Tue Mar 22 16:28:56 2011 Return-Path: <randy@psg.com> 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 AD3C628C15E for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:28:56 -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 k0K2lYUYinrr for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:28:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id E36E428C154 for <idr@ietf.org>; Tue, 22 Mar 2011 16:28:55 -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 <randy@psg.com>) id 1Q2B0j-000NJt-5S; Tue, 22 Mar 2011 23:29:13 +0000 Date: Tue, 22 Mar 2011 16:29:12 -0700 Message-ID: <m21v1yu43b.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Ilya Varlashkin <ilya@nobulus.com> In-Reply-To: <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:28:56 -0000 > that coder of non-diagnostic message has two choices: > > a) feel free to send MAX_SIZEd message and expect that other side will > just truncate, or real close, but not quite. it is not specified what the encapsulator who ran out of room will do. truncate is a possibility. > b) be aware that his/her message can be encapsulated inside other > message at some point and therefore he/her MUST leave room for those > possible encapsulations good idea > With operator's hat on I would rather have specification clearly > saying that we want option (b) in all compliant implementations. well, it does say MUST. randy From raszuk@cisco.com Tue Mar 22 16:32:06 2011 Return-Path: <raszuk@cisco.com> 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 069B828C164 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:32:06 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgRpRQOO8gIo for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:32:04 -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 6C00528C154 for <idr@ietf.org>; Tue, 22 Mar 2011 16:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=286; q=dns/txt; s=iport; t=1300836818; x=1302046418; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pGtYDlGHHRZC/r+Jfcz1YBiCHZ0ahWt8TqK0MsOQReA=; b=ahtGZqm+N01J+OjarC0OBjugcKGAHn2egVCa4+DcSAekjNkf2VOTP0y+ h7GsaYkXr0icujWVkv2jNSis2IguuvD3b4NvL9ACJtiK48TBslBPYW+28 kIyyse6H0+wf9UVx6Q4q2Kqx0i5fYViUXj2gPYkQUPpcl4Wpg7xBgKzG3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIzOiE2rRDoH/2dsb2JhbAClQneITaB0gm4OAZkPhWgEjGuDUg X-IronPort-AV: E=Sophos;i="4.63,228,1299456000"; d="scan'208";a="323217153" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2011 23:33:32 +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 p2MNXUQM007385; Tue, 22 Mar 2011 23:33:31 GMT Message-ID: <4D8931CC.9000209@cisco.com> Date: Wed, 23 Mar 2011 00:33:32 +0100 From: Robert Raszuk <raszuk@cisco.com> 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 <randy@psg.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <m21v1yu43b.wl%randy@psg.com> In-Reply-To: <m21v1yu43b.wl%randy@psg.com> 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.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:32:06 -0000 >> With operator's hat on I would rather have specification clearly >> saying that we want option (b) in all compliant implementations. > > well, it does say MUST. "MUST be aware" ... That does not define what "MUST" encoding/action should be. An important difference. R. From keyupate@cisco.com Tue Mar 22 16:34:35 2011 Return-Path: <keyupate@cisco.com> 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 1D18228C164 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 vk9UwL0u89Zz for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:34:34 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0D17A3A6841 for <idr@ietf.org>; Tue, 22 Mar 2011 16:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=2995; q=dns/txt; s=iport; t=1300836967; x=1302046567; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=N8dnVBHhrgNVgvUYlXb/j6VqyajC9Ea4ffjWHiwHc1k=; b=b/Lom6mAtFbKrreTwrEWfJf0lo/t8n6sUkwg7/z/7QzjYhoIu4GRyK6N t3oxK80+4YMeO1oMhHZlm/bratkOQZG3bvnDUJWPy5eEFenoJP5wdRG4x Mh3ddCc0Tn4O5WDwmrDTYrch8QHJoosRPQRPXXGjTc1TtLJmxjt/E/N76 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAMfOiE2rRDoI/2dsb2JhbACYDI02d4hNoHCcDIVoBIU1hzaDWA X-IronPort-AV: E=Sophos;i="4.63,228,1299456000"; d="scan'208";a="350830333" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2011 23:36:05 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2MNa4Rd017599; Tue, 22 Mar 2011 23:36:05 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); Tue, 22 Mar 2011 16:36:04 -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 ; Tue, 22 Mar 2011 23:36:03 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 22 Mar 2011 16:35:21 -0700 From: Keyur Patel <keyupate@cisco.com> To: Jakob Heitz <jakob.heitz@ericsson.com>, Ilya Varlashkin <ilya@nobulus.com>, IETF IDR <idr@ietf.org> Message-ID: <C9AE8049.1B2CB%keyupate@cisco.com> Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acvo462uPxdeMU0jQNO0h++0uKB+fQAANDyQAAFUH7Q= In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2011 23:36:04.0346 (UTC) FILETIME=[E8F315A0:01CBE8E9] 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:34:35 -0000 IMHO the draft should not document how many *bytes to leave*. Instead it should be flexible enough and should be left upon implementations. As long as an implementation is able to encapsulate BGP messages it should be good enough. Regards, Keyur On 3/22/11 4:13 PM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote: > I agree with Ilya. > > It's not going to hurt anyone to shave a hundred or two > bytes off the end. > > I don't even like the maximum size of 65535. > > No concrete reason, I just feel nervous pushing > things to the red line. > > -- > Jakob Heitz. > > >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On >> Behalf Of Ilya Varlashkin >> Sent: Tuesday, March 22, 2011 3:51 PM >> To: IETF IDR; Claudio Jeker >> Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 >> >> >> On Mar 22, 2011, at 22:23 , Claudio Jeker wrote: >> >>> On Tue, Mar 22, 2011 at 09:33:41PM +0100, Robert Raszuk wrote: >>>> >>>> We have IP operators asking to send them back malformed update >>>> within BGP (no new protocol to establish between ASes). >>>> >>>> Should the answer be: Sorry dear ISP - No - since Randy said so ? >>> >>> No the answer is, we try our best but maybe part of the message is >>> truncated because it exceeds the message boundary. This is >> needed anyway >>> since the proposed Extended Message support is asymetric. >>> It is a diagnostic message and so truncation is acceptable. >>> >> >> I don't share view that truncation is acceptable. As an >> operator I would like to see whole message that caused the >> problem. And my understanding of current situation regarding >> message size is that coder of non-diagnostic message has two choices: >> >> a) feel free to send MAX_SIZEd message and expect that other >> side will just truncate, or >> b) be aware that his/her message can be encapsulated inside >> other message at some point and therefore he/her MUST leave >> room for those possible encapsulations >> >> and at the moment going either way will be compliant with >> specification. So we may end up with some implementations in >> the field that don't leave room for secondary encapsulation >> and some that do, and some that do it by a switch. With >> operator's hat on I would rather have specification clearly >> saying that we want option (b) in all compliant implementations. >> >> If we can agree on the above, then second issue to resolve is >> which messages are allowed to be MAX_SIZEd and which should >> allow room for other encapsulations. And finally we need to >> agree how much room exactly to leave. >> >> >> Kind regards, >> iLya >> >> _______________________________________________ >> 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 raszuk@cisco.com Tue Mar 22 16:36:03 2011 Return-Path: <raszuk@cisco.com> 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 01CBB28C15E for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:36:03 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u9TE4OUrqR8 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:36:00 -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 D440C28C16D for <idr@ietf.org>; Tue, 22 Mar 2011 16:36:00 -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=1300837054; x=1302046654; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zJ0uwc3d0zuxZFjJyAS9Fu7WnPH5NOZoxRqJVPXPgqM=; b=ks4J/+of/NtMr/UMsWGEY0+W0baegv4Mq9wLYqGRptr+yfOTomm8O6HX jU+TwlhVo/tidJ+9KD1zX+lbdwcleF9laNNWBdIlopA2Ff6oa8BVy6mNX O623dNM4i1MnH/mKpnZWdTSDQ3FYjMTnMO8TV5sSku824MhNbzzSErO9b 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMHPiE2rRDoG/2dsb2JhbAClQneITaBNgm4OAZkQhWgEjGuDUg X-IronPort-AV: E=Sophos;i="4.63,228,1299456000"; d="scan'208";a="323218362" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2011 23:37:34 +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 p2MNbXpE028559; Tue, 22 Mar 2011 23:37:33 GMT Message-ID: <4D8932BE.1030706@cisco.com> Date: Wed, 23 Mar 2011 00:37:34 +0100 From: Robert Raszuk <raszuk@cisco.com> 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 <jakob.heitz@ericsson.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR <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 Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:36:03 -0000 Hi Jakob, > I don't even like the maximum size of 65535. That max massage size resulting in taking all bits is just not acceptable to me. This value should remain reserved till someone comes with new draft where this length indicates a special BGP message handling. So at most draft-ymbk-bgp-extended-messages could use 65534. Cheers, R. PS. On the other topic I do agree with Ilya that allowing implementations to choose what max message size of BGP UPDATE Message should be for a given SAFI under set of previously negotiated capabilities is just a pure receipt for problems. How would we handle dynamic capabilities ? Would that automatically result in essentially per peer different max BGP UPDATE Message size limit ? Nightmare to troubleshoot - that's what IMHO it will be. From ilya@nobulus.com Tue Mar 22 16:39:33 2011 Return-Path: <ilya@nobulus.com> 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 11D7D28C154 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 1ZOh-uSDH6KJ for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:39:32 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 1B7C43A6841 for <idr@ietf.org>; Tue, 22 Mar 2011 16:39:31 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id A38AF17413; Wed, 23 Mar 2011 00:41:04 +0100 (CET) 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 07UI+O6hlqVE; Wed, 23 Mar 2011 00:41:02 +0100 (CET) Received: from c3b41984.dsl.de.easynet.net (C3B41984.dsl.de.easynet.net [195.180.25.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 081EB17408; Wed, 23 Mar 2011 00:41:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin <ilya@nobulus.com> In-Reply-To: <4D8931CC.9000209@cisco.com> Date: Wed, 23 Mar 2011 00:41:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <DA0D488E-07AE-44ED-84BA-10D5F0B5AA06@nobulus.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <m21v1yu43b.wl%randy@psg.com> <4D8931CC.9000209@cisco.com> To: IETF IDR <idr@ietf.org>, Robert Raszuk <raszuk@cisco.com> X-Mailer: Apple Mail (2.1082) 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:39:33 -0000 On Mar 23, 2011, at 24:33 , Robert Raszuk wrote: >=20 >>> With operator's hat on I would rather have specification clearly >>> saying that we want option (b) in all compliant implementations. >>=20 >> well, it does say MUST. >=20 > "MUST be aware" ... That does not define what "MUST" encoding/action = should be. An important difference. >=20 ehrm...I've actually said "MUST leave room". To summarize, how about = adding following text into the draft: "As some BGP messages potentially can potentially be encapsulated inside = other BGP messages, implementations compliant to this specification MUST = limit size of messages of Type X1, ... Xn to MAX_SIZE - MAX_OVERHEAD" ? /iLya From randy@psg.com Tue Mar 22 16:39:47 2011 Return-Path: <randy@psg.com> 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 1376128C16C for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:39:47 -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 1JjUyr7Zn4xd for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:39:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 6134D28C16B for <idr@ietf.org>; Tue, 22 Mar 2011 16:39:46 -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 <randy@psg.com>) id 1Q2BCR-000NMo-7c; Tue, 22 Mar 2011 23:41:19 +0000 Date: Tue, 22 Mar 2011 16:41:18 -0700 Message-ID: <m2wrjqsoyp.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Robert Raszuk <raszuk@cisco.com> In-Reply-To: <4D8931CC.9000209@cisco.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <m21v1yu43b.wl%randy@psg.com> <4D8931CC.9000209@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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:39:47 -0000 ok 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. i feel sorry for the payloaders trying to find out the pmtu randy From cjeker@diehard.n-r-g.com Tue Mar 22 16:41:38 2011 Return-Path: <cjeker@diehard.n-r-g.com> 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 3C2AC28C164 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, 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 iMnBrpSSfp77 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:41:37 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id 9F3C328C15E for <idr@ietf.org>; Tue, 22 Mar 2011 16:41:36 -0700 (PDT) Received: (qmail 18756 invoked by uid 1001); 22 Mar 2011 23:43:08 -0000 Date: Wed, 23 Mar 2011 00:43:08 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: Robert Raszuk <raszuk@cisco.com> Message-ID: <20110322234308.GK9210@diehard.n-r-g.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D89142A.7010607@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D89142A.7010607@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:41:38 -0000 On Tue, Mar 22, 2011 at 10:27:06PM +0100, Robert Raszuk wrote: > Hi Claudio, > > >Actually I don't see how this would be possible with the current MP spec > >(at least the NLRI encoding is limited to 256bits and so way smaller then > >the current limit). > > I do not put it into MP_REACH :) > > See > http://tools.ietf.org/html/draft-raszuk-bgp-diagnostic-message-02 > for encoding details of new message format. > You mentioned putting bgp messages of SAFI X in SAFI Y. Diagnostic messages use a new message type but they have nothing todo with SAFIs. On Tue, Mar 22, 2011 at 09:22:02PM +0100, Robert Raszuk wrote: ... > This is not the point for application to be aware of max BGP message > size. This is about allowing one BGP message from SAFI X to contain > entire BGP message from SAFI Y. > > If you make SAFI Y massage as big as it is possible with two octet > length field it effectively means that SAFI X may include it only by > cutting it into two pieces. So this has nothing todo with SAFI but with the idea to be able to put a full BGP message for diagnostic reasons into another BGP message. Now I'm a bit less confused. -- :wq Claudio From jakob.heitz@ericsson.com Tue Mar 22 16:43:03 2011 Return-Path: <jakob.heitz@ericsson.com> 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 266A128C164 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.739 X-Spam-Level: X-Spam-Status: No, score=-5.739 tagged_above=-999 required=5 tests=[AWL=0.860, 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 Djbl7r9cBImR for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:43:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id F3A9828C15E for <idr@ietf.org>; Tue, 22 Mar 2011 16:43: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 p2MNiXJq028140; Tue, 22 Mar 2011 18:44:34 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 22 Mar 2011 19:44:27 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: Keyur Patel <keyupate@cisco.com>, Ilya Varlashkin <ilya@nobulus.com>, IETF IDR <idr@ietf.org> Date: Tue, 22 Mar 2011 19:44:26 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acvo462uPxdeMU0jQNO0h++0uKB+fQAANDyQAAFUH7QAADUEoA== Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> <C9AE8049.1B2CB%keyupate@cisco.com> In-Reply-To: <C9AE8049.1B2CB%keyupate@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-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:43:03 -0000 How about some numbers: maximm message size =3D 65000 maximum update message size =3D 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. -- Jakob Heitz. =20 > -----Original Message----- > From: Keyur Patel [mailto:keyupate@cisco.com]=20 > Sent: Tuesday, March 22, 2011 4:35 PM > To: Jakob Heitz; Ilya Varlashkin; IETF IDR > Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 >=20 > IMHO the draft should not document how many *bytes to leave*.=20 > Instead it > should be flexible enough and should be left upon=20 > implementations. As long > as an implementation is able to encapsulate BGP messages it=20 > should be good > enough. >=20 >=20 > Regards, > Keyur >=20 > On 3/22/11 4:13 PM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote: >=20 > > I agree with Ilya. > >=20 > > It's not going to hurt anyone to shave a hundred or two > > bytes off the end. > >=20 > > I don't even like the maximum size of 65535. > >=20 > > No concrete reason, I just feel nervous pushing > > things to the red line. > >=20 > > -- > > Jakob Heitz. > > =20 > >=20 > >> -----Original Message----- > >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On > >> Behalf Of Ilya Varlashkin > >> Sent: Tuesday, March 22, 2011 3:51 PM > >> To: IETF IDR; Claudio Jeker > >> Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 > >>=20 > >>=20 > >> On Mar 22, 2011, at 22:23 , Claudio Jeker wrote: > >>=20 > >>> On Tue, Mar 22, 2011 at 09:33:41PM +0100, Robert Raszuk wrote: > >>>>=20 > >>>> We have IP operators asking to send them back malformed update > >>>> within BGP (no new protocol to establish between ASes). > >>>>=20 > >>>> Should the answer be: Sorry dear ISP - No - since Randy said so ? > >>>=20 > >>> No the answer is, we try our best but maybe part of the message is > >>> truncated because it exceeds the message boundary. This is > >> needed anyway > >>> since the proposed Extended Message support is asymetric. > >>> It is a diagnostic message and so truncation is acceptable. > >>>=20 > >>=20 > >> I don't share view that truncation is acceptable. As an > >> operator I would like to see whole message that caused the > >> problem. And my understanding of current situation regarding > >> message size is that coder of non-diagnostic message has=20 > two choices: > >>=20 > >> a) feel free to send MAX_SIZEd message and expect that other > >> side will just truncate, or > >> b) be aware that his/her message can be encapsulated inside > >> other message at some point and therefore he/her MUST leave > >> room for those possible encapsulations > >>=20 > >> and at the moment going either way will be compliant with > >> specification. So we may end up with some implementations in > >> the field that don't leave room for secondary encapsulation > >> and some that do, and some that do it by a switch. With > >> operator's hat on I would rather have specification clearly > >> saying that we want option (b) in all compliant implementations. > >>=20 > >> If we can agree on the above, then second issue to resolve is > >> which messages are allowed to be MAX_SIZEd and which should > >> allow room for other encapsulations. And finally we need to > >> agree how much room exactly to leave. > >>=20 > >>=20 > >> Kind regards, > >> iLya > >>=20 > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > >>=20 > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr >=20 > = From raszuk@cisco.com Tue Mar 22 16:46:33 2011 Return-Path: <raszuk@cisco.com> 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 940E628C164 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:46:33 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJdhcZCBVUdv for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:46:32 -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 9705528C154 for <idr@ietf.org>; Tue, 22 Mar 2011 16:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=347; q=dns/txt; s=iport; t=1300837686; x=1302047286; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YoveYcmRP/fI+7eiM4izQ70tGCSmxacRc0+Hnrdh3IQ=; b=U3hKnJGWQmKczjx0lhF2C+znLi0RRBsRiIP+NW37cG4hYaah7gYbml5b ByJHQZK8A5fd0UprMs+gJd9wun0XnvTQsdTHkOM43+zVOviHgELXZ/kXV 4EojY5lXZLwF6EgWSq1H/Nnyd6JDJkwRjDLKe6Qt8h30aBTAvqPOOwjXa 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAErSiE2rRDoG/2dsb2JhbAClQneITaBTgm4OAZkRhWgEjGuDUg X-IronPort-AV: E=Sophos;i="4.63,228,1299456000"; d="scan'208";a="669636559" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 22 Mar 2011 23:48:06 +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 p2MNm5do003280; Tue, 22 Mar 2011 23:48:05 GMT Message-ID: <4D893536.2090507@cisco.com> Date: Wed, 23 Mar 2011 00:48:06 +0100 From: Robert Raszuk <raszuk@cisco.com> 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: Claudio Jeker <cjeker@diehard.n-r-g.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <4D89142A.7010607@cisco.com> <20110322234308.GK9210@diehard.n-r-g.com> In-Reply-To: <20110322234308.GK9210@diehard.n-r-g.com> 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.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:46:33 -0000 Hi Claudio, > You mentioned putting bgp messages of SAFI X in SAFI Y. Diagnostic > messages use a new message type but they have nothing todo with SAFIs. Yes indeed .. it was just for the purpose of descriptive illustration of the problem. The problem being the max BGP message size itself not related to any set of SAFIs. Rgs, R. From jakob.heitz@ericsson.com Tue Mar 22 16:49:27 2011 Return-Path: <jakob.heitz@ericsson.com> 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 0C50428C154 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.717, 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 ZKYMfuud+CxF for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:49:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id C781A28C16C for <idr@ietf.org>; Tue, 22 Mar 2011 16:49:25 -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 p2MNov7K028586; Tue, 22 Mar 2011 18:50:58 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 22 Mar 2011 19:50:51 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: Jakob Heitz <jakob.heitz@ericsson.com>, Keyur Patel <keyupate@cisco.com>, Ilya Varlashkin <ilya@nobulus.com>, IETF IDR <idr@ietf.org> Date: Tue, 22 Mar 2011 19:50:50 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: Acvo462uPxdeMU0jQNO0h++0uKB+fQAANDyQAAFUH7QAADUEoAAAQNTQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BC3@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> <C9AE8049.1B2CB%keyupate@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.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: 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:49:27 -0000 I didn't think of large refresh or open message... maximum notification message size =3D 65000 maximum non-notification message size =3D 64000 -- Jakob Heitz. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Jakob Heitz > Sent: Tuesday, March 22, 2011 4:44 PM > To: Keyur Patel; Ilya Varlashkin; IETF IDR > Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 >=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 > and it gives us a little playroom for the "what if" cases. >=20 > -- > Jakob Heitz. > =20 >=20 > > -----Original Message----- > > From: Keyur Patel [mailto:keyupate@cisco.com]=20 > > Sent: Tuesday, March 22, 2011 4:35 PM > > To: Jakob Heitz; Ilya Varlashkin; IETF IDR > > Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 > >=20 > > IMHO the draft should not document how many *bytes to leave*.=20 > > Instead it > > should be flexible enough and should be left upon=20 > > implementations. As long > > as an implementation is able to encapsulate BGP messages it=20 > > should be good > > enough. > >=20 > >=20 > > Regards, > > Keyur > >=20 > > On 3/22/11 4:13 PM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote: > >=20 > > > I agree with Ilya. > > >=20 > > > It's not going to hurt anyone to shave a hundred or two > > > bytes off the end. > > >=20 > > > I don't even like the maximum size of 65535. > > >=20 > > > No concrete reason, I just feel nervous pushing > > > things to the red line. > > >=20 > > > -- > > > Jakob Heitz. > > > =20 > > >=20 > > >> -----Original Message----- > > >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On > > >> Behalf Of Ilya Varlashkin > > >> Sent: Tuesday, March 22, 2011 3:51 PM > > >> To: IETF IDR; Claudio Jeker > > >> Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 > > >>=20 > > >>=20 > > >> On Mar 22, 2011, at 22:23 , Claudio Jeker wrote: > > >>=20 > > >>> On Tue, Mar 22, 2011 at 09:33:41PM +0100, Robert Raszuk wrote: > > >>>>=20 > > >>>> We have IP operators asking to send them back malformed update > > >>>> within BGP (no new protocol to establish between ASes). > > >>>>=20 > > >>>> Should the answer be: Sorry dear ISP - No - since=20 > Randy said so ? > > >>>=20 > > >>> No the answer is, we try our best but maybe part of the=20 > message is > > >>> truncated because it exceeds the message boundary. This is > > >> needed anyway > > >>> since the proposed Extended Message support is asymetric. > > >>> It is a diagnostic message and so truncation is acceptable. > > >>>=20 > > >>=20 > > >> I don't share view that truncation is acceptable. As an > > >> operator I would like to see whole message that caused the > > >> problem. And my understanding of current situation regarding > > >> message size is that coder of non-diagnostic message has=20 > > two choices: > > >>=20 > > >> a) feel free to send MAX_SIZEd message and expect that other > > >> side will just truncate, or > > >> b) be aware that his/her message can be encapsulated inside > > >> other message at some point and therefore he/her MUST leave > > >> room for those possible encapsulations > > >>=20 > > >> and at the moment going either way will be compliant with > > >> specification. So we may end up with some implementations in > > >> the field that don't leave room for secondary encapsulation > > >> and some that do, and some that do it by a switch. With > > >> operator's hat on I would rather have specification clearly > > >> saying that we want option (b) in all compliant implementations. > > >>=20 > > >> If we can agree on the above, then second issue to resolve is > > >> which messages are allowed to be MAX_SIZEd and which should > > >> allow room for other encapsulations. And finally we need to > > >> agree how much room exactly to leave. > > >>=20 > > >>=20 > > >> Kind regards, > > >> iLya > > >>=20 > > >> _______________________________________________ > > >> Idr mailing list > > >> Idr@ietf.org > > >> https://www.ietf.org/mailman/listinfo/idr > > >>=20 > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr > >=20 > >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From randy@psg.com Tue Mar 22 16:51:16 2011 Return-Path: <randy@psg.com> 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 2ADF628C16B for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:51:16 -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 yz7fMav6i9Xg for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:51:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 6494E28C154 for <idr@ietf.org>; Tue, 22 Mar 2011 16:51: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 <randy@psg.com>) id 1Q2BNV-000NRH-Lq; Tue, 22 Mar 2011 23:52:45 +0000 Date: Tue, 22 Mar 2011 16:52:44 -0700 Message-ID: <m2vczasofn.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Jakob Heitz <jakob.heitz@ericsson.com> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> <C9AE8049.1B2CB%keyupate@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@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 <keyupate@cisco.com>, IETF, IDR <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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:51:16 -0000 > 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. randy From raszuk@cisco.com Tue Mar 22 16:51:54 2011 Return-Path: <raszuk@cisco.com> 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 720C628C17E for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:51:54 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6m2Lfajik+u for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:51:53 -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 8343A28C17B for <idr@ietf.org>; Tue, 22 Mar 2011 16:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=442; q=dns/txt; s=iport; t=1300838007; x=1302047607; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=KDwGU3yNEMBIRMtPHXyRqa6E2nEbLzxtjL9uq8SEksU=; b=FZPIK7UhgZhV8J4ZAz2aH81SAqutKsHVIbPTS3Hv+Qra47xqoggeZwDH hT02MbMyGlZjHq1+/8VwEbLLBhpv3+KM6SnAhu1lZkdA0ZRaP/4UBrQSy wP4DdvMp+Q2vMRigcVbhLRiKycUXBcdbLsd7pHZWoYfEL7Tzo7m6SrlWQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMHAHfTiE2rRDoH/2dsb2JhbACYS4x3d4hNoFSCbg4BmRCFaASMa4NS X-IronPort-AV: E=Sophos;i="4.63,228,1299456000"; d="scan'208";a="669637588" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 22 Mar 2011 23:53:27 +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 p2MNrQc3018538 for <idr@ietf.org>; Tue, 22 Mar 2011 23:53:26 GMT Message-ID: <4D893677.3050201@cisco.com> Date: Wed, 23 Mar 2011 00:53:27 +0100 From: Robert Raszuk <raszuk@cisco.com> 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: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> <C9AE8049.1B2CB%keyupate@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.eamcs.ericsson.se> 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.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:51:54 -0000 Hi Jakob, > 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. It would be so clean and simple ... I 100% agree with your proposal. To make max BGP Message size of X and max BGP Update Msg of Y where Y < X. We could talk what the Y and X should be. Cheers, R. From jsw@inconcepts.biz Tue Mar 22 16:53:19 2011 Return-Path: <jsw@inconcepts.biz> 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 4DDD228C16D for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 2h0Fb29LWHz5 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:53:18 -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 54D1D28C105 for <idr@ietf.org>; Tue, 22 Mar 2011 16:53:18 -0700 (PDT) Received: by vxg33 with SMTP id 33so6976521vxg.31 for <idr@ietf.org>; Tue, 22 Mar 2011 16:54:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.53.132 with SMTP id m4mr1465520vcg.8.1300838091540; Tue, 22 Mar 2011 16:54:51 -0700 (PDT) Received: by 10.220.185.134 with HTTP; Tue, 22 Mar 2011 16:54:51 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> Date: Tue, 22 Mar 2011 19:54:51 -0400 Message-ID: <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> From: Jeff Wheeler <jsw@inconcepts.biz> 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:53:19 -0000 On Tue, Mar 22, 2011 at 6:50 PM, Ilya Varlashkin <ilya@nobulus.com> wrote: > I don't share view that truncation is acceptable. As an operator I would = like to see whole message that caused the problem. So you want the neighbor to encapsulate a problematic message within another message that indicates a problem. This is not a bad thing to want, but there are only three ways to get there: 1) define two different maximum message sizes, one for "signaling" and one for "diagnostic" 2) change the header format to indicate "signaling" disposition vs "diagnostic" disposition and don't encapsulate at all 3) fragment/reassemble Even if you decide to reduce the proposed maximum message size from 65535 to 64000 this will not change the fact that an erroneous signaling message which is 64000 bytes long could not be encapsulated into a diagnostic message without violating the maximum message length. You can't "have your cake and eat it, too." I suggest you pick some of these possible options and argue your position. My opinion is that the possibility of truncated diagnostic messages is better than any of the three alternatives above. If I had to choose one, I'd pick #1, above, which is the least complex to implement. The only reason this looks like a kludge is because anything will be unless the header format is modified, which is clearly not desirable. --=20 Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator=A0 /=A0 Innovative Network Concepts From cjeker@diehard.n-r-g.com Tue Mar 22 16:59:54 2011 Return-Path: <cjeker@diehard.n-r-g.com> 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 D79B528C16D for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.625, 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 eVX3qqjsH82h for <idr@core3.amsl.com>; Tue, 22 Mar 2011 16:59:54 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id B444A28C0F8 for <idr@ietf.org>; Tue, 22 Mar 2011 16:59:53 -0700 (PDT) Received: (qmail 6884 invoked by uid 1001); 23 Mar 2011 00:01:26 -0000 Date: Wed, 23 Mar 2011 01:01:26 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: idr@ietf.org Message-ID: <20110323000126.GA23996@diehard.n-r-g.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> <C9AE8049.1B2CB%keyupate@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.eamcs.ericsson.se> 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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Mar 2011 23:59:55 -0000 On Tue, Mar 22, 2011 at 07:44:26PM -0400, Jakob Heitz wrote: > How about some numbers: > maximm message size = 65000 > maximum update message size = 64000 These two need to be maximum recv size and an maximum send size (unless it is one of the special BGP messages that may carry another message). The maximum send size is not a hard limit but more of a line that should not be crossed when generating messages. Still this does not protect from encapsulation issues. So the important question to solve is what happens when an update exceeds the maximum message size (be it 4096, or any other new number)? IIRC neither RFC 4271 nor any other RFC define a behaviour for this case. > 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. > -- :wq Claudio From ilya@nobulus.com Tue Mar 22 17:08:25 2011 Return-Path: <ilya@nobulus.com> 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 7441028C154 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 17:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 a5wmltZJ6eqD for <idr@core3.amsl.com>; Tue, 22 Mar 2011 17:08:24 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 4FD9128C0F8 for <idr@ietf.org>; Tue, 22 Mar 2011 17:08:24 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 64C1C17129; Wed, 23 Mar 2011 01:09:57 +0100 (CET) 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 ms9hCNzDaEA1; Wed, 23 Mar 2011 01:09:55 +0100 (CET) Received: from c3b41984.dsl.de.easynet.net (C3B41984.dsl.de.easynet.net [195.180.25.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id EEB92170C3; Wed, 23 Mar 2011 01:09:54 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin <ilya@nobulus.com> In-Reply-To: <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> Date: Wed, 23 Mar 2011 01:09:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> To: Jeff Wheeler <jsw@inconcepts.biz> X-Mailer: Apple Mail (2.1082) 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 00:08:25 -0000 On Mar 23, 2011, at 24:54 , Jeff Wheeler wrote: > 1) define two different maximum message sizes, one for "signaling" and > one for "diagnostic" > 2) change the header format to indicate "signaling" disposition vs > "diagnostic" disposition and don't encapsulate at all > 3) fragment/reassemble >=20 I prefer option (1) and got feeling that this is what we're discussing, = not merely reducing general max_size. With opt 2 & 3 there is danger = that single message/fragment is all what's going to reach other end = while TCP connection is still open. The reason why I would like whole messages is because I've seen messages = that caused session reset, but the part that was sent inside = notification looked perfectly fine. And from Robert's hint looks like = there are other operators that share same view. /iLya From randy@psg.com Tue Mar 22 17:10:34 2011 Return-Path: <randy@psg.com> 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 2863228C16D for <idr@core3.amsl.com>; Tue, 22 Mar 2011 17:10:34 -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 4Di-bvYwSJeR for <idr@core3.amsl.com>; Tue, 22 Mar 2011 17:10:33 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 8111D28C154 for <idr@ietf.org>; Tue, 22 Mar 2011 17:10:33 -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 <randy@psg.com>) id 1Q2BgD-000NkC-Ue; Wed, 23 Mar 2011 00:12:06 +0000 Date: Tue, 22 Mar 2011 17:12:05 -0700 Message-ID: <m2tyeusnje.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Claudio Jeker <cjeker@diehard.n-r-g.com> In-Reply-To: <20110323000126.GA23996@diehard.n-r-g.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7B81@EUSAACMS0701.eamcs.ericsson.se> <C9AE8049.1B2CB%keyupate@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F3D7BB9@EUSAACMS0701.eamcs.ericsson.se> <20110323000126.GA23996@diehard.n-r-g.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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 00:10:34 -0000 i suggest that any hard specified limits, extra bytes, ... you want to diddle around 64k also be applied retroactively to 4k. clearly all the same so-called logic should apply. and maybe you will find it easier to think of all this as the draft having a secret limit of 128k, but the 64k was whittled down to allow all the cruft you seem to want to invent. :) randy From randy@psg.com Tue Mar 22 17:26:30 2011 Return-Path: <randy@psg.com> 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 6CD6B28C16D for <idr@core3.amsl.com>; Tue, 22 Mar 2011 17:26:30 -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 Z8lynCU++eoC for <idr@core3.amsl.com>; Tue, 22 Mar 2011 17:26:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id A607728C0F8 for <idr@ietf.org>; Tue, 22 Mar 2011 17:26:29 -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 <randy@psg.com>) id 1Q2Bvd-000Nnk-EE; Wed, 23 Mar 2011 00:28:01 +0000 Date: Tue, 22 Mar 2011 17:28:00 -0700 Message-ID: <m2pqpismsv.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Ilya Varlashkin <ilya@nobulus.com> In-Reply-To: <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 00:26:30 -0000 >> 1) define two different maximum message sizes, one for "signaling" and >> one for "diagnostic" > I prefer option (1) and got feeling that this is what we're > discussing but one would think you would discuss it in the designs and drafts which differentiate between signaling and diagnostics. this draft does not can can not, as it can not predict all the kink the compexifornicans will come up with in the next N years. and "oh, let's throw 592.4 bytes at it, surely it will be enough," philosophy should be embarrassing. any hard coded fudge will turn out to be wrong. randy From jsw@inconcepts.biz Tue Mar 22 17:34:39 2011 Return-Path: <jsw@inconcepts.biz> 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 BCB803A6847 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 17:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 zEf5cyB+RraY for <idr@core3.amsl.com>; Tue, 22 Mar 2011 17:34:39 -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 CFA1F3A6843 for <idr@ietf.org>; Tue, 22 Mar 2011 17:34:38 -0700 (PDT) Received: by vxg33 with SMTP id 33so6992052vxg.31 for <idr@ietf.org>; Tue, 22 Mar 2011 17:36:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.137 with SMTP id dg9mr3354180vdc.221.1300840571819; Tue, 22 Mar 2011 17:36:11 -0700 (PDT) Received: by 10.220.185.134 with HTTP; Tue, 22 Mar 2011 17:36:11 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> Date: Tue, 22 Mar 2011 20:36:11 -0400 Message-ID: <AANLkTinvb4R-h8Yn7ObQp4E2Ksc2n-ZRE4SS+MOhkwj7@mail.gmail.com> From: Jeff Wheeler <jsw@inconcepts.biz> 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 00:34:39 -0000 On Tue, Mar 22, 2011 at 8:09 PM, Ilya Varlashkin <ilya@nobulus.com> wrote: > I prefer option (1) and got feeling that this is what we're discussing, n= ot merely reducing general max_size. With opt 2 & 3 there is danger that si= ngle message/fragment is all what's going to reach other end while TCP conn= ection is still open. > > The reason why I would like whole messages is because I've seen messages = that caused session reset, but the part that was sent inside notification l= ooked perfectly fine. And from Robert's hint looks like there are other ope= rators that share same I can buy into this argument. If this is the general consensus, the remaining question is, what should the maximum message size(s) be? I have no gripes with Jakob Heitz's numbers, 64K for "signaling" and 65K for "diagnostic." You could ask some questions: Question #1: why 64000 and not 65535? Why not 64000? My admittedly off-the-cuff understanding of the issue is that growing the maximum message size from 4096 to any of these values is an order-of-magnitude change, and if that isn't enough, then people should be advocating for more than 65535, not for the relatively inconsequential difference between 65535 and 64000. Like Randy says, maybe it could have been 128K; but unless someone is arguing in favor of a much bigger size, 64000 should suit pretty much anyone. IMO there should be no implementation difficulty which arises for a 64000 byte maximum size, and does not also arise for a 65535 maximum size. Question #2: why a difference of 1000 bytes for diagnostic encapsulation / "outer message?" Again, off-the-cuff, I think this could be as small as 19(?) bytes permitting only a single "outer message" for encapsulation. However, picking the minimum possible value would guarantee that this difference would have to change in the eventuality that the message header ever grows. Once again, if that 1000 bytes worth of extra payload space really matters to any application, then that application needs an advocate who is asking for more than one order of magnitude increase, i.e. they should not be any more satisfied with 65535 than they are with 64000, and the difference between 19 bytes and 1000 bytes is inconsequential. You folks will have to excuse me for writing "bytes" instead of "octets" or using the term "diagnostic message" where there may be a more appropriate one already in common use. Please feel free to read what I mean, not what I say. On Tue, Mar 22, 2011 at 8:28 PM, Randy Bush <randy@psg.com> wrote: > this draft does not can can not, as it can not predict all the kink the > compexifornicans will come up with in the next N years. =A0and "oh, let's > throw 592.4 bytes at it, surely it will be enough," philosophy should be > embarrassing. =A0any hard coded fudge will turn out to be wrong. I don't understand what your position is on this subject. Perhaps you could sum it up into favoring one or more of the proposals or opposing all of them in favor of truncation or message header modifications, or some other scheme you have in mind? --=20 Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator=A0 /=A0 Innovative Network Concepts From ilya@nobulus.com Tue Mar 22 17:42:42 2011 Return-Path: <ilya@nobulus.com> 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 484A13A684A for <idr@core3.amsl.com>; Tue, 22 Mar 2011 17:42:42 -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 dVxbRtm5plfc for <idr@core3.amsl.com>; Tue, 22 Mar 2011 17:42:41 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id E429B3A6847 for <idr@ietf.org>; Tue, 22 Mar 2011 17:42:40 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id E464817129; Wed, 23 Mar 2011 01:44:12 +0100 (CET) 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 bCJTI6T530b2; Wed, 23 Mar 2011 01:44:09 +0100 (CET) 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 950E7170F9; Wed, 23 Mar 2011 01:44:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin <ilya@nobulus.com> In-Reply-To: <m2pqpismsv.wl%randy@psg.com> Date: Wed, 23 Mar 2011 01:44:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <A24259B5-BBA4-4C30-A58A-A1061DC2F04D@nobulus.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> <m2pqpismsv.wl%randy@psg.com> To: IETF IDR <idr@ietf.org>, Randy Bush <randy@psg.com> X-Mailer: Apple Mail (2.1082) 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 00:42:42 -0000 After brief off-the-list conversation I agree with Keyur and with Randy = regarding generalizing only on "MUST leave room for encapsulating this = message inside a message that can ever come from _direct peer_" (i.e. = without specifying by how much less certain messages must be). To add = context: Speaker A has negotiated some set of Capability Codes with = Speaker B and therefore it's granted that Speaker A knows what Speaker B = can potentially send, so Speaker A can calculate how much room to leave. = Such approach paves the way for any further protocol enhancements while = satisfying basic operators' need - to ensure that diag messages will = contain complete version of the message that caused problem. /iLya On Mar 23, 2011, at 01:28 , Randy Bush wrote: >>> 1) define two different maximum message sizes, one for "signaling" = and >>> one for "diagnostic" >> I prefer option (1) and got feeling that this is what we're >> discussing >=20 > but one would think you would discuss it in the designs and drafts = which > differentiate between signaling and diagnostics. >=20 > this draft does not can can not, as it can not predict all the kink = the > compexifornicans will come up with in the next N years. and "oh, = let's > throw 592.4 bytes at it, surely it will be enough," philosophy should = be > embarrassing. any hard coded fudge will turn out to be wrong. >=20 > randy >=20 /iLya From randy@psg.com Tue Mar 22 20:58:31 2011 Return-Path: <randy@psg.com> 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 AEA343A68A2 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 20:58:31 -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 tr2HUQy16o0w for <idr@core3.amsl.com>; Tue, 22 Mar 2011 20:58:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 9BD453A6884 for <idr@ietf.org>; Tue, 22 Mar 2011 20:58:30 -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 <randy@psg.com>) id 1Q2FEp-000Otn-8U; Wed, 23 Mar 2011 04:00:03 +0000 Date: Tue, 22 Mar 2011 21:00:02 -0700 Message-ID: <m2oc52sczh.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Jeff Wheeler <jsw@inconcepts.biz> In-Reply-To: <AANLkTinvb4R-h8Yn7ObQp4E2Ksc2n-ZRE4SS+MOhkwj7@mail.gmail.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> <AANLkTinvb4R-h8Yn7ObQp4E2Ksc2n-ZRE4SS+MOhkwj7@mail.gmail.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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 03:58:31 -0000 >> The reason why I would like whole messages is because I've seen >> messages that caused session reset, but the part that was sent inside >> notification looked perfectly fine. And from Robert's hint looks like >> there are other operators that share same > I can buy into this argument. If this is the general consensus, the > remaining question is, what should the maximum message size(s) be? no. the question is to what size a bgp sender interested in a whole error response should limit it's outgoing message given that the max response message size will be 4k or 64k. the answer is that this draft should not care. it is the documentation of the encapsulation which needs to say, "if you want my whole response, then limit your outgoing message size to the agreed max, 4k or 64k, less the encaps overhead which is 19.3, or whatever. randy From randy@psg.com Tue Mar 22 20:59:36 2011 Return-Path: <randy@psg.com> 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 53E5928C0F7 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 20:59:36 -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 bII3Ug-mQ6Cl for <idr@core3.amsl.com>; Tue, 22 Mar 2011 20:59:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 9537628C0EF for <idr@ietf.org>; Tue, 22 Mar 2011 20:59:35 -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 <randy@psg.com>) id 1Q2FFt-000OuF-8F; Wed, 23 Mar 2011 04:01:09 +0000 Date: Tue, 22 Mar 2011 21:01:08 -0700 Message-ID: <m2mxkmscxn.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Ilya Varlashkin <ilya@nobulus.com> In-Reply-To: <A24259B5-BBA4-4C30-A58A-A1061DC2F04D@nobulus.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> <m2pqpismsv.wl%randy@psg.com> <A24259B5-BBA4-4C30-A58A-A1061DC2F04D@nobulus.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: IETF IDR <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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 03:59:36 -0000 > After brief off-the-list conversation I agree with Keyur and with > Randy regarding generalizing only on "MUST leave room for > encapsulating this message inside a message that can ever come from > _direct peer_" (i.e. without specifying by how much less certain > messages must be). To add context: Speaker A has negotiated some set > of Capability Codes with Speaker B and therefore it's granted that > Speaker A knows what Speaker B can potentially send, so Speaker A can > calculate how much room to leave. Such approach paves the way for any > further protocol enhancements while satisfying basic operators' need - > to ensure that diag messages will contain complete version of the > message that caused problem. yes. precisely. randy From jsw@inconcepts.biz Tue Mar 22 23:34:58 2011 Return-Path: <jsw@inconcepts.biz> 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 3BA3D3A67C0 for <idr@core3.amsl.com>; Tue, 22 Mar 2011 23:34:58 -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, 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 c4Rf4e-3zteq for <idr@core3.amsl.com>; Tue, 22 Mar 2011 23:34:57 -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 3BFAD3A68F9 for <idr@ietf.org>; Tue, 22 Mar 2011 23:34:57 -0700 (PDT) Received: by vws12 with SMTP id 12so6619491vws.31 for <idr@ietf.org>; Tue, 22 Mar 2011 23:36:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.137 with SMTP id dg9mr3639027vdc.221.1300862190696; Tue, 22 Mar 2011 23:36:30 -0700 (PDT) Received: by 10.220.185.134 with HTTP; Tue, 22 Mar 2011 23:36:30 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <m2oc52sczh.wl%randy@psg.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> <AANLkTinvb4R-h8Yn7ObQp4E2Ksc2n-ZRE4SS+MOhkwj7@mail.gmail.com> <m2oc52sczh.wl%randy@psg.com> Date: Wed, 23 Mar 2011 02:36:30 -0400 Message-ID: <AANLkTinEEAfkboB6gQV+Air0bEq1ULJQUrDP_Ma+i8zO@mail.gmail.com> From: Jeff Wheeler <jsw@inconcepts.biz> 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 06:34:58 -0000 On Wed, Mar 23, 2011 at 12:00 AM, Randy Bush <randy@psg.com> wrote: > it is the documentation of the encapsulation which needs to say, "if you > want my whole response, then limit your outgoing message size to the > agreed max, 4k or 64k, less the encaps overhead which is 19.3, or Is your position then that you have more confidence in vendors correctly implementing the above behavior than in same vendors dealing with two distinct maximum message sizes, one for "signaling" and one for "diagnostic?" I still have "off by twenty" BGP-related bugs that I've reported to vendors many years ago, which have not and probably will not be fixed. My opinion is that two distinct sizes is more likely to be correctly implemented without introducing new bugs. Instead of vendors' BGP implementations correctly reducing the maximum "signaling message" size to account for encapsulation of same messages within a diagnostic outer-message header, the kinds of related bugs I foresee are: 1) failing to reduce signaling message size 1a) resulting in truncation of related diagnostic messages; or 1b) resulting in too-long diagnostic messages which violate the single maximum message size 2) incorrectly reducing signaling message size too much 3) incorrectly applying the reduced signaling message size to diagnostic messages I think we disagree on a basic issue here. If I were Ilya, and cared a lot about receiving the whole offending message in case of trouble, I would want there to be few obstacles standing in the way of vendors getting that right. In both cases, we're really talking about the same thing -- two different maximum message sizes. Yours comes up with two different sizes by way of calculating the exact encapsulation overhead needed and reducing signaling message size as appropriate. Jakob Heitz' notion simply spells out two distinct constants. --=20 Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator=A0 /=A0 Innovative Network Concepts From randy@psg.com Wed Mar 23 00:50:18 2011 Return-Path: <randy@psg.com> 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 6011D3A690B for <idr@core3.amsl.com>; Wed, 23 Mar 2011 00:50:18 -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 Ybi3+TYAXJ41 for <idr@core3.amsl.com>; Wed, 23 Mar 2011 00:50:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id ADB0F3A6900 for <idr@ietf.org>; Wed, 23 Mar 2011 00:50:17 -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 <randy@psg.com>) id 1Q2Ipv-000PPH-Ob; Wed, 23 Mar 2011 07:50:35 +0000 Date: Wed, 23 Mar 2011 00:50:35 -0700 Message-ID: <m21v1ys2b8.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Jeff Wheeler <jsw@inconcepts.biz> In-Reply-To: <AANLkTinEEAfkboB6gQV+Air0bEq1ULJQUrDP_Ma+i8zO@mail.gmail.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> <AANLkTinvb4R-h8Yn7ObQp4E2Ksc2n-ZRE4SS+MOhkwj7@mail.gmail.com> <m2oc52sczh.wl%randy@psg.com> <AANLkTinEEAfkboB6gQV+Air0bEq1ULJQUrDP_Ma+i8zO@mail.gmail.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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 07:50:18 -0000 > Is your position then that you have more confidence in vendors > correctly implementing the above behavior than in same vendors dealing > with two distinct maximum message sizes, one for "signaling" and one > for "diagnostic?" i have far more confidence in vendors correctly implementing a simple and clear spec than a shotgun crap-shoot of second-guessing and wild estimation. this week it's diagnostics. next meeting it will be bgp wrapped mpls encapsulated dns rrs of ssh keys of routers. it makes zero sense to rev this document for every allegedly bright idea that comes down the idr septic pipe. this document is a simple statement of pdu max. folk who want to do exciting things can keep the excitement in their documents. randy From jsw@inconcepts.biz Wed Mar 23 04:10:04 2011 Return-Path: <jsw@inconcepts.biz> 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 7A8393A681C for <idr@core3.amsl.com>; Wed, 23 Mar 2011 04:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 TqYwsQLsKsQz for <idr@core3.amsl.com>; Wed, 23 Mar 2011 04:10:03 -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 676C33A681A for <idr@ietf.org>; Wed, 23 Mar 2011 04:10:03 -0700 (PDT) Received: by vxg33 with SMTP id 33so7283251vxg.31 for <idr@ietf.org>; Wed, 23 Mar 2011 04:11:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.96.161 with SMTP id dt1mr1359653vdb.261.1300878696921; Wed, 23 Mar 2011 04:11:36 -0700 (PDT) Received: by 10.220.185.134 with HTTP; Wed, 23 Mar 2011 04:11:36 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <m21v1ys2b8.wl%randy@psg.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> <AANLkTinvb4R-h8Yn7ObQp4E2Ksc2n-ZRE4SS+MOhkwj7@mail.gmail.com> <m2oc52sczh.wl%randy@psg.com> <AANLkTinEEAfkboB6gQV+Air0bEq1ULJQUrDP_Ma+i8zO@mail.gmail.com> <m21v1ys2b8.wl%randy@psg.com> Date: Wed, 23 Mar 2011 07:11:36 -0400 Message-ID: <AANLkTikmY2fu9PmTTFiF6sM0FVZ_QUcxsZLeyePFe=cU@mail.gmail.com> From: Jeff Wheeler <jsw@inconcepts.biz> 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 11:10:04 -0000 On Wed, Mar 23, 2011 at 3:50 AM, Randy Bush <randy@psg.com> wrote: > i have far more confidence in vendors correctly implementing a simple > and clear spec than a shotgun crap-shoot of second-guessing and wild > estimation. If this is the case, then your spec should be simple and clear, and should not contain language such as this: >Applications generating messages which might be encapsulated within >BGP messages MUST be aware of the maximum message size and all >encapsulation overheads on the path the encapsulated data are >expected to traverse. As has been demonstrated on this thread, "all encapsulation overheads on the path the encapsulated data are expected to traverse" may lead some implementing persons to believe that means it must account for transport (TCP) overhead, which is unrelated to the maximum size of the BGP message. Perhaps you should revise your proposal to state: =3DApplications generating messages which are nested within BGP outer-messages, such as diagnostic notifications, must be aware that the maximum message size applies to the outer-most BGP message. Applications relying on a BGP neighbor's ability to encapsulate a transmitted message within an outer-header and echo it back must further reduce the maximum size to account for the outer-header size and any additional data payload. Two different message sizes is also quite simple and clear. If you're having trouble wrapping your head around this, I suggest you think about it from the perspective of the programmer implementing BGP on his employer's router. Standards documents must not be goals in and of themselves; they should be tools for getting from "feature customers want" to "bullet point on vendor datasheet" using a common and inter-operable mechanism. How will Mr Programmer decide to implement Ilya's desire to receive whole-message diagnostic messages in response to bad/unhandled signaling messages? Probably, he's going to pass this message to a distinct subroutine that wraps it up in the outer-message and sticks it in the output queue. This subroutine is going to have to do a bounds check against the maximum payload size it is allowed to send to the neighbor. It can either check against a computed payload size which the vendor will probably get right, because it's not that hard to subtract 19 from the maximum message size for the neighbor; or it can check against a constant that has less opportunity for mistakes and some "wiggle room" for catching cases where the offending neighbor has accidentally sent a "too big" message and reporting that to said neighbor. You say this is a "crap-shoot of second-guessing." I say it's quite reasonable to draw a distinction between signalling and notification/diagnostic messages, and to include in the diagnostic process a buffer against bugs. After all, the diagnostic message Ilya wants will very likely be in response to bugs on one side or the other, be they capabilities negotiation / interpretation failures, off-by-ones (or twenties), or whatever. > this week it's diagnostics. =A0next meeting it will be bgp wrapped mpls > encapsulated dns rrs of ssh keys of routers. =A0it makes zero sense to re= v > this document for every allegedly bright idea that comes down the idr > septic pipe. =A0this document is a simple statement of pdu max. =A0folk w= ho > want to do exciting things can keep the excitement in their documents. There must be someone who appreciates your larger-than-life examples of why this is some kind of slippery slope. I don't, and I take these to mean that you do not have a realistic and practical example of how this is somehow unwise, dangerous, or more difficult for vendors to implement, either now or in a future which doesn't require suspending disbelief. If you want to define what are supposed to be industry-standards based on an irrational fear of wrapping some "mpls encapsulated dns rrs of ssh keys of routers" inside BGP messages, I suggest you work harder on getting "The Social Network 2: The Standards-Track" green-lit, because that kind of imaginative but utterly baseless argument is not beneficial to the operators or the vendors. The fact that "contributions" like your outlandish example sometimes drive the standards process is deplorable. --=20 Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator=A0 /=A0 Innovative Network Concepts From paul@jakma.org Wed Mar 23 04:13:08 2011 Return-Path: <paul@jakma.org> 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 216353A682E for <idr@core3.amsl.com>; Wed, 23 Mar 2011 04:13:08 -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 kFnSWXHt+uxH for <idr@core3.amsl.com>; Wed, 23 Mar 2011 04:13:07 -0700 (PDT) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by core3.amsl.com (Postfix) with ESMTP id D2E1C3A6817 for <idr@ietf.org>; Wed, 23 Mar 2011 04:13:06 -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 p2NBDwYg025316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2011 11:14:02 GMT Date: Wed, 23 Mar 2011 11:13:52 +0000 (GMT) From: Paul Jakma <paul@jakma.org> X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Ilya Varlashkin <ilya@nobulus.com> In-Reply-To: <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> Message-ID: <alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> 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; format=flowed; charset=US-ASCII Cc: IETF IDR <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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 11:13:08 -0000 On Tue, 22 Mar 2011, Ilya Varlashkin wrote: > If we can agree on the above, then second issue to resolve is which > messages are allowed to be MAX_SIZEd and which should allow room > for other encapsulations. And finally we need to agree how much > room exactly to leave. The core problem is having a limit in the underlying transport (which happens to be the same protocol). Of course it's quite possible to remove limits (use a length field with a width large enough to make the problem go away effectively for ever, or instead remove the need for pre-determined length and use an end delimiter). Alternatively, define a fragmentation capable encapsulation for BGP. (Warning: This message has been made in a factory that handles dead-pan humour). regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: Where humor is concerned there are no standards -- no one can say what is good or bad, although you can be sure that everyone will. -- John Kenneth Galbraith From rob.shakir@cw.com Wed Mar 23 04:30:13 2011 Return-Path: <rob.shakir@cw.com> 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 8D8793A681C for <idr@core3.amsl.com>; Wed, 23 Mar 2011 04:30:13 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYrXdqehcYX5 for <idr@core3.amsl.com>; Wed, 23 Mar 2011 04:30:12 -0700 (PDT) Received: from service98.mimecast.com (service98.mimecast.com [195.130.217.59]) by core3.amsl.com (Postfix) with ESMTP id 0FDEB3A6818 for <idr@ietf.org>; Wed, 23 Mar 2011 04:30:11 -0700 (PDT) Received: from GBCWSWIEC002.ad.plc.cwintra.com (cmr2.cwplc.com [213.216.141.97]) (Using TLS) by service98.mimecast.com; Wed, 23 Mar 2011 11:31:26 +0000 Received: from GBVDCEM001.ad.plc.cwintra.com ([10.196.134.34]) by GBCWSWIEC002.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Mar 2011 11:31:01 +0000 Received: from [10.154.33.32] ([10.154.33.32]) by GBVDCEM001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Mar 2011 11:31:00 +0000 Mime-Version: 1.0 (Apple Message framework v1082) From: Rob Shakir <rob.shakir@cw.com> In-Reply-To: <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> Date: Wed, 23 Mar 2011 11:31:00 +0000 Message-Id: <848FE76D-4C0C-4B39-B224-A61E4E5443A5@cw.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> To: Ilya Varlashkin <ilya@nobulus.com> X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 23 Mar 2011 11:31:00.0963 (UTC) FILETIME=[C9536330:01CBE94D] X-MC-Unique: 111032311312600401 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 11:30:13 -0000 On 23 Mar 2011, at 00:09, Ilya Varlashkin wrote: > The reason why I would like whole messages is because I've seen messages = that caused session reset, but the part that was sent inside notification l= ooked perfectly fine. And from Robert's hint looks like there are other ope= rators that share same view. Hi Ilya, IDR, Just to add some further voice to this, and add my =A30.02, I am an operato= r that cares about the above - for the same reasons that Ilya highlighted i= n this thread. Partial message replay in the case that an erroneous or corr= upt packet is received really limits the utility of such mechanisms. > After brief off-the-list conversation I agree with Keyur and with Randy r= egarding generalizing only on "MUST leave room for encapsulating this messa= ge inside a message that can ever come from _direct peer_" (i.e. without sp= ecifying by how much less certain messages must be). To add context: Speake= r A has negotiated some set of Capability Codes with Speaker B and therefor= e it's granted that Speaker A knows what Speaker B can potentially send, so= Speaker A can calculate how much room to leave. Such approach paves the wa= y for any further protocol enhancements while satisfying basic operators' n= eed - to ensure that diag messages will contain complete version of the mes= sage that caused problem. It would seem to me that this wording provides the clearest specification, = and highlights the issue of message encapsulation without leaving the speci= fication with scope for revision on each change. As Randy says, for special= cases, it would seem that those extensions requiring this should handle th= e specific caveats of this within the relevant standard. Kind regards, r. This e-mail has been scanned for viruses by the Cable&Wireless Worldwide e-= mail security system. For more information on a proactive=20 managed e-mail secure service, visit http://www.cw.com/managed-exchange The information contained in this e-mail is confidential and may also be su= bject to legal privilege. It is intended only for the recipient(s) named ab= ove.=20 If you are not named above as a recipient, you must not read, copy, disclos= e, forward or otherwise use the information contained in this email. If you= =20 have received this e-mail in error, please notify the sender (whose contact= details are above) immediately by reply e-mail and delete the message and = any=20 attachments without retaining any copies. Cable & Wireless Worldwide plc=20 Registered in England and Wales. Company Number 07029206 Registered office: Liberty House, 76 Hammersmith Road, London W14 8UD, Engl= and From ilya@nobulus.com Wed Mar 23 04:33:24 2011 Return-Path: <ilya@nobulus.com> 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 956493A6836 for <idr@core3.amsl.com>; Wed, 23 Mar 2011 04:33: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN3vEIL5mLwd for <idr@core3.amsl.com>; Wed, 23 Mar 2011 04:33:23 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 4B8D53A6825 for <idr@ietf.org>; Wed, 23 Mar 2011 04:33:23 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 7852917159; Wed, 23 Mar 2011 12:34:56 +0100 (CET) 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 PWrHAdylghUs; Wed, 23 Mar 2011 12:34:54 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:4f2:5e1d:9c52:2712]) by nobulus.com (Postfix) with ESMTPA id 27E2417129; Wed, 23 Mar 2011 12:34:54 +0100 (CET) Message-ID: <A262EA093C8041DCBAEBC7D3193926B2@hnivarlas1> From: "iLya" <ilya@nobulus.com> To: "Paul Jakma" <paul@jakma.org> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk> In-Reply-To: <alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk> Date: Wed, 23 Mar 2011 12:34:53 +0100 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: IETF IDR <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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 11:33:24 -0000 -------------------------------------------------- > The core problem is having a limit in the underlying transport (which > happens to be the same protocol). Of course it's quite possible to remove > limits (use a length field with a width large enough to make the problem > go away effectively for ever, or instead remove the need for > pre-determined length and use an end delimiter). > > Alternatively, define a fragmentation capable encapsulation for BGP. > Besides the fact that fragmentation is evil, there is also third alternative to the above two, and that is what Keyur and Randy have brought up, and which after some consideration I perceive as solid and flexible. This alternative is to require BGP speaker to calculate maximum possible overhead (it _can_ do it based on agreed Capability Code set) for given peer (!) and use that value instead of predefined fixed size overhead. I do put exactly same level of trust in implementor following this requirement as I would in trusting implementor obeying fixed-sized overhead requirement. Kind regards, iLya From cjeker@diehard.n-r-g.com Wed Mar 23 05:10:56 2011 Return-Path: <cjeker@diehard.n-r-g.com> 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 D27933A6836 for <idr@core3.amsl.com>; Wed, 23 Mar 2011 05:10:56 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8gkAg8VhG2Z for <idr@core3.amsl.com>; Wed, 23 Mar 2011 05:10:53 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id 842D33A67FD for <idr@ietf.org>; Wed, 23 Mar 2011 05:10:51 -0700 (PDT) Received: (qmail 20570 invoked by uid 1001); 23 Mar 2011 12:12:17 -0000 Date: Wed, 23 Mar 2011 13:12:17 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: idr@ietf.org Message-ID: <20110323121217.GB30915@diehard.n-r-g.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> <848FE76D-4C0C-4B39-B224-A61E4E5443A5@cw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <848FE76D-4C0C-4B39-B224-A61E4E5443A5@cw.com> 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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 12:10:57 -0000 On Wed, Mar 23, 2011 at 11:31:00AM +0000, Rob Shakir wrote: > > On 23 Mar 2011, at 00:09, Ilya Varlashkin wrote: > > > The reason why I would like whole messages is because I've seen > > messages that caused session reset, but the part that was sent inside > > notification looked perfectly fine. And from Robert's hint looks like > > there are other operators that share same view. > > Hi Ilya, IDR, > > Just to add some further voice to this, and add my £0.02, I am an > operator that cares about the above - for the same reasons that Ilya > highlighted in this thread. Partial message replay in the case that an > erroneous or corrupt packet is received really limits the utility of > such mechanisms. > Just how many times did a 4096 byte long BGP message caused a notification for you? Isn't best effort good enough in such a rare case plus the error needs to be in the last few bytes of the update as well. As an implementor I need to say it is probably better to accept this instead of creating a complex system around it which is most probably more prone to fail then the problem it should actually solve. -- :wq Claudio From ilya@nobulus.com Wed Mar 23 05:22:15 2011 Return-Path: <ilya@nobulus.com> 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 625C03A682C for <idr@core3.amsl.com>; Wed, 23 Mar 2011 05:22:15 -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.001, BAYES_00=-2.599, STOX_REPLY_TYPE=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 ccvSet--TvNA for <idr@core3.amsl.com>; Wed, 23 Mar 2011 05:22:14 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 272133A67FD for <idr@ietf.org>; Wed, 23 Mar 2011 05:22:14 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 83B35170F9; Wed, 23 Mar 2011 13:23:47 +0100 (CET) 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 qnPP0vLm7Np0; Wed, 23 Mar 2011 13:23:45 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:4f2:5e1d:9c52:2712]) by nobulus.com (Postfix) with ESMTPA id 16FA7170CD; Wed, 23 Mar 2011 13:23:45 +0100 (CET) Message-ID: <F470CFD93F66443C8D780E3DAA0813CD@hnivarlas1> From: "iLya" <ilya@nobulus.com> To: "Claudio Jeker" <cjeker@diehard.n-r-g.com>, <idr@ietf.org> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com><m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com><20110322212324.GI9210@diehard.n-r-g.com><BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com><AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com><7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com><848FE76D-4C0C-4B39-B224-A61E4E5443A5@cw.com> <20110323121217.GB30915@diehard.n-r-g.com> In-Reply-To: <20110323121217.GB30915@diehard.n-r-g.com> Date: Wed, 23 Mar 2011 13:23:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 12:22:15 -0000 -------------------------------------------------- > Just how many times did a 4096 byte long BGP message caused a notification > for you? Isn't best effort good enough in such a rare case plus the error since we're talking here about extending message length far beyond original 4K octets, there's good chance that we will start seeing more of the large messages in the field (not necessary in the global IPv4/IPv6 tables), and since solution to address rised concern seems both feasible for implementors and satisfactory to operators then naturally it seems like a good thing to stick to. Kind regards, iLya From cjeker@diehard.n-r-g.com Wed Mar 23 05:47:40 2011 Return-Path: <cjeker@diehard.n-r-g.com> 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 ACEC43A6850 for <idr@core3.amsl.com>; Wed, 23 Mar 2011 05:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.417, 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 ASAC8rXxHgFJ for <idr@core3.amsl.com>; Wed, 23 Mar 2011 05:47:39 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id 6BC8D3A6836 for <idr@ietf.org>; Wed, 23 Mar 2011 05:47:39 -0700 (PDT) Received: (qmail 17205 invoked by uid 1001); 23 Mar 2011 12:49:08 -0000 Date: Wed, 23 Mar 2011 13:49:08 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: iLya <ilya@nobulus.com> Message-ID: <20110323124908.GC30915@diehard.n-r-g.com> References: <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> <848FE76D-4C0C-4B39-B224-A61E4E5443A5@cw.com> <20110323121217.GB30915@diehard.n-r-g.com> <F470CFD93F66443C8D780E3DAA0813CD@hnivarlas1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <F470CFD93F66443C8D780E3DAA0813CD@hnivarlas1> User-Agent: Mutt/1.5.21 (2010-09-15) 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 12:47:40 -0000 On Wed, Mar 23, 2011 at 01:23:44PM +0100, iLya wrote: > > -------------------------------------------------- > >Just how many times did a 4096 byte long BGP message caused a notification > >for you? Isn't best effort good enough in such a rare case plus the error > > since we're talking here about extending message length far beyond > original 4K octets, there's good chance that we will start seeing > more of the large messages in the field (not necessary in the global > IPv4/IPv6 tables), and since solution to address rised concern seems > both feasible for implementors and satisfactory to operators then > naturally it seems like a good thing to stick to. > Yes, but it is even less of an issue in the case larger messages are available. Currently it is possible to get all information into 4k and so from a math perspective making the maximum message size bigger will reduce the risk of truncation even more. Yes the 4k BGP message size is starting to cause problems but we're talking here about a new limit that is 16 times bigger. I don't want to know what kind of information needs to be added to make an update exceed even 32k. I hope that somewhen people will realize that BGP is not a kitchen sink. -- :wq Claudio From rob.shakir@cw.com Wed Mar 23 06:56:27 2011 Return-Path: <rob.shakir@cw.com> 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 A81023A6914 for <idr@core3.amsl.com>; Wed, 23 Mar 2011 06:56:27 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS+lXesQhtIb for <idr@core3.amsl.com>; Wed, 23 Mar 2011 06:56:26 -0700 (PDT) Received: from service98.mimecast.com (service98.mimecast.com [195.130.217.59]) by core3.amsl.com (Postfix) with ESMTP id 355713A690F for <idr@ietf.org>; Wed, 23 Mar 2011 06:56:25 -0700 (PDT) Received: from GBCWSWIEC002.ad.plc.cwintra.com (cmr2.cwplc.com [213.216.141.97]) (Using TLS) by service98.mimecast.com; Wed, 23 Mar 2011 13:57:53 +0000 Received: from GBVDCEM001.ad.plc.cwintra.com ([10.196.134.34]) by GBCWSWIEC002.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Mar 2011 13:56:25 +0000 Received: from [10.154.33.32] ([10.154.33.32]) by GBVDCEM001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Mar 2011 13:56:25 +0000 Mime-Version: 1.0 (Apple Message framework v1082) From: Rob Shakir <rob.shakir@cw.com> In-Reply-To: <20110323121217.GB30915@diehard.n-r-g.com> Date: Wed, 23 Mar 2011 13:56:24 +0000 Message-Id: <B7B17E02-11E8-4552-9A0C-C74228079855@cw.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <AANLkTinREiFAPZsFaXRvHpJL2u+nrVFvOrHty37oa=qz@mail.gmail.com> <7BF65DD6-CE0B-4425-A1EE-1AEA3C34E911@nobulus.com> <848FE76D-4C0C-4B39-B224-A61E4E5443A5@cw.com> <20110323121217.GB30915@diehard.n-r-g.com> To: Claudio Jeker <cjeker@diehard.n-r-g.com> X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 23 Mar 2011 13:56:25.0327 (UTC) FILETIME=[1973AFF0:01CBE962] X-MC-Unique: 111032313575309701 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 13:56:27 -0000 Hi Claudio, On 23 Mar 2011, at 12:12, Claudio Jeker wrote: > Just how many times did a 4096 byte long BGP message caused a notificatio= n > for you? Isn't best effort good enough in such a rare case plus the error > needs to be in the last few bytes of the update as well. As an implemento= r > I need to say it is probably better to accept this instead of creating a > complex system around it which is most probably more prone to fail then t= he > problem it should actually solve. We already know that this problem is relatively difficult for us to solve a= s operators - isolating a single message that is triggering NOTIFICATION is= not trivial within many live environments. The cost of not being able to s= olve this issue in some cases is high (where we have a high impact session = that is actually generating NOTIFICATION based on this message we cause out= ages to subsets of NLRI). I think should keep in mind that operational visi= bility of any protocol is key to being able to debug it correctly, therefor= e I would much prefer that we avoid generating some case whereby we have ca= ses that are harder to debug, especially those that are "edge" cases (such = as at the boundaries of available lengths). As such, I therefore think that= keeping the capability to support these cases is very useful. >From your view as an implementor, I'd be very interested to hear whether it= 's actually likely to be that one would introduce disproportionate complexi= ty by implementing some check as suggested by Ilya (i.e. I can receive a me= ssage of up to length X from my peer, therefore I should transmit messages = only up to X-N where N is the maximum length of the 'encapsulation' of the = message). From my (very na=EFve) view, it does not sound to exceed an accep= table level of complexity? Indeed, perhaps the most complex scenario is aro= und where one replicates a message to multiple neighbours, but in this case= , this is easily handled by selecting the minimum largest available message= size for a peer. > I hope that somewhen people will realize that BGP is not a > kitchen sink. This is a whole other debate ;-), which touches on scaleability, and networ= k deployment complexity. Unfortunately, I think we should rather deal with = the situation that BGP-4 provides a key signalling protocol to operators, r= ather than one based on aspirations away from this position. Kind regards, r. This e-mail has been scanned for viruses by the Cable&Wireless Worldwide e-= mail security system. For more information on a proactive=20 managed e-mail secure service, visit http://www.cw.com/managed-exchange The information contained in this e-mail is confidential and may also be su= bject to legal privilege. It is intended only for the recipient(s) named ab= ove.=20 If you are not named above as a recipient, you must not read, copy, disclos= e, forward or otherwise use the information contained in this email. If you= =20 have received this e-mail in error, please notify the sender (whose contact= details are above) immediately by reply e-mail and delete the message and = any=20 attachments without retaining any copies. Cable & Wireless Worldwide plc=20 Registered in England and Wales. Company Number 07029206 Registered office: Liberty House, 76 Hammersmith Road, London W14 8UD, Engl= and From ilya@nobulus.com Wed Mar 23 09:14:40 2011 Return-Path: <ilya@nobulus.com> 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 93BE73A6812 for <idr@core3.amsl.com>; Wed, 23 Mar 2011 09:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=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 d9mVADywsh2x for <idr@core3.amsl.com>; Wed, 23 Mar 2011 09:14:40 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id C03BA3A63CA for <idr@ietf.org>; Wed, 23 Mar 2011 09:14:39 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 6CC31170F9 for <idr@ietf.org>; Wed, 23 Mar 2011 17:16:12 +0100 (CET) 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 FkOBOwFDkatG for <idr@ietf.org>; Wed, 23 Mar 2011 17:16:10 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:4f2:5e1d:9c52:2712]) by nobulus.com (Postfix) with ESMTPA id 82825170CD for <idr@ietf.org>; Wed, 23 Mar 2011 17:16:10 +0100 (CET) Message-ID: <086D238C97E643AB9F9A5C9BACB913B0@hnivarlas1> From: "iLya" <ilya@nobulus.com> To: <idr@ietf.org> Date: Wed, 23 Mar 2011 17:16:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original 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 Subject: [Idr] draft-varlashkin-bgp-nh-cost-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Mar 2011 16:14:40 -0000 Hi, Next-Hop SAFI draft has been updated with couple usage scenarios - http://tools.ietf.org/html/draft-varlashkin-bgp-nh-cost-01. Comments/questions will be appreciated. Kind regards, iLya From david.freedman@uk.clara.net Thu Mar 24 05:46:02 2011 Return-Path: <david.freedman@uk.clara.net> 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 16FF328C0EE for <idr@core3.amsl.com>; Thu, 24 Mar 2011 05:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, 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 ORLNs0fpMJwo for <idr@core3.amsl.com>; Thu, 24 Mar 2011 05:46:01 -0700 (PDT) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by core3.amsl.com (Postfix) with ESMTP id CE03728C0E0 for <idr@ietf.org>; Thu, 24 Mar 2011 05:46:00 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.72) (envelope-from <david.freedman@uk.clara.net>) id 1Q2jwT-0004uZ-4U for idr@ietf.org; Thu, 24 Mar 2011 12:47:09 +0000 Message-ID: <4D8B3D4D.8060107@uk.clara.net> Date: Thu, 24 Mar 2011 12:47:09 +0000 From: David Freedman <david.freedman@uk.clara.net> 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 <idr@ietf.org> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk> <A262EA093C8041DCBAEBC7D3193926B2@hnivarlas1> In-Reply-To: <A262EA093C8041DCBAEBC7D3193926B2@hnivarlas1> X-Enigmail-Version: 1.0.1 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] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Mar 2011 12:46:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/03/11 11:34, iLya wrote: >> > > Besides the fact that fragmentation is evil, there is also third > alternative to the above two, and that is what Keyur and Randy have > brought up, and which after some consideration I perceive as solid and > flexible. This alternative is to require BGP speaker to calculate > maximum possible overhead (it _can_ do it based on agreed Capability > Code set) for given peer (!) and use that value instead of predefined > fixed size overhead. I do put exactly same level of trust in implementor > following this requirement as I would in trusting implementor obeying > fixed-sized overhead requirement. I think the capability-value should be used to define the max-message-size, so the implementer can decide what they are happy (and competent) to accept and process. I also don't see a need for symmetry either. If the situation arises where an implementation decides it really needs to send a message its peer which is larger than the peer's max-message-size (either through evaluation of the cap-value or lack of cap) then it could either send a NOTIFICATION (if the message was critical to operation) or ADVISORY (yet another use case) with an optional summary of the message contained. Dave. - -- David Freedman Claranet -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2LPUwACgkQtFWeqpgEZrJa/wCfYee9U9OtHvPKr2oOPD64wYrf aQYAnRky55RnNZC+tQI4OBkpcCIMEcUL =iBTX -----END PGP SIGNATURE----- From jakob.heitz@ericsson.com Thu Mar 24 06:03:24 2011 Return-Path: <jakob.heitz@ericsson.com> 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 B052B28C0E0 for <idr@core3.amsl.com>; Thu, 24 Mar 2011 06:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 N08Iv3bESd7F for <idr@core3.amsl.com>; Thu, 24 Mar 2011 06:03:23 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 91EED3A684E for <idr@ietf.org>; Thu, 24 Mar 2011 06:03:23 -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 p2OD4HBJ024894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Mar 2011 08:04:57 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 24 Mar 2011 09:03:53 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: David Freedman <david.freedman@uk.clara.net> Date: Thu, 24 Mar 2011 09:03:48 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: AcvqI+xsE9Q8TircTeSDyQ11F68Sug== Message-ID: <3BFE0A33-4772-46B0-AFA3-489BB4425FE8@ericsson.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk> <A262EA093C8041DCBAEBC7D3193926B2@hnivarlas1> <4D8B3D4D.8060107@uk.clara.net> In-Reply-To: <4D8B3D4D.8060107@uk.clara.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 Cc: idr <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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Mar 2011 13:03:24 -0000 I hope you don't mean to put the actual value into the capability. Then I'l= l have 1000 different peers with 1000 different sizes. What a nightmare of = code that would be, for no good reason. You will be sure to get a few malfo= rmed then.=20 -- Jakob Heitz. On Mar 24, 2011, at 5:47 AM, "David Freedman" <david.freedman@uk.clara.net>= wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 23/03/11 11:34, iLya wrote: >>>=20 >>=20 >> Besides the fact that fragmentation is evil, there is also third >> alternative to the above two, and that is what Keyur and Randy have >> brought up, and which after some consideration I perceive as solid and >> flexible. This alternative is to require BGP speaker to calculate >> maximum possible overhead (it _can_ do it based on agreed Capability >> Code set) for given peer (!) and use that value instead of predefined >> fixed size overhead. I do put exactly same level of trust in implementor >> following this requirement as I would in trusting implementor obeying >> fixed-sized overhead requirement. >=20 > I think the capability-value should be used to define the > max-message-size, so the implementer can decide what they are happy (and > competent) to accept and process. >=20 > I also don't see a need for symmetry either. >=20 > If the situation arises where an implementation decides it really needs > to send a message its peer which is larger than the peer's > max-message-size (either through evaluation of the cap-value or lack of > cap) then it could either send a NOTIFICATION (if the message was > critical to operation) or ADVISORY (yet another use case) > with an optional summary of the message contained. >=20 > Dave. >=20 > - --=20 >=20 > David Freedman > Claranet > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk2LPUwACgkQtFWeqpgEZrJa/wCfYee9U9OtHvPKr2oOPD64wYrf > aQYAnRky55RnNZC+tQI4OBkpcCIMEcUL > =3DiBTX > -----END PGP SIGNATURE----- > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From david.freedman@uk.clara.net Thu Mar 24 06:10:23 2011 Return-Path: <david.freedman@uk.clara.net> 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 4943528C0F1 for <idr@core3.amsl.com>; Thu, 24 Mar 2011 06:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 Ojjg0TGTpsKU for <idr@core3.amsl.com>; Thu, 24 Mar 2011 06:10:22 -0700 (PDT) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by core3.amsl.com (Postfix) with ESMTP id 1B96B3A68A2 for <idr@ietf.org>; Thu, 24 Mar 2011 06:10:21 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.72) (envelope-from <david.freedman@uk.clara.net>) id 1Q2kKF-0004y1-Ux; Thu, 24 Mar 2011 13:11:43 +0000 Message-ID: <4D8B430F.8030501@uk.clara.net> Date: Thu, 24 Mar 2011 13:11:43 +0000 From: David Freedman <david.freedman@uk.clara.net> 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: Jakob Heitz <jakob.heitz@ericsson.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk> <A262EA093C8041DCBAEBC7D3193926B2@hnivarlas1> <4D8B3D4D.8060107@uk.clara.net> <3BFE0A33-4772-46B0-AFA3-489BB4425FE8@ericsson.com> In-Reply-To: <3BFE0A33-4772-46B0-AFA3-489BB4425FE8@ericsson.com> X-Enigmail-Version: 1.0.1 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 Cc: idr <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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Mar 2011 13:10:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/03/11 13:03, Jakob Heitz wrote: > I hope you don't mean to put the actual value into the capability. Then I'll have 1000 different peers with 1000 different sizes. What a nightmare of code that would be, for no good reason. You will be sure to get a few malformed then. > Why not? we do this with TCP already! The only advantage I can possibly see for standardising on the extended size would be if an implementation used it to generate bigger UPDATE messages (i.e faster convergence) and wanted saner grouping for peers for this output processing (and even then, I'm sure it could come up with a solution based on thresholds) Dave. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2LQw8ACgkQtFWeqpgEZrL6xACbBjo8m0/Jm6X0lazpQinhL20c r1QAn1J8jk1QpiEzscLsz4oPGemBK05f =bcYt -----END PGP SIGNATURE----- From cjeker@diehard.n-r-g.com Thu Mar 24 06:14:03 2011 Return-Path: <cjeker@diehard.n-r-g.com> 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 1A1A33A68A2 for <idr@core3.amsl.com>; Thu, 24 Mar 2011 06:14:03 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Xa3mRYzRVvz for <idr@core3.amsl.com>; Thu, 24 Mar 2011 06:14:02 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id C35603A684E for <idr@ietf.org>; Thu, 24 Mar 2011 06:14:01 -0700 (PDT) Received: (qmail 22064 invoked by uid 1001); 24 Mar 2011 13:15:30 -0000 Date: Thu, 24 Mar 2011 14:15:30 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: idr@ietf.org Message-ID: <20110324131530.GD11857@diehard.n-r-g.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk> <A262EA093C8041DCBAEBC7D3193926B2@hnivarlas1> <4D8B3D4D.8060107@uk.clara.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D8B3D4D.8060107@uk.clara.net> 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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Mar 2011 13:14:03 -0000 On Thu, Mar 24, 2011 at 12:47:09PM +0000, David Freedman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 23/03/11 11:34, iLya wrote: > >> > > > > Besides the fact that fragmentation is evil, there is also third > > alternative to the above two, and that is what Keyur and Randy have > > brought up, and which after some consideration I perceive as solid and > > flexible. This alternative is to require BGP speaker to calculate > > maximum possible overhead (it _can_ do it based on agreed Capability > > Code set) for given peer (!) and use that value instead of predefined > > fixed size overhead. I do put exactly same level of trust in implementor > > following this requirement as I would in trusting implementor obeying > > fixed-sized overhead requirement. > > I think the capability-value should be used to define the > max-message-size, so the implementer can decide what they are happy (and > competent) to accept and process. Please no. Having to cope with 4k and >4k clients is enought of a problem. We don't need the interop issues caused by systems announcing starange max-message-size values. > I also don't see a need for symmetry either. We do need symmetry because of the fact that notfications may need to be sent back with more then 4096 bytes of data in them. Handling asymmetry does only gain more complexity but nothing else. KISS - keep it simple and stupid is the way to build robust protocols (no buttons, no unneeded fluff or features). > If the situation arises where an implementation decides it really needs > to send a message its peer which is larger than the peer's > max-message-size (either through evaluation of the cap-value or lack of > cap) then it could either send a NOTIFICATION (if the message was > critical to operation) or ADVISORY (yet another use case) > with an optional summary of the message contained. Yes, there is a need to define the behaviour of BGP speakers when messages exceed the maximum size but I have the feeling that this should be covered in a different document since this also affects systems that only use 4k buffers. -- :wq Claudio From cjeker@diehard.n-r-g.com Thu Mar 24 06:27:23 2011 Return-Path: <cjeker@diehard.n-r-g.com> 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 AEA963A68AC for <idr@core3.amsl.com>; Thu, 24 Mar 2011 06:27:22 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ73Nj896xog for <idr@core3.amsl.com>; Thu, 24 Mar 2011 06:27:20 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id 490AA3A68AA for <idr@ietf.org>; Thu, 24 Mar 2011 06:27:20 -0700 (PDT) Received: (qmail 10793 invoked by uid 1001); 24 Mar 2011 13:28:52 -0000 Date: Thu, 24 Mar 2011 14:28:52 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: idr@ietf.org Message-ID: <20110324132852.GE11857@diehard.n-r-g.com> References: <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk> <A262EA093C8041DCBAEBC7D3193926B2@hnivarlas1> <4D8B3D4D.8060107@uk.clara.net> <3BFE0A33-4772-46B0-AFA3-489BB4425FE8@ericsson.com> <4D8B430F.8030501@uk.clara.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D8B430F.8030501@uk.clara.net> 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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Mar 2011 13:27:23 -0000 On Thu, Mar 24, 2011 at 01:11:43PM +0000, David Freedman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 24/03/11 13:03, Jakob Heitz wrote: > > I hope you don't mean to put the actual value into the capability. Then I'll have 1000 different peers with 1000 different sizes. What a nightmare of code that would be, for no good reason. You will be sure to get a few malformed then. > > > > Why not? we do this with TCP already! TCP is a byte stream and has therefor no message size. What is the gain of having clients with BGP message sizes of 4096, 5000, 6000, 8000, 10000, 16000, 18000, ..., 32000 bytes? I don't want to imagine the nightmare of having to admin such a network. > The only advantage I can possibly see for standardising on the extended > size would be if an implementation used it to generate bigger UPDATE > messages (i.e faster convergence) and wanted saner grouping for peers > for this output processing (and even then, I'm sure it could come up > with a solution based on thresholds) Transport and message sizes are not the problem to achive faster convergence. My systems are able to exchange the full table in a lot less then 10 seconds (from open until all messages are processed). Do you think this needs to be faster? -- :wq Claudio From david.freedman@uk.clara.net Thu Mar 24 08:11:24 2011 Return-Path: <david.freedman@uk.clara.net> 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 30A1328C0F0 for <idr@core3.amsl.com>; Thu, 24 Mar 2011 08:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_21=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 I3zpsHFomt3R for <idr@core3.amsl.com>; Thu, 24 Mar 2011 08:11:22 -0700 (PDT) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by core3.amsl.com (Postfix) with ESMTP id 7FBC028C0DE for <idr@ietf.org>; Thu, 24 Mar 2011 08:11:21 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.72) (envelope-from <david.freedman@uk.clara.net>) id 1Q2mDE-0005Kj-9C for idr@ietf.org; Thu, 24 Mar 2011 15:12:36 +0000 Message-ID: <4D8B5F64.6040407@uk.clara.net> Date: Thu, 24 Mar 2011 15:12:36 +0000 From: David Freedman <david.freedman@uk.clara.net> 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 <idr@ietf.org> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk> <A262EA093C8041DCBAEBC7D3193926B2@hnivarlas1> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> In-Reply-To: <20110324131530.GD11857@diehard.n-r-g.com> X-Enigmail-Version: 1.0.1 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] draft-ymbk-bgp-extended-messages-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Mar 2011 15:11:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Please no. Having to cope with 4k and >4k clients is enought of a > problem. We don't need the interop issues caused by systems announcing > starange max-message-size values. Well, there is no intention of interop burden here, you need to support at least 4096 , you can grow above this if you use the cap , otherwise the min size you need to interop is 4096. > >> I also don't see a need for symmetry either. > > We do need symmetry because of the fact that notfications may need to > be sent back with more then 4096 bytes of data in them. Handling asymmetry > does only gain more complexity but nothing else. KISS - keep it simple and > stupid is the way to build robust protocols (no buttons, no unneeded fluff > or features). > Well, if its a notify, it is session terminal, we can tear the session down (the primary objective) without having to preserve all the message content (and if we do have to preserve the message content, then it must be important enough to require both peers to support these larger messages anyway) >TCP is a byte stream and has therefore no message size. What is the >gain of >having clients with BGP message sizes of 4096, 5000, 6000, 8000, 10000, >16000, 18000, ..., 32000 bytes? I don't want to imagine the nightmare >of >having to admin such a network. Not sure what kind of additional admin work you may need to do, if implementers are confident enough to standardise on always trying to negotiate this cap with 65535 then so be it. >Transport and message sizes are not the problem to achieve faster >convergence. My systems are able to exchange the full table in a lot >less >then 10 seconds (from open until all messages are processed). Do you >think >this needs to be faster? The "full internet routing table" example take less time to transport with larger TCP MSS and BGP message sizes (for the UPDATE) Of course, retransmitting these large messages (if they are lost/corrupted) is another issue! - -- David Freedman Group Network Engineering david.freedman@uk.clara.net Tel +44 (0) 20 7685 8000 Claranet Group 21 Southampton Row London - WC1B 5HA - UK http://www.claranet.com Company Registration: 3152737 - Place of registration: England All the information contained within this electronic message from Claranet Ltd is covered by the disclaimer at http://www.claranet.co.uk/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2LX2QACgkQtFWeqpgEZrKZAACgzDBepgq87MQ3b/GLd3zdbGSL w+cAoJFLOb6NdXJxyqXBMq9sZVZMJIT8 =6rNz -----END PGP SIGNATURE----- From ilya@nobulus.com Thu Mar 24 09:03:44 2011 Return-Path: <ilya@nobulus.com> 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 D466C28C0FF for <idr@core3.amsl.com>; Thu, 24 Mar 2011 09:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=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 cpjNjZx1spLW for <idr@core3.amsl.com>; Thu, 24 Mar 2011 09:03:44 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 9B8EE28C0DE for <idr@ietf.org>; Thu, 24 Mar 2011 09:03:43 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 7F89B17343; Thu, 24 Mar 2011 17:05:16 +0100 (CET) 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 3H7yK0pJ0BTn; Thu, 24 Mar 2011 17:05:11 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:eda4:c2f:8b96:a258]) by nobulus.com (Postfix) with ESMTPA id 30E0817332; Thu, 24 Mar 2011 17:05:11 +0100 (CET) Message-ID: <9AD8DFCF6ABF4909986F6F377F24DEBB@hnivarlas1> From: "iLya" <ilya@nobulus.com> To: "Claudio Jeker" <cjeker@diehard.n-r-g.com>, <idr@ietf.org> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com><m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com><20110322212324.GI9210@diehard.n-r-g.com><BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com><alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk><A262EA093C8041DCBAEBC7D3193926B2@hnivarlas1><4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> In-Reply-To: <20110324131530.GD11857@diehard.n-r-g.com> Date: Thu, 24 Mar 2011 17:05:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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 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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Mar 2011 16:03:44 -0000 > We do need symmetry because of the fact that notfications may need to > be sent back with more then 4096 bytes of data in them. Handling asymmetry > does only gain more complexity but nothing else. KISS - keep it simple and > stupid is the way to build robust protocols (no buttons, no unneeded fluff > or features). > On this I'm with Claudio - big messages should be supported either by both sides or by none. /iLya From jakob.heitz@ericsson.com Thu Mar 24 09:21:53 2011 Return-Path: <jakob.heitz@ericsson.com> 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 830DB28C0E1 for <idr@core3.amsl.com>; Thu, 24 Mar 2011 09:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.538, 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 wR8tvupzjyLs for <idr@core3.amsl.com>; Thu, 24 Mar 2011 09:21:52 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 8667628C0DB for <idr@ietf.org>; Thu, 24 Mar 2011 09:21:51 -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 p2OGMO6e023795; Thu, 24 Mar 2011 11:23:26 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 24 Mar 2011 12:22:47 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: David Freedman <david.freedman@uk.clara.net> Date: Thu, 24 Mar 2011 12:22:44 -0400 Thread-Topic: [Idr] draft-ymbk-bgp-extended-messages-01 Thread-Index: AcvqP7Yh/k8qmH+hSlqo/K1kBSCOpg== Message-ID: <7526E119-8FFD-415C-B2BD-D450BD4CA16C@ericsson.com> References: <m2bp13ukic.wl%randy@psg.com> <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk> <A262EA093C8041DCBAEBC7D3193926B2@hnivarlas1> <4D8B3D4D.8060107@uk.clara.net> <3BFE0A33-4772-46B0-AFA3-489BB4425FE8@ericsson.com> <4D8B430F.8030501@uk.clara.net> In-Reply-To: <4D8B430F.8030501@uk.clara.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 Cc: idr <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 <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Mar 2011 16:21:53 -0000 -- Jakob Heitz. 510-566-2901 On Mar 24, 2011, at 6:12 AM, "David Freedman" <david.freedman@uk.clara.net>= wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > On 24/03/11 13:03, Jakob Heitz wrote: >> I hope you don't mean to put the actual value into the capability. Then = I'll have 1000 different peers with 1000 different sizes. What a nightmare = of code that would be, for no good reason. You will be sure to get a few ma= lformed then.=20 >>=20 >=20 > Why not? we do this with TCP already! No you don't. TCP options size is limited to 40. God help you if anyone fig= ures out how to increase it to 65535. The TCP data field is not interpreted= by TCP, only the header.=20 >=20 > The only advantage I can possibly see for standardising on the extended > size would be if an implementation used it to generate bigger UPDATE > messages (i.e faster convergence) and wanted saner grouping for peers > for this output processing (and even then, I'm sure it could come up > with a solution based on thresholds) >=20 >=20 > Dave. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk2LQw8ACgkQtFWeqpgEZrL6xACbBjo8m0/Jm6X0lazpQinhL20c > r1QAn1J8jk1QpiEzscLsz4oPGemBK05f > =3DbcYt > -----END PGP SIGNATURE----- From cjeker@diehard.n-r-g.com Thu Mar 24 09:40:51 2011 Return-Path: <cjeker@diehard.n-r-g.com> 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 8AE7128C104 for <idr@core3.amsl.com>; Thu, 24 Mar 2011 09:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 m8afeRYU+XEN for <idr@core3.amsl.com>; Thu, 24 Mar 2011 09:40:50 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by core3.amsl.com (Postfix) with ESMTP id F41DF28C0CE for <idr@ietf.org>; Thu, 24 Mar 2011 09:40:49 -0700 (PDT) Received: (qmail 32373 invoked by uid 1001); 24 Mar 2011 16:42:19 -0000 Date: Thu, 24 Mar 2011 17:42:19 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: idr@ietf.org Message-ID: <20110324164219.GI11857@diehard.n-r-g.com> References: <4D8904EA.8040106@cisco.com> <m2hbauucek.wl%randy@psg.com> <4D8907A5.30702@cisco.com> <20110322212324.GI9210@diehard.n-r-g.com> <BC6441F3-DA49-47CC-A97A-B348729721BE@nobulus.com> <alpine.LFD.2.02.1103231104490.3809@jamaica.dcs.gla.ac.uk> <A262EA093C8041DCBAEBC7D3193926B2@hnivarlas1> <4D8B3D4D.8060107@uk.clara.net> <20110324131530.GD11857@diehard.n-r-g.com> <4D8B5F64.6040407@uk.clara.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D8B5F64.6040407@uk.clara.net> 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.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Mar 2011 16:40:51 -0000 On Thu, Mar 24, 2011 at 03:12:36PM +0000, David Freedman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Please no. Having to cope with 4k and >4k clients is enought of a > > problem. We don't need the interop issues caused by systems announcing > > starange max-message-size values. > > Well, there is no intention of interop burden here, you need to support > at least 4096 , you can grow above this if you use the cap , otherwise > the min size you need to interop is 4096. At the same time you need to interop on the new big messages. > > > >> I also don't see a need for symmetry either. > > > > We do need symmetry because of the fact that notfications may need to > > be sent back with more then 4096 bytes of data in them. Handling asymmetry > > does only gain more complexity but nothing else. KISS - keep it simple and > > stupid is the way to build robust protocols (no buttons, no unneeded fluff > > or features). > > > > Well, if its a notify, it is session terminal, we can tear the session > down (the primary objective) without having to preserve all the message > content (and if we do have to preserve the message content, then it must > be important enough to require both peers to support these larger > messages anyway) Reading this mailing list in the last few days I came to the conclusion that losing even a few bytes on notifications is a huge issue. So slamming down the session with no reason at all will not be appreciated. > >TCP is a byte stream and has therefore no message size. What is the > >gain of > >having clients with BGP message sizes of 4096, 5000, 6000, 8000, 10000, > >16000, 18000, ..., 32000 bytes? I don't want to imagine the nightmare >of > >having to admin such a network. > > Not sure what kind of additional admin work you may need to do, if > implementers are confident enough to standardise on always trying to > negotiate this cap with 65535 then so be it. It was suggested to support multiple sizes. Lets do a stupid little example: lets guess I will implement a max-size of 23456 bytes (I like this number) and someone else does something else like 16384 bytes for whatever reason and then there is one system that supports 32000 bytes. Now suppose you run this network and currently the biggest updates for a single prefix is around 15000 bytes (huge amount of path attributes). All is fine until that day when someone adds another 2000 bytes of attributes to these pathes. Suddenly part of the network behaves funky even though all systems support RFC XYZ Extended BGP Messages. All systems conform to the RFC but the operator is still screwed just because some people think they need a button for something that should be fixed number. The maximum message size does not need to be negotiated. It is either 4096 or the extended size. > >Transport and message sizes are not the problem to achieve faster > >convergence. My systems are able to exchange the full table in a lot >less > >then 10 seconds (from open until all messages are processed). Do you >think > >this needs to be faster? > > The "full internet routing table" example take less time to transport > with larger TCP MSS and BGP message sizes (for the UPDATE) The time to transport the updates can be neglected. Most time is spent to update the RIB (memory allocation, filtering, lookups). For a good network stack the TCP MSS has no big influence on transfer speed. It will just generate more packets. TCP window sizes are another matter, though. Being able to add more NLRIs to a single update may help a bit but I doubt it is really measurable (considering the current maximum of 4096 byte messages). There are not many pathes that need to be sent multiple times because the limit is hit. > Of course, retransmitting these large messages (if they are > lost/corrupted) is another issue! This is TCP's business and it works already for connections around the world. I see no issue at all since the retransmit behaviour is not altered by bigger BGP messages. -- :wq Claudio From jgs@juniper.net Sat Mar 26 02:55:18 2011 Return-Path: <jgs@juniper.net> 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 B200C3A690F for <idr@core3.amsl.com>; Sat, 26 Mar 2011 02:55:18 -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 yN2Frb8TUgrj for <idr@core3.amsl.com>; Sat, 26 Mar 2011 02:55:17 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 49F4B3A67AD for <idr@ietf.org>; Sat, 26 Mar 2011 02:55:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTY24ZDk3xj61/Ge8S80cgA3k6Rchrrn6@postini.com; Sat, 26 Mar 2011 02:56:53 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; Sat, 26 Mar 2011 02:51:42 -0700 From: John Scudder <jgs@juniper.net> To: "idr@ietf.org List" <idr@ietf.org> Date: Sat, 26 Mar 2011 02:53:05 -0700 Thread-Topic: BGP drafts in SIDR at IETF-80 Thread-Index: Acvrm2ikgN25eeP2QLm79porc17ldQ== Message-ID: <BE133D87-0916-424D-BD85-C3CB60D9D76C@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: [Idr] BGP drafts in SIDR at IETF-80 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 26 Mar 2011 09:55:18 -0000 IDR folks -- There are a number of BGP-related drafts being presented in other WGs. In = particular, there are quite a few in SIDR this time, see http://tools.ietf.= org/wg/sidr/agenda?item=3Dagenda80.html including: o draft-zhang-idr-decoupling-02.txt o draft-retana-bgp-security-state-diagnostic-00.txt o draft-ymbk-bgpsec-reqs-02.txt o draft-kent-bgpsec-threats-01.txt o draft-ymbk-bgpsec-ops-01 o draft-lepinski-bgpsec-overview-00.txt o draft-lepinski-bgpsec-protocol-00.txt IDR folk should consider attending. SIDR is scheduled Thursday and Friday. --John= From jakob.heitz@ericsson.com Sun Mar 27 12:19:24 2011 Return-Path: <jakob.heitz@ericsson.com> 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 EEB2F3A690B; Sun, 27 Mar 2011 12:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.391, 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 BScIs2SNtDJ2; Sun, 27 Mar 2011 12:19:24 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 10D483A6900; Sun, 27 Mar 2011 12:19:23 -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 p2RJL0sv003973; Sun, 27 Mar 2011 14:21:01 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 27 Mar 2011 15:20:54 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "grow@ietf.org" <grow@ietf.org>, IETF IDR <idr@ietf.org> Date: Sun, 27 Mar 2011 15:20:52 -0400 Thread-Topic: draft-ietf-grow-diverse-bgp-path-dist ignore IGP metric Thread-Index: AcvstBaef8O2lxxcTZm6vwlVa0vluA== Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAB@EUSAACMS0701.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-ietf-grow-diverse-bgp-path-dist ignore IGP metric X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 19:19:25 -0000 If you ignore IGP metric, you may choose the wrong bestpath. Suppose 3 paths, 2 RR planes. Suppose RR clusters in POPs all over the country. One RR cluster may not choose its closest path at all. It could choose 2 paths far away when there is one path closer. -- Jakob Heitz. From jakob.heitz@ericsson.com Sun Mar 27 12:32:11 2011 Return-Path: <jakob.heitz@ericsson.com> 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 845143A6927; Sun, 27 Mar 2011 12:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 FafkctqiYyCI; Sun, 27 Mar 2011 12:32:09 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 30B723A6926; Sun, 27 Mar 2011 12:32:08 -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 p2RJXiGO006707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Mar 2011 14:33:44 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 27 Mar 2011 15:33:44 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "raszuk@cisco.com" <raszuk@cisco.com>, "grow@ietf.org" <grow@ietf.org>, IETF IDR <idr@ietf.org> Date: Sun, 27 Mar 2011 15:33:42 -0400 Thread-Topic: [GROW] Potential route flap with bgp-diverse-path Thread-Index: Acvrko26N6b9zE5MRw+90jqenrNOJQBId0iw Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAF@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> In-Reply-To: <4D8DA854.6060401@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] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 19:32:11 -0000 If there are 3 paths: P1, P2 and P3 and 2 RR planes. Plane1 advertises best, Plan2 advertizes 2nd best. When the bestpath P1 goes away, the client can flap to the 3rd best path, P3, before coming back to the 2nd bset path P2. Here is the initial condition: P1 is best, P2 2nd best, P3 3rd best. Plane1 advertises P1, Plane2 advertises P2 Because the advertisements from the RR planes are not synchronized, the order of events could be: 1. P1 goes down: P2 becomes best, P3 becomes 2nd best. 2. Client receives IGP message of P1 down: Client chooses P2. 3. Client receives P3 from Plane2: Client chooses P3. 4. Client receives P2 from Plane1: Client chooses P2. Possible fix: Recommend at least as many RR planes as possible paths for any destination. -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Saturday, March 26, 2011 1:48 AM > To: Jakob Heitz > Cc: grow@ietf.org > Subject: Re: [GROW] Potential route flap with bgp-diverse-path >=20 > Hi Jakob, >=20 > > Suppose 2 RR planes, plane1 advertises the best path > > and plane2 advertises the second best. > > > > If there is no second best, does plane2 advertise nothing? >=20 > Yes it would advertise overall best if backup is missing. >=20 > > Suppose it does. >=20 > Ok. >=20 > > Suppose there are 2 paths to a destination. > > P1 is best and P2 second best. > > Now P1 goes down. > > Plane1 will change its advertisement to P2. > > Plane2 will withdraw P2. >=20 > No. >=20 > The overall assumption is that all RRs keep all paths. So=20 > plane 1 will=20 > advertise P2 and plane 2 will do nothing if P1 goes down as=20 > it already=20 > advertised P2 to the client. >=20 > > If the RR client receives and processes the withdrawal > > first, it will flap. >=20 > No withdraw will happen. >=20 > Cheers, > R. >=20 > > Note, the messages are asynchronous. Even if plane1 > > sends his message first, the client can still process > > the message from plane2 first. > > > > A solution would be to delay any advertisements from > > the second-best plane by an interval greater than the MRAI > > timer. Not good, but I can't think of anything better. > > > > -- > > Jakob Heitz. > > > > _______________________________________________ > > GROW mailing list > > GROW@ietf.org > > https://www.ietf.org/mailman/listinfo/grow > > >=20 > = From jakob.heitz@ericsson.com Sun Mar 27 12:47:41 2011 Return-Path: <jakob.heitz@ericsson.com> 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 74ED73A692E; Sun, 27 Mar 2011 12:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.268 X-Spam-Level: X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=0.331, 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 LVBBAt+Xec2R; Sun, 27 Mar 2011 12:47:40 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 7E8FC3A690B; Sun, 27 Mar 2011 12:47:40 -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 p2RJnFBb004504; Sun, 27 Mar 2011 14:49:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 27 Mar 2011 15:49:09 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "raszuk@cisco.com" <raszuk@cisco.com>, "grow@ietf.org" <grow@ietf.org>, IETF IDR <idr@ietf.org> Date: Sun, 27 Mar 2011 15:49:08 -0400 Thread-Topic: [GROW] Potential route flap with bgp-diverse-path Thread-Index: Acvrko26N6b9zE5MRw+90jqenrNOJQBI8R/Q Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECB2@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> In-Reply-To: <4D8DA854.6060401@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] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 19:47:41 -0000 If every RR plane must send a path, then the clients will have N paths for every destination, even if there is only one path. Given N RR planes, that means clients will need N times the BGP memory and N times the BGP processing power for destinations with only one path. Please make a recommendation on how many RR planes are optimal. -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Saturday, March 26, 2011 1:48 AM > To: Jakob Heitz > Cc: grow@ietf.org > Subject: Re: [GROW] Potential route flap with bgp-diverse-path >=20 > Hi Jakob, >=20 > > Suppose 2 RR planes, plane1 advertises the best path > > and plane2 advertises the second best. > > > > If there is no second best, does plane2 advertise nothing? >=20 > Yes it would advertise overall best if backup is missing. >=20 > > Suppose it does. >=20 > Ok. >=20 > > Suppose there are 2 paths to a destination. > > P1 is best and P2 second best. > > Now P1 goes down. > > Plane1 will change its advertisement to P2. > > Plane2 will withdraw P2. >=20 > No. >=20 > The overall assumption is that all RRs keep all paths. So=20 > plane 1 will=20 > advertise P2 and plane 2 will do nothing if P1 goes down as=20 > it already=20 > advertised P2 to the client. >=20 > > If the RR client receives and processes the withdrawal > > first, it will flap. >=20 > No withdraw will happen. >=20 > Cheers, > R. >=20 > > Note, the messages are asynchronous. Even if plane1 > > sends his message first, the client can still process > > the message from plane2 first. > > > > A solution would be to delay any advertisements from > > the second-best plane by an interval greater than the MRAI > > timer. Not good, but I can't think of anything better. > > > > -- > > Jakob Heitz. > > > > _______________________________________________ > > GROW mailing list > > GROW@ietf.org > > https://www.ietf.org/mailman/listinfo/grow > > >=20 > = From raszuk@cisco.com Sun Mar 27 13:44:40 2011 Return-Path: <raszuk@cisco.com> 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 E34573A6947; Sun, 27 Mar 2011 13:44:40 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCXwTT4Oc8y1; Sun, 27 Mar 2011 13:44:38 -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 307C33A693B; Sun, 27 Mar 2011 13:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1468; q=dns/txt; s=iport; t=1301258775; x=1302468375; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=aftWBZqBosCtALUOM6EC9npORBXd8bZ5ipo0lzOYgzs=; b=k9cVKOBMx7At5X9M37A8bugig1fMiUWZv9gsCuy6eWcTW6X+cLJSIj7b pK7/3+/jGR9G0oD6vJJZ5PRv6ajut2NdNKjfxfV80SXKYKKxOb9GOBvfF 0xUaZSv7TPQvYxhC/tcbmLRi6LWhVCSbeGfpIyEI8ulXQl2yeBn2E4LeT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKOhj02rRDoG/2dsb2JhbAClUXeIa5wygm8OAZd5hWkEjHeDVA X-IronPort-AV: E=Sophos;i="4.63,251,1299456000"; d="scan'208";a="325443141" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 27 Mar 2011 20:46:15 +0000 Received: from [10.21.104.107] (sjc-vpnasa1-107.cisco.com [10.21.104.107]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2RKkEWB031113; Sun, 27 Mar 2011 20:46:14 GMT Message-ID: <4D8FA215.7020809@cisco.com> Date: Sun, 27 Mar 2011 22:46:13 +0200 From: Robert Raszuk <raszuk@cisco.com> 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 <jakob.heitz@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAF@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAF@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 20:44:41 -0000 Hello Jakob, > If there are 3 paths: P1, P2 and P3 > and 2 RR planes. > Plane1 advertises best, Plan2 advertizes 2nd best. Ok. > When the bestpath P1 goes away, the client can > flap to the 3rd best path, P3, before coming > back to the 2nd bset path P2. Nope it will not .. see below on comments to your description. > Here is the initial condition: > P1 is best, P2 2nd best, P3 3rd best. > Plane1 advertises P1, Plane2 advertises P2 Perfect ! > Because the advertisements from the RR planes are > not synchronized, the order of events could be: > > 1. P1 goes down: P2 becomes best, P3 becomes 2nd best. Ok. > 2. Client receives IGP message of P1 down: Client chooses P2. Ok. > 3. Client receives P3 from Plane2: Client chooses P3. This is only when client would not have P2 at all. IMHO corner case (see below why) > 4. Client receives P2 from Plane1: Client chooses P2. P2 should not go away from client. > Possible fix: Recommend at least as many RR planes > as possible paths for any destination. Nope. There are two simple solution here: - Presence of an extra session from client to either RR to make sure that your second best is not removed before overall best is advertised - Small delay on the RR when advertising 2nd best to clients to make sure overall best is there first in some implementations just configuring per session mrai may help here. Cheers, R. From raszuk@cisco.com Sun Mar 27 13:46:01 2011 Return-Path: <raszuk@cisco.com> 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 2435F28C14D; Sun, 27 Mar 2011 13:46:01 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fudFMD-YSmO; Sun, 27 Mar 2011 13:46:00 -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 67C7628C13D; Sun, 27 Mar 2011 13:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=623; q=dns/txt; s=iport; t=1301258857; x=1302468457; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jyPqFypD3y3KYf1wvs8wwzSL+mptzvg+849tEr8OFGM=; b=Bwcq5QxzKHV1BSRPEpcQt7P6WYHIkTHojtcPhp55hkY8VTYnQ9yPZoFq 5MVTcJsOpSZYSP3u4g5ueGSoatUNu3vG6RQexljCr9Nli9HFcmDDI3q4/ xgSM15JhlO35rZrYFGFGtPFrP0WA5YHVtv359YH0LOxZxqdr9ovime2pR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACahj02rRDoH/2dsb2JhbAClUXeIa5w2gm8OAZd5hWkEjHeDVA X-IronPort-AV: E=Sophos;i="4.63,251,1299456000"; d="scan'208";a="671404575" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 27 Mar 2011 20:47:37 +0000 Received: from [10.21.104.107] (sjc-vpnasa1-107.cisco.com [10.21.104.107]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2RKlaxl022831; Sun, 27 Mar 2011 20:47:36 GMT Message-ID: <4D8FA268.3000705@cisco.com> Date: Sun, 27 Mar 2011 22:47:36 +0200 From: Robert Raszuk <raszuk@cisco.com> 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 <jakob.heitz@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECB2@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECB2@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 20:46:01 -0000 > If every RR plane must send a path, then the clients > will have N paths for every destination, even if there > is only one path. Nope that is not a requirement as discussed in the previous email. > Please make a recommendation on how many RR planes > are optimal. For all applications of today I see 2 as sufficient and optimal. Thx, R. > > Given N RR planes, > that means clients will need N times the BGP memory > and N times the BGP processing power for destinations > with only one path. > > Please make a recommendation on how many RR planes > are optimal. > > -- > Jakob Heitz. From jakob.heitz@ericsson.com Sun Mar 27 13:48:55 2011 Return-Path: <jakob.heitz@ericsson.com> 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 B2EC028C13D; Sun, 27 Mar 2011 13:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 Azph+jTrOena; Sun, 27 Mar 2011 13:48:54 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 2E76628C119; Sun, 27 Mar 2011 13:48:54 -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 p2RKoSGp005659; Sun, 27 Mar 2011 15:50:30 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 27 Mar 2011 16:50:28 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "raszuk@cisco.com" <raszuk@cisco.com> Date: Sun, 27 Mar 2011 16:50:27 -0400 Thread-Topic: [GROW] Potential route flap with bgp-diverse-path Thread-Index: AcvswDfH1xSsnthSQyGG0S9YLE57GQAACFLw Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC1@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECB2@EUSAACMS0701.eamcs.ericsson.se> <4D8FA268.3000705@cisco.com> In-Reply-To: <4D8FA268.3000705@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: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 20:48:55 -0000 > > If every RR plane must send a path, then the clients > > will have N paths for every destination, even if there > > is only one path. >=20 > Nope that is not a requirement as discussed in the previous email. In the previous email, you said the exact opposite: "Yes it would advertise overall best if backup is missing." You require that to stop the flap. >=20 > > Please make a recommendation on how many RR planes > > are optimal. >=20 > For all applications of today I see 2 as sufficient and optimal. >=20 > Thx, > R. >=20 >=20 > > > > Given N RR planes, > > that means clients will need N times the BGP memory > > and N times the BGP processing power for destinations > > with only one path. > > > > Please make a recommendation on how many RR planes > > are optimal. > > > > -- > > Jakob Heitz. >=20 > = From raszuk@cisco.com Sun Mar 27 13:52:21 2011 Return-Path: <raszuk@cisco.com> 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 D824F28C152; Sun, 27 Mar 2011 13:52: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF4khX53yEEL; Sun, 27 Mar 2011 13:52:20 -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 D046A28C119; Sun, 27 Mar 2011 13:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1302; q=dns/txt; s=iport; t=1301259238; x=1302468838; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UT9IEFkK8sSYwpNX84f3gdKQewLGluACuJ6DdmpRHmY=; b=MzGbmwl19N98o1ca8fydArVUrUXvstfMdQ2sjI5rmrVRwxwtl+rWXqnZ SgT2H4/3RkF5mPJLgdWZxU4EobzJzEcWCgV1bnMLQVK8VkwlwsNc48Jmv wb17uAIxWhoJtuIA2Jp0GjK6WJgnAhBlQAj5mP+X1zqTsZAmHOCVisfYU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIejj02rRDoH/2dsb2JhbAClUXeIa5xEgm8OAZd3hWkEjHeDVA X-IronPort-AV: E=Sophos;i="4.63,251,1299456000"; d="scan'208";a="671405972" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 27 Mar 2011 20:53:58 +0000 Received: from [10.21.104.107] (sjc-vpnasa1-107.cisco.com [10.21.104.107]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2RKrudg025765; Sun, 27 Mar 2011 20:53:57 GMT Message-ID: <4D8FA3E4.304@cisco.com> Date: Sun, 27 Mar 2011 22:53:56 +0200 From: Robert Raszuk <raszuk@cisco.com> 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 <jakob.heitz@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECB2@EUSAACMS0701.eamcs.ericsson.se> <4D8FA268.3000705@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC1@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC1@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 20:52:22 -0000 > In the previous email, you said the exact opposite: > "Yes it would advertise overall best if backup is missing." That is true but this is not applicable to the case here. Here RRs as you have indicated would have P1, P2 and P3 and when P1 goes down there is backup on both RRs. Thx, R. >>> If every RR plane must send a path, then the clients >>> will have N paths for every destination, even if there >>> is only one path. >> >> Nope that is not a requirement as discussed in the previous email. > > In the previous email, you said the exact opposite: > "Yes it would advertise overall best if backup is missing." > > You require that to stop the flap. > >> >> > Please make a recommendation on how many RR planes >> > are optimal. >> >> For all applications of today I see 2 as sufficient and optimal. >> >> Thx, >> R. >> >> >>> >>> Given N RR planes, >>> that means clients will need N times the BGP memory >>> and N times the BGP processing power for destinations >>> with only one path. >>> >>> Please make a recommendation on how many RR planes >>> are optimal. >>> >>> -- >>> Jakob Heitz. >> >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From raszuk@cisco.com Sun Mar 27 14:02:37 2011 Return-Path: <raszuk@cisco.com> 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 8C2193A693C; Sun, 27 Mar 2011 14:02:37 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1YnIus1EfeN; Sun, 27 Mar 2011 14:02:36 -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 D3F0B3A693B; Sun, 27 Mar 2011 14:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1047; q=dns/txt; s=iport; t=1301259854; x=1302469454; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OLuFJ/In2n1ONeZnQtyubNQxuz4o7Q7y76O7kur6MHM=; b=M6rTkAKlwK4nNCCflyfio/muypQLQB/obcOR3WV8kFq8W053vmdmDHVi ZaZesOCwx12yAiuY3dhAnuuigyTvio4MQPoBedgZ1wmiCemftmkYCBkcY arsKLb1V8N0/pbo2PWansATuaZLpszK6vyV7jnaUt8UscvuaCgf5ZCgxm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACOlj02rRDoH/2dsb2JhbAClUXeIa5xHgm8OAZd3hWkEjHeDVA X-IronPort-AV: E=Sophos;i="4.63,251,1299456000"; d="scan'208";a="325449711" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 27 Mar 2011 21:04:14 +0000 Received: from [10.21.104.107] (sjc-vpnasa1-107.cisco.com [10.21.104.107]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2RL4CsZ031294; Sun, 27 Mar 2011 21:04:13 GMT Message-ID: <4D8FA64C.4030607@cisco.com> Date: Sun, 27 Mar 2011 23:04:12 +0200 From: Robert Raszuk <raszuk@cisco.com> 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 <jakob.heitz@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAB@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAB@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] draft-ietf-grow-diverse-bgp-path-dist ignore IGP metric X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 21:02:37 -0000 Jakob, > If you ignore IGP metric, you may choose the wrong bestpath. This is to be used when RRs are control plane devices somewhere in the middle of the network. In case of hierarchical network such RRs would be in the core area. If you have RRs in each POP either at the pop to core boundary or within the POP you do not need to use this at all. Moreover if you have two sessions to any of the RRs this is also not needed. For more discussions on next hop IGP metric influence of BGP best path decision I would recommend to take a look at this work: http://tools.ietf.org/html/draft-raszuk-bgp-optimal-route-reflection-01 Thx, R. > Suppose 3 paths, 2 RR planes. > Suppose RR clusters in POPs all over the country. > One RR cluster may not choose its closest path at all. > It could choose 2 paths far away when there is one > path closer. > > -- > Jakob Heitz. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From jakob.heitz@ericsson.com Sun Mar 27 14:04:21 2011 Return-Path: <jakob.heitz@ericsson.com> 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 B91F43A6917; Sun, 27 Mar 2011 14:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.33 X-Spam-Level: X-Spam-Status: No, score=-6.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 LvxoL2hOjHwP; Sun, 27 Mar 2011 14:04:21 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id CFA913A6906; Sun, 27 Mar 2011 14:04:20 -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 p2RL5udS005936; Sun, 27 Mar 2011 16:05:57 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 27 Mar 2011 17:05:50 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "raszuk@cisco.com" <raszuk@cisco.com> Date: Sun, 27 Mar 2011 17:05:48 -0400 Thread-Topic: [GROW] Potential route flap with bgp-diverse-path Thread-Index: AcvswAZnGPY/FHqGTUi5P7cOoKt9MQAAUDCA Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC3@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAF@EUSAACMS0701.eamcs.ericsson.se> <4D8FA215.7020809@cisco.com> In-Reply-To: <4D8FA215.7020809@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: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 21:04:21 -0000 The "corner" case happens 1/2 the time. Initial: Plane1 advertises P1. Plane2 advertises P2. P1 goes down: Plane1 advertises P2. Plane2 advertises P3. The case that the client receives Plane2 message first is 50% likely. During the flap, it has: Plane1: P1 Plane2: P3 P1 is unreachable, so it chooses P3. Originally, I proposed a delay on Plane2 advertisements, but you didn't like it. How "small" should the delay be? I think longer than MRAI, since Plane1 may be running that timer for its P2 advertisement. What is the "extra session"? Is it a 3rd RR plane? -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Sunday, March 27, 2011 1:46 PM > To: Jakob Heitz > Cc: grow@ietf.org; IETF IDR > Subject: Re: [GROW] Potential route flap with bgp-diverse-path >=20 > Hello Jakob, >=20 > > If there are 3 paths: P1, P2 and P3 > > and 2 RR planes. > > Plane1 advertises best, Plan2 advertizes 2nd best. >=20 > Ok. >=20 > > When the bestpath P1 goes away, the client can > > flap to the 3rd best path, P3, before coming > > back to the 2nd bset path P2. >=20 > Nope it will not .. see below on comments to your description. >=20 > > Here is the initial condition: > > P1 is best, P2 2nd best, P3 3rd best. > > Plane1 advertises P1, Plane2 advertises P2 >=20 > Perfect ! >=20 > > Because the advertisements from the RR planes are > > not synchronized, the order of events could be: > > > > 1. P1 goes down: P2 becomes best, P3 becomes 2nd best. >=20 > Ok. >=20 > > 2. Client receives IGP message of P1 down: Client chooses P2. >=20 > Ok. >=20 > > 3. Client receives P3 from Plane2: Client chooses P3. >=20 > This is only when client would not have P2 at all. IMHO=20 > corner case (see=20 > below why) >=20 > > 4. Client receives P2 from Plane1: Client chooses P2. >=20 > P2 should not go away from client. >=20 > > Possible fix: Recommend at least as many RR planes > > as possible paths for any destination. >=20 > Nope. >=20 > There are two simple solution here: >=20 > - Presence of an extra session from client to either RR to make sure=20 > that your second best is not removed before overall best is advertised >=20 > - Small delay on the RR when advertising 2nd best to clients to make=20 > sure overall best is there first in some implementations just=20 > configuring per session mrai may help here. >=20 > Cheers, > R. >=20 > = From jakob.heitz@ericsson.com Sun Mar 27 14:07:40 2011 Return-Path: <jakob.heitz@ericsson.com> 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 A7ECC3A6950; Sun, 27 Mar 2011 14:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.346 X-Spam-Level: X-Spam-Status: No, score=-6.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 NIsAbGEPCFGZ; Sun, 27 Mar 2011 14:07:39 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id B01733A6948; Sun, 27 Mar 2011 14:07:39 -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 p2RL9EY8005970; Sun, 27 Mar 2011 16:09:15 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 27 Mar 2011 17:09:09 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "raszuk@cisco.com" <raszuk@cisco.com> Date: Sun, 27 Mar 2011 17:09:05 -0400 Thread-Topic: [Idr] [GROW] Potential route flap with bgp-diverse-path Thread-Index: AcvswRn2o30Cm0xVRA6Tt6NwI1sezgAAd54Q Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC6@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECB2@EUSAACMS0701.eamcs.ericsson.se> <4D8FA268.3000705@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC1@EUSAACMS0701.eamcs.ericsson.se> <4D8FA3E4.304@cisco.com> In-Reply-To: <4D8FA3E4.304@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: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 21:07:40 -0000 So what is the rule to make it applicable? If there is no second path, When does the 2nd best RR plane advertise the best and when does it advertise nothing? -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Sunday, March 27, 2011 1:54 PM > To: Jakob Heitz > Cc: IETF IDR; grow@ietf.org > Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path >=20 >=20 > > In the previous email, you said the exact opposite: > > "Yes it would advertise overall best if backup is missing." >=20 > That is true but this is not applicable to the case here. >=20 > Here RRs as you have indicated would have P1, P2 and P3 and=20 > when P1 goes=20 > down there is backup on both RRs. >=20 > Thx, > R. >=20 >=20 > >>> If every RR plane must send a path, then the clients > >>> will have N paths for every destination, even if there > >>> is only one path. > >> > >> Nope that is not a requirement as discussed in the previous email. > > > > In the previous email, you said the exact opposite: > > "Yes it would advertise overall best if backup is missing." > > > > You require that to stop the flap. > > > >> > >> > Please make a recommendation on how many RR planes > >> > are optimal. > >> > >> For all applications of today I see 2 as sufficient and optimal. > >> > >> Thx, > >> R. > >> > >> > >>> > >>> Given N RR planes, > >>> that means clients will need N times the BGP memory > >>> and N times the BGP processing power for destinations > >>> with only one path. > >>> > >>> Please make a recommendation on how many RR planes > >>> are optimal. > >>> > >>> -- > >>> Jakob Heitz. > >> > >> > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > >=20 > = From raszuk@cisco.com Sun Mar 27 14:23:19 2011 Return-Path: <raszuk@cisco.com> 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 2B4C03A695E; Sun, 27 Mar 2011 14:23:19 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAMgdw8oiQbs; Sun, 27 Mar 2011 14:23:17 -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 B3AA33A695D; Sun, 27 Mar 2011 14:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=4044; q=dns/txt; s=iport; t=1301261094; x=1302470694; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XXSrFMUAg8rFAuIFEWMFu6FHz3tH6g/8xjvEAREXyBk=; b=jETs9pRvBlonKD3+Q/Ch+/pFv+wZNYDhUiDquts+oxgWCo7JVzSH5vOR VBu+wXJD0L3pqWjraZ1Ki9wVYO5vP86VQS8GRn8jiLEwF7YMxesGef/DY eqvTb2MmGYLSB/j47oReByVNsqu0XREHe0LqsqATWAkPb9IqjxUUFdisK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAMaqj02rRDoG/2dsb2JhbACYE40+d4hrnFeCbw4Bl3aFaQSMd4NU X-IronPort-AV: E=Sophos;i="4.63,252,1299456000"; d="scan'208";a="283638303" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 27 Mar 2011 21:24:18 +0000 Received: from [10.21.104.107] (sjc-vpnasa1-107.cisco.com [10.21.104.107]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2RLOIu2016159; Sun, 27 Mar 2011 21:24:18 GMT Message-ID: <4D8FAB01.2090407@cisco.com> Date: Sun, 27 Mar 2011 23:24:17 +0200 From: Robert Raszuk <raszuk@cisco.com> 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 <jakob.heitz@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAF@EUSAACMS0701.eamcs.ericsson.se> <4D8FA215.7020809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC3@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC3@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 21:23:19 -0000 Hi Jakob, > The "corner" case happens 1/2 the time. If you insist let's focus on it then ... > Initial: > Plane1 advertises P1. > Plane2 advertises P2. > > P1 goes down: > Plane1 advertises P2. > Plane2 advertises P3. > > The case that the client receives Plane2 message first > is 50% likely. During the flap, it has: > > Plane1: P1 > Plane2: P3 > > P1 is unreachable, so it chooses P3. There is no "flap" in the above. Let's see what client does in this case ... Initially you have net X via P1 and P2. P1 goes down so P2 becomes active in prefix independent convergence way no packet drops other then IGP notification about P1 down bad event. Now RR2 sends implicit withdraw and advertises P3 over the session so client does RIB update for net X and in place modification for it's next hop (assuming that P2 and P3 have even different next hops). In decent implementation this is not removal of the path, drop then it's new installation. In decent bgp implementation switching one active and valid next hop with a given net with another valid next hop is not traffic impacting (if that is what you mean by route flap). So with the light of this what problem are you trying to address in the first place ? > Originally, I proposed a delay on Plane2 advertisements, > but you didn't like it. How "small" should the delay be? In non decent implementation the delay of advertising 2nd best may cover for it. I would not make any recommendation for the value at this point and leave it as an configuration option. > I think longer than MRAI, since Plane1 may be running > that timer for its P2 advertisement. Well this now depends how MRAI is implemented ... does it allow always first transition to go or not. Besides default MRAI for IBGP and this is IBGP we are discussing has been for a long time recommended to be of zero. > What is the "extra session"? > Is it a 3rd RR plane? Additional session allows you to receive from the same RR both best and second best paths one on each session. Hence non of the issues you are describing do apply then. Cheers, R. > > -- > Jakob Heitz. > > >> -----Original Message----- >> From: Robert Raszuk [mailto:raszuk@cisco.com] >> Sent: Sunday, March 27, 2011 1:46 PM >> To: Jakob Heitz >> Cc: grow@ietf.org; IETF IDR >> Subject: Re: [GROW] Potential route flap with bgp-diverse-path >> >> Hello Jakob, >> >>> If there are 3 paths: P1, P2 and P3 >>> and 2 RR planes. >>> Plane1 advertises best, Plan2 advertizes 2nd best. >> >> Ok. >> >>> When the bestpath P1 goes away, the client can >>> flap to the 3rd best path, P3, before coming >>> back to the 2nd bset path P2. >> >> Nope it will not .. see below on comments to your description. >> >>> Here is the initial condition: >>> P1 is best, P2 2nd best, P3 3rd best. >>> Plane1 advertises P1, Plane2 advertises P2 >> >> Perfect ! >> >>> Because the advertisements from the RR planes are >>> not synchronized, the order of events could be: >>> >>> 1. P1 goes down: P2 becomes best, P3 becomes 2nd best. >> >> Ok. >> >>> 2. Client receives IGP message of P1 down: Client chooses P2. >> >> Ok. >> >>> 3. Client receives P3 from Plane2: Client chooses P3. >> >> This is only when client would not have P2 at all. IMHO >> corner case (see >> below why) >> >>> 4. Client receives P2 from Plane1: Client chooses P2. >> >> P2 should not go away from client. >> >>> Possible fix: Recommend at least as many RR planes >>> as possible paths for any destination. >> >> Nope. >> >> There are two simple solution here: >> >> - Presence of an extra session from client to either RR to make sure >> that your second best is not removed before overall best is advertised >> >> - Small delay on the RR when advertising 2nd best to clients to make >> sure overall best is there first in some implementations just >> configuring per session mrai may help here. >> >> Cheers, >> R. >> >> From jakob.heitz@ericsson.com Sun Mar 27 14:26:30 2011 Return-Path: <jakob.heitz@ericsson.com> 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 870523A6964; Sun, 27 Mar 2011 14:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.36 X-Spam-Level: X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 AkCvLk44gi9b; Sun, 27 Mar 2011 14:26:29 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 86BFB3A695F; Sun, 27 Mar 2011 14:26:29 -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 p2RLS50o006261; Sun, 27 Mar 2011 16:28:06 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 27 Mar 2011 17:27:59 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "grow@ietf.org" <grow@ietf.org>, IETF IDR <idr@ietf.org> Date: Sun, 27 Mar 2011 17:27:57 -0400 Thread-Topic: draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection Thread-Index: AcvsxddAHsvF6xdPQLSXy+Iluq7ddA== Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.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-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 21:26:30 -0000 Route selection tie breakers in RFC 4271 state: f) Remove from consideration all routes other than the route that was advertised by the BGP speaker with the lowest BGP Identifier value. g) Prefer the route received from the lowest peer address. Suppose RR Planes use different BGP Identifier values. If they use the same BGP Identifier, a similar argument can be made for peer address. To prevent clients in different clusters from choosing different bestpaths based on tie breaker (f): The RR Plane that advertises the best path MUST be configured with a BGP Identifier higher than that of the RR Plane that advertises the 2nd best. This must be higher than that of the Plane that advertises the 3rd best and so on. I'm not sure if this rule completely solves the problem. If not, then the "Edge_Discriminator attribute" proposed by draft-pmohapat-idr-fast-conn-restore may be required. Also, this would need to be applied before rule (f). -- Jakob Heitz. From jakob.heitz@ericsson.com Sun Mar 27 14:36:09 2011 Return-Path: <jakob.heitz@ericsson.com> 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 885033A696C; Sun, 27 Mar 2011 14:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 l-LCmA+iyB2b; Sun, 27 Mar 2011 14:36:08 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 3E35C3A6957; Sun, 27 Mar 2011 14:36:08 -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 p2RLbhxu008590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Mar 2011 16:37:43 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 27 Mar 2011 17:37:42 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "raszuk@cisco.com" <raszuk@cisco.com> Date: Sun, 27 Mar 2011 17:37:41 -0400 Thread-Topic: [GROW] Potential route flap with bgp-diverse-path Thread-Index: AcvsxWyNa3VkFTsfRQSQOucGn/1uPQAAN3Bw Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCC@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAF@EUSAACMS0701.eamcs.ericsson.se> <4D8FA215.7020809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC3@EUSAACMS0701.eamcs.ericsson.se> <4D8FAB01.2090407@cisco.com> In-Reply-To: <4D8FAB01.2090407@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: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 21:36:09 -0000 > Hi Jakob, >=20 > > The "corner" case happens 1/2 the time. >=20 > If you insist let's focus on it then ... >=20 > > Initial: > > Plane1 advertises P1. > > Plane2 advertises P2. > > > > P1 goes down: > > Plane1 advertises P2. > > Plane2 advertises P3. > > > > The case that the client receives Plane2 message first > > is 50% likely. During the flap, it has: > > > > Plane1: P1 > > Plane2: P3 > > > > P1 is unreachable, so it chooses P3. >=20 > There is no "flap" in the above. Let's see what client does=20 > in this case ... >=20 > Initially you have net X via P1 and P2. >=20 > P1 goes down so P2 becomes active in prefix independent=20 > convergence way=20 > no packet drops other then IGP notification about P1 down bad event. >=20 > Now RR2 sends implicit withdraw and advertises P3 over the session so=20 > client does RIB update for net X and in place modification=20 > for it's next=20 > hop (assuming that P2 and P3 have even different next hops). >=20 > In decent implementation this is not removal of the path,=20 > drop then it's=20 > new installation. In decent bgp implementation switching one=20 > active and=20 > valid next hop with a given net with another valid next hop is not=20 > traffic impacting (if that is what you mean by route flap). I mean it switches to P2, then to P3, then back to P2. This does not happen when using add-path. It causes churn if this router readvertises to external peers and P2 has different atributes to P3. The issue is not necessarily a problem. However, it needs to be stated in the draft, so that operators can be aware and avoid the problems. >=20 > So with the light of this what problem are you trying to=20 > address in the=20 > first place ? >=20 > > Originally, I proposed a delay on Plane2 advertisements, > > but you didn't like it. How "small" should the delay be? >=20 > In non decent implementation the delay of advertising 2nd=20 > best may cover=20 > for it. I would not make any recommendation for the value at=20 > this point=20 > and leave it as an configuration option. >=20 > > I think longer than MRAI, since Plane1 may be running > > that timer for its P2 advertisement. >=20 > Well this now depends how MRAI is implemented ... does it=20 > allow always=20 > first transition to go or not. Besides default MRAI for IBGP=20 > and this is=20 > IBGP we are discussing has been for a long time recommended=20 > to be of zero. >=20 > > What is the "extra session"? > > Is it a 3rd RR plane? >=20 > Additional session allows you to receive from the same RR=20 > both best and=20 > second best paths one on each session. Hence non of the=20 > issues you are=20 > describing do apply then. That makes it a 3rd RR plane. It means you are recommending at least as many RR planes as possible paths for any destination. >=20 > Cheers, > R. >=20 >=20 >=20 >=20 > > > > -- > > Jakob Heitz. > > > > > >> -----Original Message----- > >> From: Robert Raszuk [mailto:raszuk@cisco.com] > >> Sent: Sunday, March 27, 2011 1:46 PM > >> To: Jakob Heitz > >> Cc: grow@ietf.org; IETF IDR > >> Subject: Re: [GROW] Potential route flap with bgp-diverse-path > >> > >> Hello Jakob, > >> > >>> If there are 3 paths: P1, P2 and P3 > >>> and 2 RR planes. > >>> Plane1 advertises best, Plan2 advertizes 2nd best. > >> > >> Ok. > >> > >>> When the bestpath P1 goes away, the client can > >>> flap to the 3rd best path, P3, before coming > >>> back to the 2nd bset path P2. > >> > >> Nope it will not .. see below on comments to your description. > >> > >>> Here is the initial condition: > >>> P1 is best, P2 2nd best, P3 3rd best. > >>> Plane1 advertises P1, Plane2 advertises P2 > >> > >> Perfect ! > >> > >>> Because the advertisements from the RR planes are > >>> not synchronized, the order of events could be: > >>> > >>> 1. P1 goes down: P2 becomes best, P3 becomes 2nd best. > >> > >> Ok. > >> > >>> 2. Client receives IGP message of P1 down: Client chooses P2. > >> > >> Ok. > >> > >>> 3. Client receives P3 from Plane2: Client chooses P3. > >> > >> This is only when client would not have P2 at all. IMHO > >> corner case (see > >> below why) > >> > >>> 4. Client receives P2 from Plane1: Client chooses P2. > >> > >> P2 should not go away from client. > >> > >>> Possible fix: Recommend at least as many RR planes > >>> as possible paths for any destination. > >> > >> Nope. > >> > >> There are two simple solution here: > >> > >> - Presence of an extra session from client to either RR to=20 > make sure > >> that your second best is not removed before overall best=20 > is advertised > >> > >> - Small delay on the RR when advertising 2nd best to=20 > clients to make > >> sure overall best is there first in some implementations just > >> configuring per session mrai may help here. > >> > >> Cheers, > >> R. > >> > >> >=20 > = From raszuk@cisco.com Sun Mar 27 15:04:06 2011 Return-Path: <raszuk@cisco.com> 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 051443A6978; Sun, 27 Mar 2011 15:04:06 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Jpe+xrWrABS; Sun, 27 Mar 2011 15:04:05 -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 2A77E3A6977; Sun, 27 Mar 2011 15:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1980; q=dns/txt; s=iport; t=1301263542; x=1302473142; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jVuna0kudMAYB4JpqHGfA2VZdWjGMHLUQG8i91/YkkE=; b=nLaxrX5LGArRPX6ysBnk9xiMzf/dy+srbr+3/WfXkY62dcs3HLuFrpet xj7U7QjCngMCCpYoXgH+OUU9Q3HbR5NQUNNsf5x13J4L1B+AGZWgpVIwM rfwPngRnQd/lWthMA+fjh5ZJhwDxq/WzJyvC3GWWQt6kHx8c403Z++Swk 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGC0j02rRDoG/2dsb2JhbAClUXeIa5wbgm8OAZd3hWkEjHeDVA X-IronPort-AV: E=Sophos;i="4.63,252,1299456000"; d="scan'208";a="283646997" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 27 Mar 2011 22:05:41 +0000 Received: from [10.21.104.107] (sjc-vpnasa1-107.cisco.com [10.21.104.107]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2RM5eFM031939; Sun, 27 Mar 2011 22:05:41 GMT Message-ID: <4D8FB4B4.1040306@cisco.com> Date: Mon, 28 Mar 2011 00:05:40 +0200 From: Robert Raszuk <raszuk@cisco.com> 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 <jakob.heitz@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAF@EUSAACMS0701.eamcs.ericsson.se> <4D8FA215.7020809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC3@EUSAACMS0701.eamcs.ericsson.se> <4D8FAB01.2090407@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCC@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCC@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 22:04:06 -0000 Hi Jakob, > I mean it switches to P2, then to P3, then > back to P2. This does not happen when using add-path. No one is trying to compare it to add-paths. > It causes churn if this router readvertises to external > peers and P2 has different atributes to P3. What it needs to be compared against is current BGP deployments. You best path from both RRs and when it fails you blackhole traffic till BGP provides you a new path. The external re-advertisement is also not really valid observation. One main reason why EBGP MRAI is longer then IBGP MRAI is exactly to mitigate those short lived BGP transitions from being visible in the entire Internet. > The issue is not necessarily a problem. However, it needs > to be stated in the draft, so that operators can be > aware and avoid the problems. If you have some text to propose which would first correctly describe and clarify the issue I would be happy to incorporate it. Just keep in mind that diverse-path is a very simple way, without need to upgrade the client side to provide much better path switchover results with no packet drop as compared to what is today. > That makes it a 3rd RR plane. > It means you are recommending at least as many RR planes > as possible paths for any destination. Nope. I think you are drawing conclusions too quickly. Second client-RR session would allow to advertise best and second best from any given RR. That means that you would never transition to 3rd best even for fraction of time as your R2 would still be there on the client. Keep in mind that some deployment proposal models from customers are even today focused on sharing RRs and configuring some clients to get best and some to get second best from a given RR even if RRs are in pair. And this is just configuration as the diverse-path as will be discussed in GROW meeting this week during the implementation report is a per peer knob. Many thx, R. From raszuk@cisco.com Sun Mar 27 15:15:45 2011 Return-Path: <raszuk@cisco.com> 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 BC00C3A6976; Sun, 27 Mar 2011 15:15:45 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyDGe-NUIrXu; Sun, 27 Mar 2011 15:15:45 -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 0996F3A684B; Sun, 27 Mar 2011 15:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1686; q=dns/txt; s=iport; t=1301264241; x=1302473841; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=M1YlYbXo2Cjh0UzzgxsQGV1a7ixg6lNsEQQpHSr5+Es=; b=a2vtpo4cFv0R1RIKcn2vbySSmuJd5FLptVRZPDWHjGIkD3Ha48nMVS8i LsBNSqH/OT8j0jKgPqqIi3f2DcUirI7vk6TWzPk6nbxeQ/jZhRy6MZQJa SuCTrSHeKK7ad/JMGHWueTFWLXGLzl50+Rns6KiokISK4yC5ddKUlgX94 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALa2j02rRDoJ/2dsb2JhbAClUXeIa5wpgm8OAZd1hWkEjHeDVA X-IronPort-AV: E=Sophos;i="4.63,252,1299456000"; d="scan'208";a="283649831" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 27 Mar 2011 22:17:21 +0000 Received: from [10.21.104.107] (sjc-vpnasa1-107.cisco.com [10.21.104.107]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2RMHKW8020935; Sun, 27 Mar 2011 22:17:21 GMT Message-ID: <4D8FB770.8090901@cisco.com> Date: Mon, 28 Mar 2011 00:17:20 +0200 From: Robert Raszuk <raszuk@cisco.com> 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 <jakob.heitz@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 22:15:45 -0000 Jakob, > To prevent clients in different clusters from choosing > different bestpaths based on tie breaker (f): Can you restate what is the problem with the above ? Today clients would chose different best paths when IGP metric to one next hop is closest on one to NH1 and closest on the other to NH2. And this check happens well above step (f). How is this at all related to the diverse path draft like the subject could indicate ? Thx, R. > Route selection tie breakers in RFC 4271 state: > > f) Remove from consideration all routes other than the route that > was advertised by the BGP speaker with the lowest BGP > Identifier value. > > g) Prefer the route received from the lowest peer address. > > Suppose RR Planes use different BGP Identifier values. > If they use the same BGP Identifier, a similar argument > can be made for peer address. > > To prevent clients in different clusters from choosing > different bestpaths based on tie breaker (f): > > The RR Plane that advertises the best path MUST be configured > with a BGP Identifier higher than that of the RR Plane that > advertises the 2nd best. This must be higher than that of > the Plane that advertises the 3rd best and so on. > > I'm not sure if this rule completely solves the problem. > If not, then the "Edge_Discriminator attribute" proposed > by draft-pmohapat-idr-fast-conn-restore may be required. > Also, this would need to be applied before rule (f). > > -- > Jakob Heitz. > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > From jakob.heitz@ericsson.com Sun Mar 27 15:20:07 2011 Return-Path: <jakob.heitz@ericsson.com> 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 118A928C0CF; Sun, 27 Mar 2011 15:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 lWt++XTkr3rk; Sun, 27 Mar 2011 15:20:06 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id CAF133A63C9; Sun, 27 Mar 2011 15:20:05 -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 p2RMLfH7007096; Sun, 27 Mar 2011 17:21:42 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 27 Mar 2011 18:21:35 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "raszuk@cisco.com" <raszuk@cisco.com> Date: Sun, 27 Mar 2011 18:21:33 -0400 Thread-Topic: [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection Thread-Index: AcvszMDF+1JU+i9wQ+iR87wMipSWUwAAEuCg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCD@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> <4D8FB770.8090901@cisco.com> In-Reply-To: <4D8FB770.8090901@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: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 22:20:07 -0000 This is standard BGP if the IGP metrics are equal. -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Sunday, March 27, 2011 3:17 PM > To: Jakob Heitz > Cc: grow@ietf.org; IETF IDR > Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist:=20 > risk of inconsistent path selection >=20 > Jakob, >=20 > > To prevent clients in different clusters from choosing > > different bestpaths based on tie breaker (f): >=20 > Can you restate what is the problem with the above ? >=20 > Today clients would chose different best paths when IGP metric to one=20 > next hop is closest on one to NH1 and closest on the other to=20 > NH2. And=20 > this check happens well above step (f). >=20 > How is this at all related to the diverse path draft like the subject=20 > could indicate ? >=20 > Thx, > R. >=20 >=20 >=20 > > Route selection tie breakers in RFC 4271 state: > > > > f) Remove from consideration all routes other than=20 > the route that > > was advertised by the BGP speaker with the lowest BGP > > Identifier value. > > > > g) Prefer the route received from the lowest peer address. > > > > Suppose RR Planes use different BGP Identifier values. > > If they use the same BGP Identifier, a similar argument > > can be made for peer address. > > > > To prevent clients in different clusters from choosing > > different bestpaths based on tie breaker (f): > > > > The RR Plane that advertises the best path MUST be configured > > with a BGP Identifier higher than that of the RR Plane that > > advertises the 2nd best. This must be higher than that of > > the Plane that advertises the 3rd best and so on. > > > > I'm not sure if this rule completely solves the problem. > > If not, then the "Edge_Discriminator attribute" proposed > > by draft-pmohapat-idr-fast-conn-restore may be required. > > Also, this would need to be applied before rule (f). > > > > -- > > Jakob Heitz. > > > > _______________________________________________ > > GROW mailing list > > GROW@ietf.org > > https://www.ietf.org/mailman/listinfo/grow > > >=20 > = From raszuk@cisco.com Sun Mar 27 15:24:22 2011 Return-Path: <raszuk@cisco.com> 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 DEE9228C0E6; Sun, 27 Mar 2011 15:24:22 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zmgfs1UyGQbV; Sun, 27 Mar 2011 15:24: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 C3D0C3A63C9; Sun, 27 Mar 2011 15:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2325; q=dns/txt; s=iport; t=1301264759; x=1302474359; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RbhvE9QHpoA9CQ1x/IaG1lGENpsHweG0jxN5gRM8jgM=; b=gi9/BBVXDYdhS96Ht3IxGkEGG9FeUBi/2OQqv8X1iDj/DXLsiN6uBnuZ cEoCWCOpqLpQy9iqU5hcmOEDpw1cOi99i6oKlO+y7w3Is5Md/1wuoXqU3 JxOJ7KBy0PpCcAWhd78GGbifM4oi0+zMAa99A9esSW7w4I9w5hv7gOKBI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAOe4j02rRDoJ/2dsb2JhbACYE40+d4hrnCSCbw4Bl3SFaQSMd4NU X-IronPort-AV: E=Sophos;i="4.63,252,1299456000"; d="scan'208";a="283651894" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 27 Mar 2011 22:25:59 +0000 Received: from [10.21.104.107] (sjc-vpnasa1-107.cisco.com [10.21.104.107]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2RMPvFt024692; Sun, 27 Mar 2011 22:25:58 GMT Message-ID: <4D8FB975.1030809@cisco.com> Date: Mon, 28 Mar 2011 00:25:57 +0200 From: Robert Raszuk <raszuk@cisco.com> 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 <jakob.heitz@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> <4D8FB770.8090901@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCD@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCD@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 22:24:23 -0000 Exactly. So what is the problem within this thread which you claim that clients may "risk of inconsistent path selection" ? R. > This is standard BGP if the IGP metrics are equal. > > -- > Jakob Heitz. > > >> -----Original Message----- >> From: Robert Raszuk [mailto:raszuk@cisco.com] >> Sent: Sunday, March 27, 2011 3:17 PM >> To: Jakob Heitz >> Cc: grow@ietf.org; IETF IDR >> Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: >> risk of inconsistent path selection >> >> Jakob, >> >> > To prevent clients in different clusters from choosing >> > different bestpaths based on tie breaker (f): >> >> Can you restate what is the problem with the above ? >> >> Today clients would chose different best paths when IGP metric to one >> next hop is closest on one to NH1 and closest on the other to >> NH2. And >> this check happens well above step (f). >> >> How is this at all related to the diverse path draft like the subject >> could indicate ? >> >> Thx, >> R. >> >> >> >>> Route selection tie breakers in RFC 4271 state: >>> >>> f) Remove from consideration all routes other than >> the route that >>> was advertised by the BGP speaker with the lowest BGP >>> Identifier value. >>> >>> g) Prefer the route received from the lowest peer address. >>> >>> Suppose RR Planes use different BGP Identifier values. >>> If they use the same BGP Identifier, a similar argument >>> can be made for peer address. >>> >>> To prevent clients in different clusters from choosing >>> different bestpaths based on tie breaker (f): >>> >>> The RR Plane that advertises the best path MUST be configured >>> with a BGP Identifier higher than that of the RR Plane that >>> advertises the 2nd best. This must be higher than that of >>> the Plane that advertises the 3rd best and so on. >>> >>> I'm not sure if this rule completely solves the problem. >>> If not, then the "Edge_Discriminator attribute" proposed >>> by draft-pmohapat-idr-fast-conn-restore may be required. >>> Also, this would need to be applied before rule (f). >>> >>> -- >>> Jakob Heitz. >>> >>> _______________________________________________ >>> GROW mailing list >>> GROW@ietf.org >>> https://www.ietf.org/mailman/listinfo/grow >>> >> >> From jakob.heitz@ericsson.com Sun Mar 27 15:25:23 2011 Return-Path: <jakob.heitz@ericsson.com> 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 1659D28C16F; Sun, 27 Mar 2011 15:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 4Rqc47tFbWoA; Sun, 27 Mar 2011 15:25:22 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 0606D3A63C9; Sun, 27 Mar 2011 15:25:21 -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 p2RMQvWI007176; Sun, 27 Mar 2011 17:26:58 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 27 Mar 2011 18:26:50 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "raszuk@cisco.com" <raszuk@cisco.com> Date: Sun, 27 Mar 2011 18:26:48 -0400 Thread-Topic: [GROW] Potential route flap with bgp-diverse-path Thread-Index: Acvsyx+Sy0D5O1KGQ1meacYoOjbjbQAAHzZA Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCE@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAF@EUSAACMS0701.eamcs.ericsson.se> <4D8FA215.7020809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC3@EUSAACMS0701.eamcs.ericsson.se> <4D8FAB01.2090407@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCC@EUSAACMS0701.eamcs.ericsson.se> <4D8FB4B4.1040306@cisco.com> In-Reply-To: <4D8FB4B4.1040306@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: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 22:25:23 -0000 I propose to add this text to the draft: Advertisements of multiple paths by multiple planes of advertisers are received asynchronously. It is not possible to order the messages reliably from different planes. This may cause churn in route selection when paths change. To address this issue, a speaker that advertises the Nth best path, where N>1, SHOULD delay its advertisement by MRAI plus (N-1) times X. X SHOULD be a small value that is greater than the message delivery time between BGP speakers. Such a speaker should not add its own MRAI timer to this delay. A speaker that advertises the Nth best path shall initially advertise nothing if an Nth best path does not exist. Once the Nth best path changes, it should apply the above delay before sending the changed advertisement. The change may be a withdrawal. -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Sunday, March 27, 2011 3:06 PM > To: Jakob Heitz > Cc: grow@ietf.org; IETF IDR > Subject: Re: [GROW] Potential route flap with bgp-diverse-path >=20 > Hi Jakob, >=20 > > I mean it switches to P2, then to P3, then > > back to P2. This does not happen when using add-path. >=20 > No one is trying to compare it to add-paths. >=20 > > It causes churn if this router readvertises to external > > peers and P2 has different atributes to P3. >=20 > What it needs to be compared against is current BGP deployments. You=20 > best path from both RRs and when it fails you blackhole=20 > traffic till BGP=20 > provides you a new path. >=20 > The external re-advertisement is also not really valid=20 > observation. One=20 > main reason why EBGP MRAI is longer then IBGP MRAI is exactly to=20 > mitigate those short lived BGP transitions from being visible in the=20 > entire Internet. >=20 > > The issue is not necessarily a problem. However, it needs > > to be stated in the draft, so that operators can be > > aware and avoid the problems. >=20 > If you have some text to propose which would first correctly describe=20 > and clarify the issue I would be happy to incorporate it. >=20 > Just keep in mind that diverse-path is a very simple way,=20 > without need=20 > to upgrade the client side to provide much better path switchover=20 > results with no packet drop as compared to what is today. >=20 > > That makes it a 3rd RR plane. > > It means you are recommending at least as many RR planes > > as possible paths for any destination. >=20 > Nope. I think you are drawing conclusions too quickly. >=20 > Second client-RR session would allow to advertise best and=20 > second best=20 > from any given RR. That means that you would never transition to 3rd=20 > best even for fraction of time as your R2 would still be there on the=20 > client. >=20 > Keep in mind that some deployment proposal models from customers are=20 > even today focused on sharing RRs and configuring some clients to get=20 > best and some to get second best from a given RR even if RRs are in=20 > pair. And this is just configuration as the diverse-path as will be=20 > discussed in GROW meeting this week during the implementation=20 > report is=20 > a per peer knob. >=20 > Many thx, > R. >=20 >=20 >=20 >=20 >=20 > = From jakob.heitz@ericsson.com Sun Mar 27 15:43:58 2011 Return-Path: <jakob.heitz@ericsson.com> 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 820B83A63C9; Sun, 27 Mar 2011 15:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 0Adr9YVgkBoc; Sun, 27 Mar 2011 15:43:57 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 699813A6978; Sun, 27 Mar 2011 15:43: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 p2RMjWLo007437; Sun, 27 Mar 2011 17:45:33 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 27 Mar 2011 18:45:26 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "raszuk@cisco.com" <raszuk@cisco.com> Date: Sun, 27 Mar 2011 18:45:23 -0400 Thread-Topic: [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection Thread-Index: AcvszfSyMqtrW3kTQiC+3H5TxY8qoAAACDLA Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECD2@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> <4D8FB770.8090901@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCD@EUSAACMS0701.eamcs.ericsson.se> <4D8FB975.1030809@cisco.com> In-Reply-To: <4D8FB975.1030809@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: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 22:43:58 -0000 Suppose 2 clusters. Cluster 1 has 2 diverse path speakers, RR11 and RR12 and client C1. Cluster 2 has 2 diverse path speakers, RR21 and RR22. and client C2. Suppose BGP Identifiers: RR11 =3D 11 advertises best RR12 =3D 12 advertises second best RR21 =3D 21 advertises second best RR22 =3D 22 advertises best If the tie breaker reaches step (f), C1 will choose second best and C2 will choose best. The rule I state will prevent the inconsistency. I assume that the IGP metric problem at the RRs has been fixed such that each RR plane sees the same IGP metric as its mates. -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Sunday, March 27, 2011 3:26 PM > To: Jakob Heitz > Cc: grow@ietf.org; IETF IDR > Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist:=20 > risk of inconsistent path selection >=20 >=20 > Exactly. So what is the problem within this thread which you=20 > claim that=20 > clients may "risk of inconsistent path selection" ? >=20 > R. >=20 > > This is standard BGP if the IGP metrics are equal. > > > > -- > > Jakob Heitz. > > > > > >> -----Original Message----- > >> From: Robert Raszuk [mailto:raszuk@cisco.com] > >> Sent: Sunday, March 27, 2011 3:17 PM > >> To: Jakob Heitz > >> Cc: grow@ietf.org; IETF IDR > >> Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: > >> risk of inconsistent path selection > >> > >> Jakob, > >> > >> > To prevent clients in different clusters from choosing > >> > different bestpaths based on tie breaker (f): > >> > >> Can you restate what is the problem with the above ? > >> > >> Today clients would chose different best paths when IGP=20 > metric to one > >> next hop is closest on one to NH1 and closest on the other to > >> NH2. And > >> this check happens well above step (f). > >> > >> How is this at all related to the diverse path draft like=20 > the subject > >> could indicate ? > >> > >> Thx, > >> R. > >> > >> > >> > >>> Route selection tie breakers in RFC 4271 state: > >>> > >>> f) Remove from consideration all routes other than > >> the route that > >>> was advertised by the BGP speaker with the lowest BGP > >>> Identifier value. > >>> > >>> g) Prefer the route received from the lowest peer address. > >>> > >>> Suppose RR Planes use different BGP Identifier values. > >>> If they use the same BGP Identifier, a similar argument > >>> can be made for peer address. > >>> > >>> To prevent clients in different clusters from choosing > >>> different bestpaths based on tie breaker (f): > >>> > >>> The RR Plane that advertises the best path MUST be configured > >>> with a BGP Identifier higher than that of the RR Plane that > >>> advertises the 2nd best. This must be higher than that of > >>> the Plane that advertises the 3rd best and so on. > >>> > >>> I'm not sure if this rule completely solves the problem. > >>> If not, then the "Edge_Discriminator attribute" proposed > >>> by draft-pmohapat-idr-fast-conn-restore may be required. > >>> Also, this would need to be applied before rule (f). > >>> > >>> -- > >>> Jakob Heitz. > >>> > >>> _______________________________________________ > >>> GROW mailing list > >>> GROW@ietf.org > >>> https://www.ietf.org/mailman/listinfo/grow > >>> > >> > >> >=20 > = From raszuk@cisco.com Sun Mar 27 16:00:18 2011 Return-Path: <raszuk@cisco.com> 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 DC01028C17D; Sun, 27 Mar 2011 16:00: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-a5qVvgI+1u; Sun, 27 Mar 2011 16:00:17 -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 8BE7828C0E2; Sun, 27 Mar 2011 16:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=4663; q=dns/txt; s=iport; t=1301266914; x=1302476514; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fuAlxvxiwy8VMMWAmNw+3JAaE8UNdWARIR7txQVW934=; b=APgPU2Pb2VmykSXZfQvDAJpNNHF31b1CfhvIUPFOLoH53HQyThAtGegT 8f3k2u7VN5IXA/2kNFGFsX/5Mrt7XZ8OCpiYn6W9voOLbttoGHz+56DNJ 1XyJH+lxxVokw0QyrXV+xXZo8Yotu5g8DfasHjwzrFAXrz87mVYHU3Wu6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAELBj02rRDoG/2dsb2JhbACYE40+d4hrnCyCbw4Bl3aFaQSMd4NU X-IronPort-AV: E=Sophos;i="4.63,252,1299456000"; d="scan'208";a="325472702" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 27 Mar 2011 23:01:54 +0000 Received: from [10.21.104.107] (sjc-vpnasa1-107.cisco.com [10.21.104.107]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2RN1rKt021150; Sun, 27 Mar 2011 23:01:53 GMT Message-ID: <4D8FC1E0.6000809@cisco.com> Date: Mon, 28 Mar 2011 01:01:52 +0200 From: Robert Raszuk <raszuk@cisco.com> 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 <jakob.heitz@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> <4D8FB770.8090901@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCD@EUSAACMS0701.eamcs.ericsson.se> <4D8FB975.1030809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECD2@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECD2@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 23:00:19 -0000 Hi, > C1 will choose second best and C2 will choose best. I am sorry but each client will choose the best and backup path among the paths it receives. And this selection are normal IBGP best path selection. We are not really defining an AS wide path ordering in this work. All we are doing is distributing more paths to clients so they could use it for backup or load-balancing purposes. Are you saying that what RR considers as backup may be chosen as best by the client ? That seems to me perfectly fine. Client has no need to choose the same path as the RR. Because the second path would be a backup path on the client. With hop by hop IP lookup this is the reality today. With tunnels of some sort this becomes completely transparent, but this is different story and diverse-path does not require tunneling. Even today RRs may choose different best path when they are full meshed and advertise different to each client. Then client is at his own freedom to choose order of paths as he likes. Moreover the same behaviour would be in add-paths. Among advertised paths there is no ordering and clients can choose whichever order it consider's correct. Cheers, R. > Suppose 2 clusters. > Cluster 1 has 2 diverse path speakers, RR11 and RR12 > and client C1. > Cluster 2 has 2 diverse path speakers, RR21 and RR22. > and client C2. > > Suppose BGP Identifiers: > RR11 = 11 advertises best > RR12 = 12 advertises second best > RR21 = 21 advertises second best > RR22 = 22 advertises best > > If the tie breaker reaches step (f), > C1 will choose second best and C2 will choose best. > > The rule I state will prevent the inconsistency. > > I assume that the IGP metric problem at the RRs > has been fixed such that each RR plane > sees the same IGP metric as its mates. > > -- > Jakob Heitz. > > >> -----Original Message----- >> From: Robert Raszuk [mailto:raszuk@cisco.com] >> Sent: Sunday, March 27, 2011 3:26 PM >> To: Jakob Heitz >> Cc: grow@ietf.org; IETF IDR >> Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: >> risk of inconsistent path selection >> >> >> Exactly. So what is the problem within this thread which you >> claim that >> clients may "risk of inconsistent path selection" ? >> >> R. >> >>> This is standard BGP if the IGP metrics are equal. >>> >>> -- >>> Jakob Heitz. >>> >>> >>>> -----Original Message----- >>>> From: Robert Raszuk [mailto:raszuk@cisco.com] >>>> Sent: Sunday, March 27, 2011 3:17 PM >>>> To: Jakob Heitz >>>> Cc: grow@ietf.org; IETF IDR >>>> Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: >>>> risk of inconsistent path selection >>>> >>>> Jakob, >>>> >>>> > To prevent clients in different clusters from choosing >>>> > different bestpaths based on tie breaker (f): >>>> >>>> Can you restate what is the problem with the above ? >>>> >>>> Today clients would chose different best paths when IGP >> metric to one >>>> next hop is closest on one to NH1 and closest on the other to >>>> NH2. And >>>> this check happens well above step (f). >>>> >>>> How is this at all related to the diverse path draft like >> the subject >>>> could indicate ? >>>> >>>> Thx, >>>> R. >>>> >>>> >>>> >>>>> Route selection tie breakers in RFC 4271 state: >>>>> >>>>> f) Remove from consideration all routes other than >>>> the route that >>>>> was advertised by the BGP speaker with the lowest BGP >>>>> Identifier value. >>>>> >>>>> g) Prefer the route received from the lowest peer address. >>>>> >>>>> Suppose RR Planes use different BGP Identifier values. >>>>> If they use the same BGP Identifier, a similar argument >>>>> can be made for peer address. >>>>> >>>>> To prevent clients in different clusters from choosing >>>>> different bestpaths based on tie breaker (f): >>>>> >>>>> The RR Plane that advertises the best path MUST be configured >>>>> with a BGP Identifier higher than that of the RR Plane that >>>>> advertises the 2nd best. This must be higher than that of >>>>> the Plane that advertises the 3rd best and so on. >>>>> >>>>> I'm not sure if this rule completely solves the problem. >>>>> If not, then the "Edge_Discriminator attribute" proposed >>>>> by draft-pmohapat-idr-fast-conn-restore may be required. >>>>> Also, this would need to be applied before rule (f). >>>>> >>>>> -- >>>>> Jakob Heitz. >>>>> >>>>> _______________________________________________ >>>>> GROW mailing list >>>>> GROW@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/grow >>>>> >>>> >>>> >> >> From jakob.heitz@ericsson.com Sun Mar 27 16:15:18 2011 Return-Path: <jakob.heitz@ericsson.com> 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 4689A3A684B; Sun, 27 Mar 2011 16:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 LHpFZizYrfWF; Sun, 27 Mar 2011 16:15:17 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 155773A67AB; Sun, 27 Mar 2011 16:15:17 -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 p2RNGqrT009906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Mar 2011 18:16:53 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 27 Mar 2011 19:16:52 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "raszuk@cisco.com" <raszuk@cisco.com> Date: Sun, 27 Mar 2011 19:16:49 -0400 Thread-Topic: [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection Thread-Index: Acvs0vn0eAe2e8QeRvuy3kz0z1qaMwAAElWg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECDC@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> <4D8FB770.8090901@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCD@EUSAACMS0701.eamcs.ericsson.se> <4D8FB975.1030809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECD2@EUSAACMS0701.eamcs.ericsson.se> <4D8FC1E0.6000809@cisco.com> In-Reply-To: <4D8FC1E0.6000809@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: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Mar 2011 23:15:18 -0000 Again, if the tie breaker reaches step (f), the client will use the BGP Identifier of the RR it receives the path from to choose its best. In BGP, we like all speakers to choose the same path unless IGP metrics are different. With diverse-path, there is a possibility that different speakers choose different paths even if IGP metrics are the same. If the clients were to receive their paths from the source speaker, they would choose the same path at tie breaker (f). draft-pmohapat-idr-fast-conn-restore proposes the Edge_Discriminator attribute to fix it. It may not be a problem. However, the path selection is different than without diverse-path, therefore the behaviour needs to be stated in the draft. The rule I stated will remove the inconsistency. -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Sunday, March 27, 2011 4:02 PM > To: Jakob Heitz > Cc: grow@ietf.org; IETF IDR > Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist:=20 > risk of inconsistent path selection >=20 > Hi, >=20 > > C1 will choose second best and C2 will choose best. >=20 > I am sorry but each client will choose the best and backup path among=20 > the paths it receives. And this selection are normal IBGP best path=20 > selection. We are not really defining an AS wide path=20 > ordering in this=20 > work. All we are doing is distributing more paths to clients so they=20 > could use it for backup or load-balancing purposes. >=20 > Are you saying that what RR considers as backup may be chosen=20 > as best by=20 > the client ? >=20 > That seems to me perfectly fine. Client has no need to choose=20 > the same=20 > path as the RR. Because the second path would be a backup path on the=20 > client. With hop by hop IP lookup this is the reality today. With=20 > tunnels of some sort this becomes completely transparent, but this is=20 > different story and diverse-path does not require tunneling. >=20 > Even today RRs may choose different best path when they are=20 > full meshed=20 > and advertise different to each client. Then client is at his own=20 > freedom to choose order of paths as he likes. >=20 > Moreover the same behaviour would be in add-paths. Among advertised=20 > paths there is no ordering and clients can choose whichever order it=20 > consider's correct. >=20 > Cheers, > R. >=20 > > Suppose 2 clusters. > > Cluster 1 has 2 diverse path speakers, RR11 and RR12 > > and client C1. > > Cluster 2 has 2 diverse path speakers, RR21 and RR22. > > and client C2. > > > > Suppose BGP Identifiers: > > RR11 =3D 11 advertises best > > RR12 =3D 12 advertises second best > > RR21 =3D 21 advertises second best > > RR22 =3D 22 advertises best > > > > If the tie breaker reaches step (f), > > C1 will choose second best and C2 will choose best. > > > > The rule I state will prevent the inconsistency. > > > > I assume that the IGP metric problem at the RRs > > has been fixed such that each RR plane > > sees the same IGP metric as its mates. > > > > -- > > Jakob Heitz. > > > > > >> -----Original Message----- > >> From: Robert Raszuk [mailto:raszuk@cisco.com] > >> Sent: Sunday, March 27, 2011 3:26 PM > >> To: Jakob Heitz > >> Cc: grow@ietf.org; IETF IDR > >> Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: > >> risk of inconsistent path selection > >> > >> > >> Exactly. So what is the problem within this thread which you > >> claim that > >> clients may "risk of inconsistent path selection" ? > >> > >> R. > >> > >>> This is standard BGP if the IGP metrics are equal. > >>> > >>> -- > >>> Jakob Heitz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Robert Raszuk [mailto:raszuk@cisco.com] > >>>> Sent: Sunday, March 27, 2011 3:17 PM > >>>> To: Jakob Heitz > >>>> Cc: grow@ietf.org; IETF IDR > >>>> Subject: Re: [GROW] draft-ietf-grow-diverse-bgp-path-dist: > >>>> risk of inconsistent path selection > >>>> > >>>> Jakob, > >>>> > >>>> > To prevent clients in different clusters from choosing > >>>> > different bestpaths based on tie breaker (f): > >>>> > >>>> Can you restate what is the problem with the above ? > >>>> > >>>> Today clients would chose different best paths when IGP > >> metric to one > >>>> next hop is closest on one to NH1 and closest on the other to > >>>> NH2. And > >>>> this check happens well above step (f). > >>>> > >>>> How is this at all related to the diverse path draft like > >> the subject > >>>> could indicate ? > >>>> > >>>> Thx, > >>>> R. > >>>> > >>>> > >>>> > >>>>> Route selection tie breakers in RFC 4271 state: > >>>>> > >>>>> f) Remove from consideration all routes other than > >>>> the route that > >>>>> was advertised by the BGP speaker with the=20 > lowest BGP > >>>>> Identifier value. > >>>>> > >>>>> g) Prefer the route received from the lowest=20 > peer address. > >>>>> > >>>>> Suppose RR Planes use different BGP Identifier values. > >>>>> If they use the same BGP Identifier, a similar argument > >>>>> can be made for peer address. > >>>>> > >>>>> To prevent clients in different clusters from choosing > >>>>> different bestpaths based on tie breaker (f): > >>>>> > >>>>> The RR Plane that advertises the best path MUST be configured > >>>>> with a BGP Identifier higher than that of the RR Plane that > >>>>> advertises the 2nd best. This must be higher than that of > >>>>> the Plane that advertises the 3rd best and so on. > >>>>> > >>>>> I'm not sure if this rule completely solves the problem. > >>>>> If not, then the "Edge_Discriminator attribute" proposed > >>>>> by draft-pmohapat-idr-fast-conn-restore may be required. > >>>>> Also, this would need to be applied before rule (f). > >>>>> > >>>>> -- > >>>>> Jakob Heitz. > >>>>> > >>>>> _______________________________________________ > >>>>> GROW mailing list > >>>>> GROW@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/grow > >>>>> > >>>> > >>>> > >> > >> >=20 > = From yakov@juniper.net Mon Mar 28 08:52:48 2011 Return-Path: <yakov@juniper.net> 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 4469B3A67CF for <idr@core3.amsl.com>; Mon, 28 Mar 2011 08:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.778 X-Spam-Level: X-Spam-Status: No, score=-105.778 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, 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 ko52V2O-qqep for <idr@core3.amsl.com>; Mon, 28 Mar 2011 08:52:46 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 0BE473A6870 for <idr@ietf.org>; Mon, 28 Mar 2011 08:52:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTZCvLhWPU60BShMMAjaRBrLtSGpvxzZ0@postini.com; Mon, 28 Mar 2011 08:54:23 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Mar 2011 08:49:47 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p2SFpFv56866 for <idr@ietf.org>; Mon, 28 Mar 2011 08:51:15 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201103281551.p2SFpFv56866@magenta.juniper.net> To: <idr@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24663.1301327475.1@juniper.net> Date: Mon, 28 Mar 2011 08:51:15 -0700 From: Yakov Rekhter <yakov@juniper.net> Subject: [Idr] I-D Action:draft-ietf-idr-rfc4760bis-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Mar 2011 15:52:48 -0000 Folks, I just posted the -01 version that reflects the change mentioned below. Yakov. ------- Forwarded Message Date: Wed, 16 Feb 2011 06:12:49 -0800 From: Yakov Rekhter <yakov@juniper.net> To: Ilya Varlashkin <ilya@nobulus.com> cc: IETF IDR <idr@ietf.org>, yakov@juniper.net Subject: Re: [Idr] I-D Action:draft-ietf-idr-rfc4760bis-00.txt Ilya, > As I've previously mentioned in private conversation, this draft > seem like a perfect place to address an issue of intermixing various > SAFI of the same AFI. The problem has been discussed here at IDR > ("interoperability of 6PE and native -IPv6 within same network" - > http://www.ietf.org/mail-archive/web/idr/current/m sg04364.html). > What's group view on adding something along following line to th e > draft: if a route has been learned from AFI=x SAFI=y1, then BGP > speaker MAY NOT advertise it over a SAFI=y2 session unless speaker > sets itself as NEXT_HOP? To address the above let me propose that we'll add the following: A router SHALL NOT redistribute routing information received over one particular combination of <AFI, SAFI> into another <AFI, SAFI> unless explicitly configured. The implications of doing such redistribution are numerous and serious, but outside the scope of this document. If a router is explicitly configured to redistribute routing information received over one particular combination of <AFI, SAFI> over another <AFI, SAFI>, then when redistributing the information the router MUST set NEXT_HOP to self. In the absence of any objections within the next two weeks I'll re-issue a revised version that will include the above text. Yakov. > > On Jan 10, 2011, at 18:45 , Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts director ies. > > This draft is a work item of the Inter-Domain Routing Working Group of the IETF. > > > > > > Title : Multiprotocol Extensions for BGP-4 > > Author(s) : R. Chandra, et al. > > Filename : draft-ietf-idr-rfc4760bis-00.txt > > Pages : 12 > > Date : 2011-01-10 > > > > This document defines extensions to BGP-4 to enable it to carry > > routing information for multiple Network Layer protocols (e.g., IPv6, > > IPX, L3VPN, etc...). The extensions are backward compatible - a > > router that supports the extensions can interoperate with a router > > that doesn't support the extensions. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-00.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. > > <Mail Attachment>_______________________________________________ > > 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 ------- End of Forwarded Message From Internet-Drafts@ietf.org Mon Mar 28 09:00:02 2011 Return-Path: <Internet-Drafts@ietf.org> 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 AC9F828C0E9; Mon, 28 Mar 2011 09:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 ZcmXcSix-07R; Mon, 28 Mar 2011 09:00:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119AC3A6973; Mon, 28 Mar 2011 09:00:02 -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.13 Message-ID: <20110328160002.22669.71910.idtracker@localhost> Date: Mon, 28 Mar 2011 09:00:02 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-rfc4760bis-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Mar 2011 16:00:03 -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 : Multiprotocol Extensions for BGP-4 Author(s) : R. Chandra, et al. Filename : draft-ietf-idr-rfc4760bis-01.txt Pages : 13 Date : 2011-03-28 This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-01.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-rfc4760bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-28084523.I-D@ietf.org> --NextPart-- From raszuk@cisco.com Mon Mar 28 14:29:18 2011 Return-Path: <raszuk@cisco.com> 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 7D5143A6A70; Mon, 28 Mar 2011 14:29: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id im240ztFHkWo; Mon, 28 Mar 2011 14:29:15 -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 370AB3A688B; Mon, 28 Mar 2011 14:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1783; q=dns/txt; s=iport; t=1301347853; x=1302557453; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PGaJI+e3Z7cJNgj5fX6X+wCrbEVskDMJfRlAAP5+0BI=; b=iuarkk+7fOp1j5xeZG5Cc/hxye/NwFQrPU7bWjl3HRJzxCfKwPFIY8QJ HwfPwM9t2N9nN8DQ3JJPY8pWUiz/1Caitar/axmiu3wch5H/q5sUS8KQa qhrkqjrFKvEbNecv8OBWPsWeVtXXkCHZiK9oTsi6201djW2t1fHGoeBod c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALP9kE2rRDoH/2dsb2JhbAClRHeIa6Adgm8OAZkuhWkEjHeDVA X-IronPort-AV: E=Sophos;i="4.63,257,1299456000"; d="scan'208";a="284425243" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 28 Mar 2011 21:30:53 +0000 Received: from [10.21.106.8] (sjc-vpnasa-517.cisco.com [10.21.106.8]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2SLUp4n010435; Mon, 28 Mar 2011 21:30:52 GMT Message-ID: <4D90FE0B.9060800@cisco.com> Date: Mon, 28 Mar 2011 23:30:51 +0200 From: Robert Raszuk <raszuk@cisco.com> 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 <jakob.heitz@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> <4D8FB770.8090901@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCD@EUSAACMS0701.eamcs.ericsson.se> <4D8FB975.1030809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECD2@EUSAACMS0701.eamcs.ericsson.se> <4D8FC1E0.6000809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECDC@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECDC@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Mar 2011 21:29:18 -0000 Jakob, Diverse-path works between RR and the client and client does not advertise back the best path to other IBGP peers so there is no issue with churn or oscillation. Advertising different paths to possible EBGP peers is a feature not a bug. By definition of diverse path such path will have different next hop hence the metric to next hop would be in most cases a tie breaker. If metric to next hop is the same across both paths I see no reason to mandate any rules which would force different PEs to choose the same path. If operator wishes to prefer one path then the other he will do so by applying local preference. The fact that you like to see all paths in BGP to be selected as the same is not sufficient reason to mandate it on the clients. I see more value and no issue keeping them diverse especially since you are pointing out last step in best path selection. Cheers, R. > Again, if the tie breaker reaches step (f), > the client will use the BGP Identifier of > the RR it receives the path from to choose > its best. > > In BGP, we like all speakers to choose the same > path unless IGP metrics are different. > > With diverse-path, there is a possibility that > different speakers choose different paths even > if IGP metrics are the same. > > If the clients were to receive their paths > from the source speaker, they would choose the > same path at tie breaker (f). > > draft-pmohapat-idr-fast-conn-restore proposes > the Edge_Discriminator attribute to fix it. > > It may not be a problem. However, the path selection is > different than without diverse-path, therefore > the behaviour needs to be stated in the draft. > > The rule I stated will remove the inconsistency. > > -- > Jakob Heitz. From jakob.heitz@ericsson.com Mon Mar 28 15:36:05 2011 Return-Path: <jakob.heitz@ericsson.com> 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 9F2FA3A6A9B; Mon, 28 Mar 2011 15:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 6PiktYaKCI5u; Mon, 28 Mar 2011 15:36:04 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id AD0943A6A9A; Mon, 28 Mar 2011 15:36:04 -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 p2SMbeWG004630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Mar 2011 17:37:41 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 28 Mar 2011 18:37:40 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: "raszuk@cisco.com" <raszuk@cisco.com> Date: Mon, 28 Mar 2011 18:37:38 -0400 Thread-Topic: [Idr] [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection Thread-Index: Acvtj2yW0GUcQZCcRPipSLVN6h4wgwAB0b1w Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F660CAF@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> <4D8FB770.8090901@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCD@EUSAACMS0701.eamcs.ericsson.se> <4D8FB975.1030809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECD2@EUSAACMS0701.eamcs.ericsson.se> <4D8FC1E0.6000809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECDC@EUSAACMS0701.eamcs.ericsson.se> <4D90FE0B.9060800@cisco.com> In-Reply-To: <4D90FE0B.9060800@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: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Mar 2011 22:36:05 -0000 The inventors of BGP added tie breaker rules after IGP metric. It helps to void churn in upstream AS's that would be caused by advertising different paths needlessly. There may be other reasons for these rules too. Apparently, Pradosh found them important enough to invent the Edge_Discriminator attribute to keep these rules working. -- Jakob Heitz. =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Monday, March 28, 2011 2:31 PM > To: Jakob Heitz > Cc: IETF IDR; grow@ietf.org > Subject: Re: [Idr] [GROW]=20 > draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent=20 > path selection >=20 > Jakob, >=20 > Diverse-path works between RR and the client and client does not=20 > advertise back the best path to other IBGP peers so there is no issue=20 > with churn or oscillation. >=20 > Advertising different paths to possible EBGP peers is a=20 > feature not a bug. >=20 > By definition of diverse path such path will have different next hop=20 > hence the metric to next hop would be in most cases a tie breaker. >=20 > If metric to next hop is the same across both paths I see no=20 > reason to=20 > mandate any rules which would force different PEs to choose the same=20 > path. If operator wishes to prefer one path then the other he=20 > will do so=20 > by applying local preference. >=20 > The fact that you like to see all paths in BGP to be selected as the=20 > same is not sufficient reason to mandate it on the clients. I=20 > see more=20 > value and no issue keeping them diverse especially since you are=20 > pointing out last step in best path selection. >=20 > Cheers, > R. >=20 >=20 > > Again, if the tie breaker reaches step (f), > > the client will use the BGP Identifier of > > the RR it receives the path from to choose > > its best. > > > > In BGP, we like all speakers to choose the same > > path unless IGP metrics are different. > > > > With diverse-path, there is a possibility that > > different speakers choose different paths even > > if IGP metrics are the same. > > > > If the clients were to receive their paths > > from the source speaker, they would choose the > > same path at tie breaker (f). > > > > draft-pmohapat-idr-fast-conn-restore proposes > > the Edge_Discriminator attribute to fix it. > > > > It may not be a problem. However, the path selection is > > different than without diverse-path, therefore > > the behaviour needs to be stated in the draft. > > > > The rule I stated will remove the inconsistency. > > > > -- > > Jakob Heitz. > = From jakob.heitz@ericsson.com Mon Mar 28 15:47:09 2011 Return-Path: <jakob.heitz@ericsson.com> 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 88EEC3A6A90; Mon, 28 Mar 2011 15:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 Mhm1+HKEEKrf; Mon, 28 Mar 2011 15:47:08 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 802313A6948; Mon, 28 Mar 2011 15:47:08 -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 p2SMlW7e006711; Mon, 28 Mar 2011 17:48:45 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 28 Mar 2011 18:48:12 -0400 From: Jakob Heitz <jakob.heitz@ericsson.com> To: Jakob Heitz <jakob.heitz@ericsson.com>, "raszuk@cisco.com" <raszuk@cisco.com> Date: Mon, 28 Mar 2011 18:48:11 -0400 Thread-Topic: [GROW] [Idr] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection Thread-Index: Acvtj2yW0GUcQZCcRPipSLVN6h4wgwAB0b1wAADIHpA= Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F660CCD@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> <4D8FB770.8090901@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCD@EUSAACMS0701.eamcs.ericsson.se> <4D8FB975.1030809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECD2@EUSAACMS0701.eamcs.ericsson.se> <4D8FC1E0.6000809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECDC@EUSAACMS0701.eamcs.ericsson.se> <4D90FE0B.9060800@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F660CAF@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F660CAF@EUSAACMS0701.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 Cc: IETF IDR <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org> Subject: Re: [Idr] [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Mar 2011 22:47:09 -0000 I don't want to argue the importance of the tie breaker rules (f) and (g). They may or may not be important. My point is that diverse-path breaks them and my rule fixes it. Here it is again: The RR Plane that advertises the best path MUST be configured with a BGP Identifier higher than that of the RR Plane that advertises the 2nd best. This must be higher than that of the Plane that advertises the 3rd best and so on. -- Jakob Heitz. =20 > -----Original Message----- > From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On=20 > Behalf Of Jakob Heitz > Sent: Monday, March 28, 2011 3:38 PM > To: raszuk@cisco.com > Cc: IETF IDR; grow@ietf.org > Subject: Re: [GROW] [Idr]=20 > draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent=20 > path selection >=20 > The inventors of BGP added tie breaker rules > after IGP metric. >=20 > It helps to void churn in upstream AS's that would > be caused by advertising different paths needlessly. > There may be other reasons for these rules too. >=20 > Apparently, Pradosh found them important enough to > invent the Edge_Discriminator attribute to keep > these rules working. >=20 > -- > Jakob Heitz. > =20 >=20 > > -----Original Message----- > > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > > Sent: Monday, March 28, 2011 2:31 PM > > To: Jakob Heitz > > Cc: IETF IDR; grow@ietf.org > > Subject: Re: [Idr] [GROW]=20 > > draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent=20 > > path selection > >=20 > > Jakob, > >=20 > > Diverse-path works between RR and the client and client does not=20 > > advertise back the best path to other IBGP peers so there=20 > is no issue=20 > > with churn or oscillation. > >=20 > > Advertising different paths to possible EBGP peers is a=20 > > feature not a bug. > >=20 > > By definition of diverse path such path will have different=20 > next hop=20 > > hence the metric to next hop would be in most cases a tie breaker. > >=20 > > If metric to next hop is the same across both paths I see no=20 > > reason to=20 > > mandate any rules which would force different PEs to choose=20 > the same=20 > > path. If operator wishes to prefer one path then the other he=20 > > will do so=20 > > by applying local preference. > >=20 > > The fact that you like to see all paths in BGP to be=20 > selected as the=20 > > same is not sufficient reason to mandate it on the clients. I=20 > > see more=20 > > value and no issue keeping them diverse especially since you are=20 > > pointing out last step in best path selection. > >=20 > > Cheers, > > R. > >=20 > >=20 > > > Again, if the tie breaker reaches step (f), > > > the client will use the BGP Identifier of > > > the RR it receives the path from to choose > > > its best. > > > > > > In BGP, we like all speakers to choose the same > > > path unless IGP metrics are different. > > > > > > With diverse-path, there is a possibility that > > > different speakers choose different paths even > > > if IGP metrics are the same. > > > > > > If the clients were to receive their paths > > > from the source speaker, they would choose the > > > same path at tie breaker (f). > > > > > > draft-pmohapat-idr-fast-conn-restore proposes > > > the Edge_Discriminator attribute to fix it. > > > > > > It may not be a problem. However, the path selection is > > > different than without diverse-path, therefore > > > the behaviour needs to be stated in the draft. > > > > > > The rule I stated will remove the inconsistency. > > > > > > -- > > > Jakob Heitz. > >=20 > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > = From bashandy@cisco.com Mon Mar 28 21:16:12 2011 Return-Path: <bashandy@cisco.com> 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 A968F3A67E1; Mon, 28 Mar 2011 21:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ABTb+gYHhEPF; Mon, 28 Mar 2011 21:16:11 -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 9B7243A67AF; Mon, 28 Mar 2011 21:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=8719; q=dns/txt; s=iport; t=1301372269; x=1302581869; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=vH4BZliYI67x9K2yB1v6hjILLewaJkVYaSWpKegxTtw=; b=TC/l65pQ0gTwGRSnss1JLKG+r6JRPY+VurpsVhDkwxDDqT+eTXsNDgvD IVNZ0t90/tMRq6MrpRQkBV0+jfrwaEBh+mWdUDYnZbxb3brrYX5L5LE3M 2ORKiQ76I9zgyiHPkL3nf9Cgiw5BUn+i4MAbtcv1YSVPNcfIRP8HiMHQc Y=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.63,259,1299456000"; d="asc'?scan'208,217";a="419931510" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 29 Mar 2011 04:17:49 +0000 Received: from [10.21.77.47] ([10.21.77.47]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2T4Hi4C008960; Tue, 29 Mar 2011 04:17:45 GMT Message-ID: <4D915D5D.8030706@cisco.com> Date: Tue, 29 Mar 2011 06:17:33 +0200 From: Ahmed Bashandy <bashandy@cisco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: idr@ietf.org, "rtgwg@ietf.org" <rtgwg@ietf.org> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig296740EB73B0282820BB0F98" Cc: "Burjiz Pithawala \(bpithaw\)" <bpithaw@cisco.com> Subject: [Idr] Fwd: New Version Notification for draft-bashandy-idr-bgp-repair-label-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bashandy@cisco.com List-Id: Inter-Domain Routing <idr.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/idr> List-Post: <mailto:idr@ietf.org> List-Help: <mailto:idr-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Mar 2011 04:16:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig296740EB73B0282820BB0F98 Content-Type: multipart/alternative; boundary="------------000801050304090007040807" This is a multi-part message in MIME format. --------------000801050304090007040807 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, This is a new version of the draft with some corrections based on the fee= dback given so far This is a draft that proposes rerouting traffic, without waiting for BGP = to re-converge, to another PE in a BGP-free core when a PE detects that t= he NH is no longer reachable. Because traffic coming from the core is red= irected back to the core, we propose using a specially advertised label t= o make sure that the traffic does not get re-routed multiple times into t= he core, thus avoiding loops. The draft will be presented during the IDR meeting on Thursday Mar/31/11 All comments now or during the meeting are most welcomed Thanks Ahmed -------- Original Message -------- Subject: New Version Notification for draft-bashandy-idr-bgp-repair-labe= l-01 Date: Mon, 28 Mar 2011 21:11:45 -0700 From: IETF I-D Submission Tool <idsubmission@ietf.org> To: Ahmed Bashandy (bashandy) <bashandy@cisco.com> CC: Burjiz Pithawala (bpithaw) <bpithaw@cisco.com> A new version of I-D, draft-bashandy-idr-bgp-repair-label-01.txt has been= successfully submitted by Ahmed Bashandy and posted to the IETF reposito= ry. Filename: draft-bashandy-idr-bgp-repair-label Revision: 01 Title: Scalable, Loop-Free BGP FRR using Repair Label Creation_date: 2011-03-29 WG ID: Independent Submission Number_of_pages: 13 Abstract: Consider a BGP free core scenario. Suppose the provider edge BGP speaker PE1, PE2,..., PEn know about a prefix P/p via the external routers CE1, CE2,..., CEm. If the PE router PEi loses connectivity to the primary path, whether it is another PE router or a CE router, it desirable to immediately restore traffic by rerouting packets arriving to PEi and destined to the prefix P/p to one of the other PE routers that advertised P/p, say PEj, until BGP re-converges. However if the loss of connectivity of PEi to the primary path also resulted in the loss of connectivity between PEj and CEj, rerouting a packet before the control plane converges may result in a loop. In this document, we propose using a repair label for traffic restoration while avoiding loops. We propose advertising the "repair" label through BGP. = =20 The IETF Secretariat. --------------000801050304090007040807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF= -8"> <meta name=3D"Generator" content=3D"MS Exchange Server version 6.5.7655.10"> <title>New Version Notification for draft-bashandy-idr-bgp-repair-label-01 
Hi,

This is a new version of the draft with some corrections based on the fee=
dback given so far

This is a draft that proposes rerouting traffic, without waiting for BGP =
to re-converge, to another PE in a BGP-free core when a PE detects that t=
he NH is no longer reachable. Because traffic coming from the core is red=
irected back to the core, we propose using a specially advertised label t=
o make sure that the traffic does not get re-routed multiple times into t=
he core, thus avoiding loops.

The draft will be presented during the IDR meeting on Thursday Mar/31/11

All comments now or during the meeting are most welcomed

Thanks

Ahmed


-------- Original Message --------
Subje= ct: New Version Notification for draft-bashandy-idr-bgp-repair-label-01
Date:= Mon, 28 Mar 2011 21:11:45 -0700
From:= IETF I-D Submission Tool <idsubmission@ietf.org><= /td>
To: <= /th> Ahmed Bashandy (bashandy) <bashandy@cisco.com>
CC: <= /th> Burjiz Pithawala (bpithaw) <bpithaw@cisco.com>


New Version Notification for draft-bashandy-idr-bgp-repair-label-01

A new version of I-D, draft-bashandy-idr-bgp-repair-label-01.txt has been successfully submitted by Ahmed Bashandy and posted to the IETF repository.
Filename:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-bashand= y-idr-bgp-repair-label
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 01
Title:=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sca= lable, Loop-Free BGP FRR using Repair Label
Creation_date:=C2=A0=C2=A0 2011-03-29
WG ID:=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ind= ependent Submission
Number_of_pages: 13

Abstract:
Consider a BGP free core scenario. Suppose the provider edge BGP<= br> speaker PE1, PE2,..., PEn know about a prefix P/p via the external
routers CE1, CE2,..., CEm.=C2=A0 If the PE router PEi loses connectivity to
the primary path, whether it is another PE router or a CE router, it
desirable to immediately restore traffic by rerouting packets arriving
to PEi and destined to the prefix P/p to one of the other PE routers
that advertised P/p, say PEj, until BGP re-converges. However if the
loss of connectivity of PEi to the primary path also resulted in the
loss of connectivity between PEj and CEj, rerouting a packet before
the control plane converges may result in a loop. In this document, we
propose using a repair label for traffic restoration while avoiding
loops. We propose advertising the "repair" label through BGP.
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0


The IETF Secretariat.

--------------000801050304090007040807-- --------------enig296740EB73B0282820BB0F98 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFNkV1o+G19kFA5zIYRAlOfAJ0RA7ktxlLmJ284e2nrUMhQkZTaEACdE4gB bSnxJBHZ44uheEoEFm0Sq3k= =t3Mh -----END PGP SIGNATURE----- --------------enig296740EB73B0282820BB0F98-- From raszuk@cisco.com Tue Mar 29 00:41: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 B7E7F3A6886; Tue, 29 Mar 2011 00:41:45 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxQffwYYW0x9; Tue, 29 Mar 2011 00:41:43 -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 91E753A683F; Tue, 29 Mar 2011 00:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=4577; q=dns/txt; s=iport; t=1301384601; x=1302594201; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dExh73bfHyzW9HVxcrZIxM2emgzTGlZwHk6k+fqS8Z4=; b=EEyuVr8f5Fx6EKr6KjzNYR8I5d3wv1Acsok/GbxS0G6Radl8cuqetuYF C+cGEMQP+19+/NjrMQCSHvY2VPiTGh8QwbizySPi3i6m98DVo2cVjI6Bt qU91tLhRQY3K/xOZebqfyLoJ549JQ/rcLwCqdrfAYtqWa5WBc4dMxTaKp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAALiMkU2rRDoJ/2dsb2JhbACYD402d4h5nkqCcA4BmT6FagSNAoNU X-IronPort-AV: E=Sophos;i="4.63,260,1299456000"; d="scan'208";a="284702868" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2011 07:43:03 +0000 Received: from [10.21.106.8] (sjc-vpnasa-517.cisco.com [10.21.106.8]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2T7h2c7018014; Tue, 29 Mar 2011 07:43:02 GMT Message-ID: <4D918D86.9020908@cisco.com> Date: Tue, 29 Mar 2011 09:43: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: Jakob Heitz References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCA@EUSAACMS0701.eamcs.ericsson.se> <4D8FB770.8090901@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCD@EUSAACMS0701.eamcs.ericsson.se> <4D8FB975.1030809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECD2@EUSAACMS0701.eamcs.ericsson.se> <4D8FC1E0.6000809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECDC@EUSAACMS0701.eamcs.ericsson.se> <4D90FE0B.9060800@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F660CAF@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21390E3F660CCD@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F660CCD@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR , "grow@ietf.org" Subject: Re: [Idr] [GROW] draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent path selection 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: Tue, 29 Mar 2011 07:41:45 -0000 Jakob, > I don't want to argue the importance of the tie breaker > rules (f) and (g). They may or may not be important. Just because the above steps are in place there is no guarantee even today that all bgp speakers within the domain will declare the same very path as best. Especially RR clusters as not all RR clients clearly need to be connected to all clusters. That is also why RRs were recommended to be in the data plane topologically in the path between the rest of the network and it's clients. > My point is that diverse-path breaks them and > my rule fixes it. Here it is again: Diverse-path does not break them. It only allows for more paths to be distributed to clients. > The RR Plane that advertises the best path MUST be configured > with a BGP Identifier higher than that of the RR Plane that > advertises the 2nd best. This must be higher than that of > the Plane that advertises the 3rd best and so on. Sorry but this rule is not applicable to your problem in the first place. Your problem was described to be seen across RR clusters. Moreover .. the same RR running single BGP process may serve both set of clients: .. those interested in best path, those interested in 2nd best, those interested in Nth best and so on. And all implementations I am familiar with have single BGP Identifier for any given BGP speaker. R. >> -----Original Message----- >> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On >> Behalf Of Jakob Heitz >> Sent: Monday, March 28, 2011 3:38 PM >> To: raszuk@cisco.com >> Cc: IETF IDR; grow@ietf.org >> Subject: Re: [GROW] [Idr] >> draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent >> path selection >> >> The inventors of BGP added tie breaker rules >> after IGP metric. >> >> It helps to void churn in upstream AS's that would >> be caused by advertising different paths needlessly. >> There may be other reasons for these rules too. >> >> Apparently, Pradosh found them important enough to >> invent the Edge_Discriminator attribute to keep >> these rules working. >> >> -- >> Jakob Heitz. >> >> >>> -----Original Message----- >>> From: Robert Raszuk [mailto:raszuk@cisco.com] >>> Sent: Monday, March 28, 2011 2:31 PM >>> To: Jakob Heitz >>> Cc: IETF IDR; grow@ietf.org >>> Subject: Re: [Idr] [GROW] >>> draft-ietf-grow-diverse-bgp-path-dist: risk of inconsistent >>> path selection >>> >>> Jakob, >>> >>> Diverse-path works between RR and the client and client does not >>> advertise back the best path to other IBGP peers so there >> is no issue >>> with churn or oscillation. >>> >>> Advertising different paths to possible EBGP peers is a >>> feature not a bug. >>> >>> By definition of diverse path such path will have different >> next hop >>> hence the metric to next hop would be in most cases a tie breaker. >>> >>> If metric to next hop is the same across both paths I see no >>> reason to >>> mandate any rules which would force different PEs to choose >> the same >>> path. If operator wishes to prefer one path then the other he >>> will do so >>> by applying local preference. >>> >>> The fact that you like to see all paths in BGP to be >> selected as the >>> same is not sufficient reason to mandate it on the clients. I >>> see more >>> value and no issue keeping them diverse especially since you are >>> pointing out last step in best path selection. >>> >>> Cheers, >>> R. >>> >>> >>>> Again, if the tie breaker reaches step (f), >>>> the client will use the BGP Identifier of >>>> the RR it receives the path from to choose >>>> its best. >>>> >>>> In BGP, we like all speakers to choose the same >>>> path unless IGP metrics are different. >>>> >>>> With diverse-path, there is a possibility that >>>> different speakers choose different paths even >>>> if IGP metrics are the same. >>>> >>>> If the clients were to receive their paths >>>> from the source speaker, they would choose the >>>> same path at tie breaker (f). >>>> >>>> draft-pmohapat-idr-fast-conn-restore proposes >>>> the Edge_Discriminator attribute to fix it. >>>> >>>> It may not be a problem. However, the path selection is >>>> different than without diverse-path, therefore >>>> the behaviour needs to be stated in the draft. >>>> >>>> The rule I stated will remove the inconsistency. >>>> >>>> -- >>>> Jakob Heitz. >>> >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >> From Internet-Drafts@ietf.org Tue Mar 29 01:00: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 8F0D93A6AA7; Tue, 29 Mar 2011 01:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 KKjTrwNGBbUN; Tue, 29 Mar 2011 01:00:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56B23A6A88; Tue, 29 Mar 2011 01: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.14 Message-ID: <20110329080001.3410.32894.idtracker@localhost> Date: Tue, 29 Mar 2011 01:00:01 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-bgp-multisession-06.txt 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, 29 Mar 2011 08: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 : Multisession BGP Author(s) : J. Scudder, et al. Filename : draft-ietf-idr-bgp-multisession-06.txt Pages : 19 Date : 2011-03-29 This specification augments "Multiprotocol Extensions for BGP-4" (MP- BGP) by proposing a mechanism to facilitate the use of multiple sessions between a given pair of BGP speakers. Each session is used to transport routes related by some session-based attribute such as AFI/SAFI. This provides an alternative to the MP-BGP approach of multiplexing all routes onto a single connection. Use of this approach is expected to provide finer-grained fault management and isolation as the BGP protocol is used to support more and more diverse services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-multisession-06.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-bgp-multisession-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-29004723.I-D@ietf.org> --NextPart-- From raszuk@cisco.com Tue Mar 29 01:01: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 F21243A6A83; Tue, 29 Mar 2011 01:01:48 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnMmix8yCGi1; Tue, 29 Mar 2011 01:01:47 -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 CDBA23A68E1; Tue, 29 Mar 2011 01:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=3791; q=dns/txt; s=iport; t=1301385806; x=1302595406; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZTy/Ukbfkm+y9kB4rqIz4cdnak5lODxdfpt8jvfPrks=; b=khF7rXZywoYt/4dEVnkksqfSlniFHdYDLLNtunQKF78ORcVfWAC353nb GFfmEH4YYtq4zFCUCfdDTxgHU/znbhtkRAyLuKJrOgKQSSvMmDs8VHTm2 Jmvbz4/7EW9J6QDq/89fhsiTpw7AYfH9I+ovhgu3xkZxmcnhjq0MlH76O c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAGiRkU2rRDoJ/2dsb2JhbACYD402d4h5nmCCcA4BmT+FagSNAoNU X-IronPort-AV: E=Sophos;i="4.63,260,1299456000"; d="scan'208";a="326472826" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 29 Mar 2011 08:03:25 +0000 Received: from [10.21.106.8] (sjc-vpnasa-517.cisco.com [10.21.106.8]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2T83OQJ032513; Tue, 29 Mar 2011 08:03:24 GMT Message-ID: <4D91924C.4080709@cisco.com> Date: Tue, 29 Mar 2011 10:03:24 +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: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAF@EUSAACMS0701.eamcs.ericsson.se> <4D8FA215.7020809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC3@EUSAACMS0701.eamcs.ericsson.se> <4D8FAB01.2090407@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCC@EUSAACMS0701.eamcs.ericsson.se> <4D8FB4B4.1040306@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCE@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCE@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IDR , "grow@ietf.org" Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path 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: Tue, 29 Mar 2011 08:01:49 -0000 Hi Jakob, I have discussed this proposed text with other diverse-path co-authors and we concluded that such additional constrain is not required. The reason is that BGP implementations deployed today can easily delay reaction by BGP to IGP bad events flooding while in the same time switchover of the data plane to a pre-installed backup path will happen instantaneously in FIB. This will result in no data plane traffic drop as well as no BGP churn of any kind. Many thx, R. > I propose to add this text to the draft: > > Advertisements of multiple paths by multiple > planes of advertisers are received asynchronously. > It is not possible to order the messages reliably > from different planes. This may cause churn in > route selection when paths change. > > To address this issue, a speaker that advertises the > Nth best path, where N>1, SHOULD delay its advertisement > by MRAI plus (N-1) times X. X SHOULD be a small > value that is greater than the message delivery > time between BGP speakers. Such a speaker should not > add its own MRAI timer to this delay. > > A speaker that advertises the Nth best path shall > initially advertise nothing if an Nth best path > does not exist. Once the Nth best path changes, > it should apply the above delay before sending > the changed advertisement. The change may be a > withdrawal. > > -- > Jakob Heitz. > > >> -----Original Message----- >> From: Robert Raszuk [mailto:raszuk@cisco.com] >> Sent: Sunday, March 27, 2011 3:06 PM >> To: Jakob Heitz >> Cc: grow@ietf.org; IETF IDR >> Subject: Re: [GROW] Potential route flap with bgp-diverse-path >> >> Hi Jakob, >> >>> I mean it switches to P2, then to P3, then >>> back to P2. This does not happen when using add-path. >> >> No one is trying to compare it to add-paths. >> >>> It causes churn if this router readvertises to external >>> peers and P2 has different atributes to P3. >> >> What it needs to be compared against is current BGP deployments. You >> best path from both RRs and when it fails you blackhole >> traffic till BGP >> provides you a new path. >> >> The external re-advertisement is also not really valid >> observation. One >> main reason why EBGP MRAI is longer then IBGP MRAI is exactly to >> mitigate those short lived BGP transitions from being visible in the >> entire Internet. >> >>> The issue is not necessarily a problem. However, it needs >>> to be stated in the draft, so that operators can be >>> aware and avoid the problems. >> >> If you have some text to propose which would first correctly describe >> and clarify the issue I would be happy to incorporate it. >> >> Just keep in mind that diverse-path is a very simple way, >> without need >> to upgrade the client side to provide much better path switchover >> results with no packet drop as compared to what is today. >> >>> That makes it a 3rd RR plane. >>> It means you are recommending at least as many RR planes >>> as possible paths for any destination. >> >> Nope. I think you are drawing conclusions too quickly. >> >> Second client-RR session would allow to advertise best and >> second best >> from any given RR. That means that you would never transition to 3rd >> best even for fraction of time as your R2 would still be there on the >> client. >> >> Keep in mind that some deployment proposal models from customers are >> even today focused on sharing RRs and configuring some clients to get >> best and some to get second best from a given RR even if RRs are in >> pair. And this is just configuration as the diverse-path as will be >> discussed in GROW meeting this week during the implementation >> report is >> a per peer knob. >> >> Many thx, >> R. >> >> >> >> >> >> From jgs@juniper.net Tue Mar 29 01:47: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 E1EE93A692D for ; Tue, 29 Mar 2011 01:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=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 PdWBMR8mmBhQ for ; Tue, 29 Mar 2011 01:47:42 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 11EA53A690E for ; Tue, 29 Mar 2011 01:47:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTZGdDqoiWc00ElDTRvELmiALQobs6QTn@postini.com; Tue, 29 Mar 2011 01:49: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; Tue, 29 Mar 2011 01:43:29 -0700 From: John Scudder To: "idr@ietf.org List" Date: Tue, 29 Mar 2011 01:44:57 -0700 Thread-Topic: WGLC for draft-ietf-idr-mrai-dep-03 Thread-Index: Acvt7WBiwd2yvMSiTy6OuQiqKQjbRw== Message-ID: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@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: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 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, 29 Mar 2011 08:47:45 -0000 Folks, We have been remiss in not WGLC'ing this draft earlier, it has been stable = for some time and is exceptionally short (about a half-page plus boilerplat= e): http://www.ietf.org/internet-drafts/draft-ietf-idr-mrai-dep-03.txt Please send any comments on the draft to the list by April 12, 2011. Thanks, --John= From jgs@juniper.net Tue Mar 29 01:52: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 62D523A687E for ; Tue, 29 Mar 2011 01:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 souI2hwPc0eJ for ; Tue, 29 Mar 2011 01:52:05 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 1F6053A690E for ; Tue, 29 Mar 2011 01:51:59 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTZGeDoBuhCiC0JD123SA3ebzxhwladSM@postini.com; Tue, 29 Mar 2011 01:53:37 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; Tue, 29 Mar 2011 01:46:59 -0700 From: John Scudder To: "idr@ietf.org List" Date: Tue, 29 Mar 2011 01:48:25 -0700 Thread-Topic: [Idr] IDR meeting at IETF-80, call for volunteers Thread-Index: Acvt7d0ToyCcpudUSvuZvMzKzKzxug== Message-ID: References: <6340612B-4A33-4C5C-A950-FBE876E71604@juniper.net> In-Reply-To: <6340612B-4A33-4C5C-A950-FBE876E71604@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] IDR meeting at IETF-80, call for volunteers 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, 29 Mar 2011 08:52:06 -0000 Reminder, it would really help if there is a volunteer as note taker and an= other as Jabber scribe for Thursday's meeting. Please let me know if you'r= e willing. Thanks, --John On Mar 17, 2011, at 5:14 PM, John Scudder wrote: > Folks, >=20 > You will have noticed that our agenda for IETF-80 is very full again. In= addition, Sue will be unable to attend this time so I'll be the only chair= . With the help of the WG members we were able to get through a busy agend= a productively last time. I'd like to ask for help again this time! =20 >=20 > Please: >=20 > * Arrive on time. The meeting is scheduled to start at 13:00. Let's > plan to start working then. > * Consider volunteering to take notes. This is very important -- we > can't start without at least one note-taker. Unlike previous meetings, > the chair can't do it since I'll be the only one. Even if you can't > take notes for the whole meeting (for example because you are presenting= ) > taking some notes would help -- several sets of notes is very useful > when preparing the minutes. > * Consider volunteering as Jabber scribe. We do NOT need every presentat= ion > transcribed to Jabber. The main need is for someone to relay Jabber Q&A > to the mic. > * If you are presenting, get me your slides as early as you can. You may= =20 > revise them if needed, up until 24 hours prior to the meeting. > * If you are attending, review the drafts (and if the presenters have=20 > made them available, the slides) so that you can be prepared to make > good use of our limited Q&A time. Feel free to start Q&A on the list > immediately -- no need to wait for the in-person meeting! >=20 > Thanks in advance. If you are willing to volunteer as note taker or Jabb= er scribe, please let me know. >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Tue Mar 29 02:08: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 ADBE03A68B7 for ; Tue, 29 Mar 2011 02:08:24 -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_43=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 w3xu3-MNKCTx for ; Tue, 29 Mar 2011 02:08:23 -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 BC8A63A67B7 for ; Tue, 29 Mar 2011 02:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=498; q=dns/txt; s=iport; t=1301389802; x=1302599402; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=hJZ5lGjQD+P2eAo37CgABb4R8TijV+2ABsZSlV2oC6w=; b=kWAo5WioqIYszAmu/3PmZoZWSERfkjGhPeII3YF7cyzCrOlNxrl/PDuV +eER6XcGs8/SeXbaUO0sMpCYDn1Lu63j/e1wtVpkbW6csyVJlpCF9LEpw 3JL0+eezxpdOO269135CNahAWozfbm5y0+6ZyWUIilwnvjA6tr+Q2aLXA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgHAL6hkU2rRDoH/2dsb2JhbACYTox3d4h5nlOCcA4BmUaFagSNAoNU X-IronPort-AV: E=Sophos;i="4.63,260,1299456000"; d="scan'208";a="284748931" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2011 09:09:46 +0000 Received: from [10.21.106.8] (sjc-vpnasa-517.cisco.com [10.21.106.8]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2T99iFk002290 for ; Tue, 29 Mar 2011 09:09:45 GMT Message-ID: <4D91A1D9.4070006@cisco.com> Date: Tue, 29 Mar 2011 11:09:45 +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: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.net> In-Reply-To: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 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: Tue, 29 Mar 2011 09:08:24 -0000 Support. R. > Folks, > > We have been remiss in not WGLC'ing this draft earlier, it has been stable for some time and is exceptionally short (about a half-page plus boilerplate): > > http://www.ietf.org/internet-drafts/draft-ietf-idr-mrai-dep-03.txt > > Please send any comments on the draft to the list by April 12, 2011. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From jeff.tantsura@ericsson.com Tue Mar 29 02:12:29 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 101F63A67B7 for ; Tue, 29 Mar 2011 02:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.953 X-Spam-Level: X-Spam-Status: No, score=-4.953 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599, J_CHICKENPOX_43=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 k2hIp7AYPaB7 for ; Tue, 29 Mar 2011 02:12:28 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 58E3B3A692D for ; Tue, 29 Mar 2011 02:12:27 -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 p2T9E4PA028265; Tue, 29 Mar 2011 04:14:05 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 29 Mar 2011 05:13:58 -0400 From: Jeff Tantsura To: John Scudder Date: Tue, 29 Mar 2011 05:13:56 -0400 Thread-Topic: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 Thread-Index: Acvt8aJxbRuqCJqDQ4yIieDitJa6kg== Message-ID: References: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.net> In-Reply-To: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@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 Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 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, 29 Mar 2011 09:12:29 -0000 Yes/Support Regards, Jeff On Mar 29, 2011, at 10:49, "John Scudder" wrote: > Folks, >=20 > We have been remiss in not WGLC'ing this draft earlier, it has been stabl= e for some time and is exceptionally short (about a half-page plus boilerpl= ate): >=20 > http://www.ietf.org/internet-drafts/draft-ietf-idr-mrai-dep-03.txt >=20 > Please send any comments on the draft to the list by April 12, 2011. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jhaas@slice.pfrc.org Tue Mar 29 02: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 59BC23A687A for ; Tue, 29 Mar 2011 02:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6, 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 TMdyV2uRKaw5 for ; Tue, 29 Mar 2011 02:18:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id C754B3A6906 for ; Tue, 29 Mar 2011 02:18:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C75D722433A; Tue, 29 Mar 2011 09:20:34 +0000 (UTC) Date: Tue, 29 Mar 2011 09:20:34 +0000 From: Jeffrey Haas To: John Scudder Message-ID: <20110329092034.GA10071@slice> References: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 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, 29 Mar 2011 09:18:58 -0000 On Tue, Mar 29, 2011 at 01:44:57AM -0700, John Scudder wrote: > Folks, > > We have been remiss in not WGLC'ing this draft earlier, it has been stable for some time and is exceptionally short (about a half-page plus boilerplate): > > http://www.ietf.org/internet-drafts/draft-ietf-idr-mrai-dep-03.txt > > Please send any comments on the draft to the list by April 12, 2011. I have read this draft. As a potential minor nit, shouldn't RFC 1771 be an informative reference rather than normative? I can see arguments either way. -- Jeff From rjs@rob.sh Tue Mar 29 02:29: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 103B93A690E for ; Tue, 29 Mar 2011 02:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, NO_RELAYS=-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 8cWd6hK1FY4S for ; Tue, 29 Mar 2011 02:29: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 9A32B3A6948 for ; Tue, 29 Mar 2011 02:29:32 -0700 (PDT) Received: from [2001:df8:0:80:223:6cff:fe9a:e106] by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1Q4VE3-0005aE-Cf; Tue, 29 Mar 2011 10:28:35 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.net> Date: Tue, 29 Mar 2011 11:31:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9EAE4E0D-94B7-4595-B25D-71137FD0B192@rob.sh> References: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1082) Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 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, 29 Mar 2011 09:29:35 -0000 On 29 Mar 2011, at 10:44, John Scudder wrote: > Folks, >=20 > We have been remiss in not WGLC'ing this draft earlier, it has been = stable for some time and is exceptionally short (about a half-page plus = boilerplate): >=20 > http://www.ietf.org/internet-drafts/draft-ietf-idr-mrai-dep-03.txt I have read and support this draft. Kind regards, r.= From bruno.decraene@orange-ftgroup.com Tue Mar 29 03:04: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 BE2EF3A68EC for ; Tue, 29 Mar 2011 03:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=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 HG4HNzWkpCGv for ; Tue, 29 Mar 2011 03:04:29 -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 9D1033A6836 for ; Tue, 29 Mar 2011 03:04:29 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AEB246D8001; Tue, 29 Mar 2011 12:06:40 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id A4CBE6C0001; Tue, 29 Mar 2011 12:06:40 +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, 29 Mar 2011 12:06:07 +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, 29 Mar 2011 12:06:05 +0200 Message-ID: In-Reply-To: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 Thread-Index: Acvt7WBiwd2yvMSiTy6OuQiqKQjbRwACZMYQ References: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.net> From: To: , X-OriginalArrivalTime: 29 Mar 2011 10:06:07.0041 (UTC) FILETIME=[EB971310:01CBEDF8] Subject: Re: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 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, 29 Mar 2011 10:04:30 -0000 Hi all, Ok for deprecating the MRAI default value. =20 Sorry if I'm missing something obvious or already discussed but is there a need to recommend that an AS (SP/ISP) use (hence configure) the same MRAI value for all its IBGP sessions? Also, RFC 4271 made a distinction between iBGP and eBGP sessions (basically MRAI value on iBGP should be lower than on eBGP). Does this need to be added or is this also deprecated? Thanks, Regards, Bruno > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder > Sent: Tuesday, March 29, 2011 10:45 AM > To: idr@ietf.org List > Subject: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 >=20 > Folks, >=20 > We have been remiss in not WGLC'ing this draft earlier, it has been stable for some time and is > exceptionally short (about a half-page plus boilerplate): >=20 > http://www.ietf.org/internet-drafts/draft-ietf-idr-mrai-dep-03.txt >=20 > Please send any comments on the draft to the list by April 12, 2011. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From paul@jakma.org Tue Mar 29 06:47: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 7899A3A6A27 for ; Tue, 29 Mar 2011 06:47:27 -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 lnlvtkKOqNlS for ; Tue, 29 Mar 2011 06:47:25 -0700 (PDT) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by core3.amsl.com (Postfix) with ESMTP id 06B623A690F for ; Tue, 29 Mar 2011 06:47:23 -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 p2TDmTT7011741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2011 14:48:34 +0100 Date: Tue, 29 Mar 2011 14:48:24 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: bruno.decraene@orange-ftgroup.com In-Reply-To: Message-ID: References: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.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: idr@ietf.org Subject: Re: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 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, 29 Mar 2011 13:47:27 -0000 On Tue, 29 Mar 2011, bruno.decraene@orange-ftgroup.com wrote: > Sorry if I'm missing something obvious or already discussed but is > there a need to recommend that an AS (SP/ISP) use (hence configure) > the same MRAI value for all its IBGP sessions? Also, RFC 4271 made > a distinction between iBGP and eBGP sessions (basically MRAI value > on iBGP should be lower than on eBGP). Does this need to be added > or is this also deprecated? That's out of scope. Implementations may or may not wish to do that. An earlier form of this draft (draft-jakma-mrai-02) gave more of an outline, but it doesn't seem there is a consensus on anything more specific than that the current RFC4271 defaults are not appropriate. regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: *** Rince is wagner@schizo.DAINet.de (We have Joey, we have Fun, we have Linux on a Sun) -- Seen on #Debian From bruno.decraene@orange-ftgroup.com Tue Mar 29 07:06: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 B65253A67E3 for ; Tue, 29 Mar 2011 07:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 LF-oGhkbHxNR for ; Tue, 29 Mar 2011 07:06:42 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id A63793A63D2 for ; Tue, 29 Mar 2011 07:06:41 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4ABF3858007; Tue, 29 Mar 2011 16:14:20 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 390AD778003; Tue, 29 Mar 2011 16:14:20 +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, 29 Mar 2011 16:08:19 +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, 29 Mar 2011 16:08:17 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 Thread-Index: AcvuGBdRBsndkBYrQo2DKc38PfskSgAAO8Eg References: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.net> From: To: X-OriginalArrivalTime: 29 Mar 2011 14:08:19.0149 (UTC) FILETIME=[C166C7D0:01CBEE1A] Cc: idr@ietf.org Subject: Re: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 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, 29 Mar 2011 14:06:42 -0000 Paul, Thanks for your reply. More inline > From: Paul Jakma [mailto:paul@jakma.org] > On Tue, 29 Mar 2011, bruno.decraene@orange-ftgroup.com wrote: >=20 > > Sorry if I'm missing something obvious or already discussed but is > > there a need to recommend that an AS (SP/ISP) use (hence configure) > > the same MRAI value for all its IBGP sessions? Any recommendation on the above point? > > Also, RFC 4271 made > > a distinction between iBGP and eBGP sessions (basically MRAI value > > on iBGP should be lower than on eBGP). Does this need to be added > > or is this also deprecated? >=20 > That's out of scope. Implementations may or may not wish to do that. > An earlier form of this draft (draft-jakma-mrai-02) gave more of an > outline, but it doesn't seem there is a consensus on anything more > specific than that the current RFC4271 defaults are not appropriate. >From your above statement, I understand that the draft only deprecate the 2 default values defined in RFC 4271. Hence the following RFC 4271 text is still applicable: " Since fast convergence is needed within an autonomous system, either (a) the MinRouteAdvertisementIntervalTimer used for internal peers SHOULD be shorter than the MinRouteAdvertisementIntervalTimer used for external peers, or (b) the procedure describe in this section SHOULD NOT apply to routes sent to internal peers." In that case, IMHO, the draft sentence " The appropriate choice of default values is left to the discretion of implementors." Should be augmented with "but as per RFC 4271 default value should be chosen lower for iBGP peer than for eBGP peer". Thanks, Regards, Bruno >=20 > regards, > -- > Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A > Fortune: > *** Rince is wagner@schizo.DAINet.de (We have Joey, we have Fun, we have Linux on a Sun) > -- Seen on #Debian From paul@jakma.org Tue Mar 29 07:44: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 62B043A6824 for ; Tue, 29 Mar 2011 07:44:27 -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 eB24F68Rg3jQ for ; Tue, 29 Mar 2011 07:44:26 -0700 (PDT) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by core3.amsl.com (Postfix) with ESMTP id 10F6D3A682D for ; Tue, 29 Mar 2011 07:44:25 -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 p2TEjWWT012736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2011 15:45:37 +0100 Date: Tue, 29 Mar 2011 15:45:27 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: bruno.decraene@orange-ftgroup.com In-Reply-To: Message-ID: References: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.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: idr@ietf.org Subject: Re: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 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, 29 Mar 2011 14:44:27 -0000 On Tue, 29 Mar 2011, bruno.decraene@orange-ftgroup.com wrote: > Any recommendation on the above point? I don't I'm afraid :). I don't think differing values between peers hurt though. > From your above statement, I understand that the draft only > deprecate the 2 default values defined in RFC 4271. Hence the > following RFC 4271 text is still applicable: " Since fast > convergence is needed within an autonomous system, either (a) the > MinRouteAdvertisementIntervalTimer used for internal peers SHOULD > be shorter than the MinRouteAdvertisementIntervalTimer used for > external peers, or (b) the procedure describe in this section > SHOULD NOT apply to routes sent to internal peers." It should yes. > In that case, IMHO, the draft sentence " The appropriate choice of > default values is left to the discretion of implementors." Should be > augmented with "but as per RFC 4271 default value should be chosen lower > for iBGP peer than for eBGP peer". The draft as it is tries very hard to not prescribe anything except to remove the default values. Going beyond that likely only leads to an argument. ;) regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: In America, any boy may become president and I suppose that's just one of the risks he takes. -- Adlai Stevenson From bruno.decraene@orange-ftgroup.com Tue Mar 29 08:06: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 6666A3A695D for ; Tue, 29 Mar 2011 08:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 4v6gXEy0qXAY for ; Tue, 29 Mar 2011 08:06:20 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 56E943A6931 for ; Tue, 29 Mar 2011 08:06:20 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5B3698B800A; Tue, 29 Mar 2011 17:08:29 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 522128B8001; Tue, 29 Mar 2011 17:08:29 +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, 29 Mar 2011 17:07: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 17:07:56 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 Thread-Index: AcvuIAx8P6oOp+IaSTCL6Sp1kd9R2gAAROAg References: <5C153416-1444-48AA-A940-7AFB4ADEEB2A@juniper.net> From: To: X-OriginalArrivalTime: 29 Mar 2011 15:07:58.0023 (UTC) FILETIME=[16939D70:01CBEE23] Cc: idr@ietf.org Subject: Re: [Idr] WGLC for draft-ietf-idr-mrai-dep-03 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, 29 Mar 2011 15:06:21 -0000 > > From your above statement, I understand that the draft only > > deprecate the 2 default values defined in RFC 4271. Hence the > > following RFC 4271 text is still applicable: " Since fast > > convergence is needed within an autonomous system, either (a) the > > MinRouteAdvertisementIntervalTimer used for internal peers SHOULD > > be shorter than the MinRouteAdvertisementIntervalTimer used for > > external peers, or (b) the procedure describe in this section > > SHOULD NOT apply to routes sent to internal peers." >=20 > It should yes. >=20 > > In that case, IMHO, the draft sentence " The appropriate choice of > > default values is left to the discretion of implementors." Should be > > augmented with "but as per RFC 4271 default value should be chosen lower > > for iBGP peer than for eBGP peer". >=20 > The draft as it is tries very hard to not prescribe anything except > to remove the default values. My reading of the draft (which can be wrong) is that the above sentence allows each implementation to chose any default value and hence override RFC 4271 recommendation to have a lower value for iBGP MRAI than for eBGP MRAI. As an alternative, what about removing the second sentence? ("The appropriate choice of default values is left to the discretion of implementors.") IMO the first sentence is clear enough ( "The suggested default values for the MinRouteAdvertisementIntervalTimer given in [RFC4271] are deprecated") > Going beyond that likely only leads to an argument. ;) My point was that the second sentence already goes a bit beyond. But really no big deal. It's up to you. From Internet-Drafts@ietf.org Tue Mar 29 10:15: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 C82743A6A74; Tue, 29 Mar 2011 10:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 wXaKjHDPrGhZ; Tue, 29 Mar 2011 10:15:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF603A6A60; Tue, 29 Mar 2011 10:15: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.14 Message-ID: <20110329171501.24405.36657.idtracker@localhost> Date: Tue, 29 Mar 2011 10:15:01 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-aigp-05.txt 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, 29 Mar 2011 17:15: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 : The Accumulated IGP Metric Attribute for BGP Author(s) : R. Fernando, et al. Filename : draft-ietf-idr-aigp-05.txt Pages : 14 Date : 2011-03-29 Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aigp-05.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-aigp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-29100724.I-D@ietf.org> --NextPart-- From jgs@juniper.net Wed Mar 30 02:11: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 6238528C0CE for ; Wed, 30 Mar 2011 02:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 NkLAq69soKAl for ; Wed, 30 Mar 2011 02:11:58 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 246A03A6AFB for ; Wed, 30 Mar 2011 02:11:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTZL0QBVkSO5ooNKnfdjX6hJlcCHizdzr@postini.com; Wed, 30 Mar 2011 02:13:37 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; Wed, 30 Mar 2011 02:11:25 -0700 From: John Scudder To: "idr@ietf.org List" Date: Wed, 30 Mar 2011 02:12:53 -0700 Thread-Topic: Routing Area Open Meeting room change Thread-Index: AcvuunGx+Z6fRMDNRh+PW5XizRdboA== Message-ID: <62D29C50-3B96-4238-871A-D21CB4C17B6C@juniper.net> References: <0bb501cbeeac$e6a72390$b3f56ab0$@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: [Idr] Fwd: Routing Area Open Meeting room change 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, 30 Mar 2011 09:11:59 -0000 FYI. --John Begin forwarded message: From: Adrian Farrel > Date: March 30, 2011 9:34:25 AM GMT+02:00 To: "routing-discussion@ietf.org" > Cc: "rtg-chairs@ietf.org" > Subject: Routing Area Open Meeting room change Reply-To: "Adrian.Farrel@huawei.com" > Fortunately, this is only a change to the next-door room. Chairs: Notifying your WGs might be good. From: 80all-bounces@ietf.org [mailto:80all-b= ounces@ietf.org] On Behalf Of Wanda Lo Sent: 30 March 2011 09:01 To: 80all@ietf.org Subject: [80all] Wednesday 3-30-2011 Agenda Change Hi Everyone, There's a room change in today's afternoon session I (13:00-15:00). RTGAREA has moved to Congress Hall II. CLUE has moved to Congress Hall I. Please note it in on your pocket agenda to reflect the change. Of course, = the agenda on the IETF website (https://datatracker.ietf.org/meeting/80/age= nda.html) always has the most up-to-date information. Thanks, Wanda =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Wanda Lo Internet Engi neering span style=3D'mso-fareast-font-family:"Times New Roma= n";color:black'> 48377 Fremont Blvd., Ste. 117 Fremont, California 94538 / USA +1-510-492-4082 +1-510-492-4001 (fax) www.ietf.org -- Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From aretana@cisco.com Wed Mar 30 02:32:28 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 9D4A828C0DB for ; Wed, 30 Mar 2011 02:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 QlwsPnsvJ8ML for ; Wed, 30 Mar 2011 02:32:27 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EF6CF3A6B3C for ; Wed, 30 Mar 2011 02:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aretana@cisco.com; l=970; q=dns/txt; s=iport; t=1301477646; x=1302687246; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=EbDlVKvh/Nh1a/Dto90wMq/Zm7PWLCWIn3A2Z2Rcl3k=; b=nINyZp7uLEq1kwAyGm+Xmd1tEocAzNwy6pSVM/KQzgYhZpR8ULZfyE4Y cWS4w5VOZlU1b2WUtW0FrOxAosmNn4IHRQeTTcsfLHIAWFOCJUHHorYQp rpi8LyuLim0fOflaeDhnzrTFXv6gJi1iHjdgmpckbr5blmqxaLktBD7zl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoHAKr4kk2tJXHB/2dsb2JhbACYUIx8d6FQnE6FagSFP4si X-IronPort-AV: E=Sophos;i="4.63,267,1299456000"; d="scan'208";a="228056780" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2011 09:34:05 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2U9Y52p004677 for ; Wed, 30 Mar 2011 09:34:05 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 04:34:05 -0500 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, 30 Mar 2011 04:34:01 -0500 Message-ID: <1D23749D4168CC4D8B8652397B5F643204E57756@XMB-RCD-206.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BGP Persistent Route Oscillation Solutions as WG item Thread-Index: AcvuvZpCvuYMMTUzSdedeFT41+7ZiA== From: "Alvaro Retana (aretana)" To: X-OriginalArrivalTime: 30 Mar 2011 09:34:05.0639 (UTC) FILETIME=[9CC22570:01CBEEBD] Subject: [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: Wed, 30 Mar 2011 09:32:28 -0000 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). From jakob.heitz@ericsson.com Wed Mar 30 04:29: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 6830728C0DB; Wed, 30 Mar 2011 04:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 PQf7FY9cpF50; Wed, 30 Mar 2011 04:29:28 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 4734528C13B; Wed, 30 Mar 2011 04:29:27 -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 p2UBV3JL026493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Mar 2011 06:31:04 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 30 Mar 2011 07:31:04 -0400 From: Jakob Heitz To: "raszuk@cisco.com" Date: Wed, 30 Mar 2011 07:31:00 -0400 Thread-Topic: [GROW] Potential route flap with bgp-diverse-path Thread-Index: Acvt58n7BAvT4qnGQD+xefjMjxxf3QA5hO4g Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F6615E3@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21390E3F5BEB34@EUSAACMS0701.eamcs.ericsson.se> <4D8DA854.6060401@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECAF@EUSAACMS0701.eamcs.ericsson.se> <4D8FA215.7020809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECC3@EUSAACMS0701.eamcs.ericsson.se> <4D8FAB01.2090407@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCC@EUSAACMS0701.eamcs.ericsson.se> <4D8FB4B4.1040306@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F5BECCE@EUSAACMS0701.eamcs.ericsson.se> <4D91924C.4080709@cisco.com> In-Reply-To: <4D91924C.4080709@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: IETF IDR , "grow@ietf.org" Subject: Re: [Idr] [GROW] Potential route flap with bgp-diverse-path 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, 30 Mar 2011 11:29:30 -0000 Aww, c'mon Robert, I think it's a great idea. You just need to clean up a few loose ends. -- Jakob Heitz. x25475. 510-566-2901 =20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com]=20 > Sent: Tuesday, March 29, 2011 1:03 AM > To: Jakob Heitz > Cc: grow@ietf.org; IETF IDR > Subject: Re: [GROW] Potential route flap with bgp-diverse-path >=20 > Hi Jakob, >=20 > I have discussed this proposed text with other diverse-path=20 > co-authors=20 > and we concluded that such additional constrain is not required. >=20 > The reason is that BGP implementations deployed today can=20 > easily delay=20 > reaction by BGP to IGP bad events flooding while in the same time=20 > switchover of the data plane to a pre-installed backup path=20 > will happen=20 > instantaneously in FIB. This will result in no data plane=20 > traffic drop=20 > as well as no BGP churn of any kind. >=20 > Many thx, > R. >=20 > > I propose to add this text to the draft: > > > > Advertisements of multiple paths by multiple > > planes of advertisers are received asynchronously. > > It is not possible to order the messages reliably > > from different planes. This may cause churn in > > route selection when paths change. > > > > To address this issue, a speaker that advertises the > > Nth best path, where N>1, SHOULD delay its advertisement > > by MRAI plus (N-1) times X. X SHOULD be a small > > value that is greater than the message delivery > > time between BGP speakers. Such a speaker should not > > add its own MRAI timer to this delay. > > > > A speaker that advertises the Nth best path shall > > initially advertise nothing if an Nth best path > > does not exist. Once the Nth best path changes, > > it should apply the above delay before sending > > the changed advertisement. The change may be a > > withdrawal. > > > > -- > > Jakob Heitz. > > > > > >> -----Original Message----- > >> From: Robert Raszuk [mailto:raszuk@cisco.com] > >> Sent: Sunday, March 27, 2011 3:06 PM > >> To: Jakob Heitz > >> Cc: grow@ietf.org; IETF IDR > >> Subject: Re: [GROW] Potential route flap with bgp-diverse-path > >> > >> Hi Jakob, > >> > >>> I mean it switches to P2, then to P3, then > >>> back to P2. This does not happen when using add-path. > >> > >> No one is trying to compare it to add-paths. > >> > >>> It causes churn if this router readvertises to external > >>> peers and P2 has different atributes to P3. > >> > >> What it needs to be compared against is current BGP=20 > deployments. You > >> best path from both RRs and when it fails you blackhole > >> traffic till BGP > >> provides you a new path. > >> > >> The external re-advertisement is also not really valid > >> observation. One > >> main reason why EBGP MRAI is longer then IBGP MRAI is exactly to > >> mitigate those short lived BGP transitions from being=20 > visible in the > >> entire Internet. > >> > >>> The issue is not necessarily a problem. However, it needs > >>> to be stated in the draft, so that operators can be > >>> aware and avoid the problems. > >> > >> If you have some text to propose which would first=20 > correctly describe > >> and clarify the issue I would be happy to incorporate it. > >> > >> Just keep in mind that diverse-path is a very simple way, > >> without need > >> to upgrade the client side to provide much better path switchover > >> results with no packet drop as compared to what is today. > >> > >>> That makes it a 3rd RR plane. > >>> It means you are recommending at least as many RR planes > >>> as possible paths for any destination. > >> > >> Nope. I think you are drawing conclusions too quickly. > >> > >> Second client-RR session would allow to advertise best and > >> second best > >> from any given RR. That means that you would never=20 > transition to 3rd > >> best even for fraction of time as your R2 would still be=20 > there on the > >> client. > >> > >> Keep in mind that some deployment proposal models from=20 > customers are > >> even today focused on sharing RRs and configuring some=20 > clients to get > >> best and some to get second best from a given RR even if RRs are in > >> pair. And this is just configuration as the diverse-path as will be > >> discussed in GROW meeting this week during the implementation > >> report is > >> a per peer knob. > >> > >> Many thx, > >> R. > >> > >> > >> > >> > >> > >> >=20 > = From jgs@juniper.net Wed Mar 30 06:02: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 B313F3A6A1C for ; Wed, 30 Mar 2011 06:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 a+FqdO3Ticba for ; Wed, 30 Mar 2011 06:02:46 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 594223A6B11 for ; Wed, 30 Mar 2011 06:02:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTZMqU5+K6oyGsXYPtHsvsORpfckJW7Mu@postini.com; Wed, 30 Mar 2011 06:04:25 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; Wed, 30 Mar 2011 06:01:58 -0700 From: John Scudder To: "idr@ietf.org List" Date: Wed, 30 Mar 2011 06:03:28 -0700 Thread-Topic: WGLC for draft-ietf-idr-bgp-issues Thread-Index: Acvu2qc5PJ0AbgIFR6q7bTCD3Yx0PA== 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-bgp-issues 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, 30 Mar 2011 13:02:46 -0000 Folks, This is to start a working group last call for draft-ietf-idr-bgp-issues, "= Issues in Revising BGP-4 (RFC1771 to RFC4271)". As a reminder, this was a = working document used to track the process of updating the BGP base spec. = We want to publish it as an Informational document for posterity. Please post any comments by April 13, 2011. (However in light of the great= length of the draft, we will extend the WGLC if anyone requests it.) http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-issues-04.txt Thanks, --John= From jgs@juniper.net Wed Mar 30 06:11: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 6FFE03A67CC for ; Wed, 30 Mar 2011 06:11:54 -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 RRnWwlFg1Mwb for ; Wed, 30 Mar 2011 06:11:51 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 88B8A3A6781 for ; Wed, 30 Mar 2011 06:11:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTZMsemhPkg1LpHkNWTawMn9iiAcfce+P@postini.com; Wed, 30 Mar 2011 06:13:30 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; Wed, 30 Mar 2011 06:10:12 -0700 From: John Scudder To: "idr@ietf.org List" Date: Wed, 30 Mar 2011 06:11:42 -0700 Thread-Topic: WGLC for draft-ietf-idr-link-bandwidth Thread-Index: Acvu2817+/t9ZhBFRjuosONw3V6jsg== Message-ID: <862D429C-3654-429F-8D8E-169F923B6B18@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: [Idr] WGLC for draft-ietf-idr-link-bandwidth 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, 30 Mar 2011 13:11:54 -0000 Folks, The authors have revised draft-ietf-idr-link-bandwidth to reflect previous = WGLC comments. Since some time has passed we will do another WGLC. Please= send any comments by April 13, 2011. --John= From jgs@juniper.net Wed Mar 30 07:13:01 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 C50DD3A6B65 for ; Wed, 30 Mar 2011 07:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 RtOnSj1lFZhC for ; Wed, 30 Mar 2011 07:13:01 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 72AB53A6B64 for ; Wed, 30 Mar 2011 07:13:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTZM6z8Lpt3ksETgZCJsa9eWMtkENGhZn@postini.com; Wed, 30 Mar 2011 07:14:40 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; Wed, 30 Mar 2011 07:11:49 -0700 From: John Scudder To: "idr@ietf.org List" Date: Wed, 30 Mar 2011 07:09:54 -0700 Thread-Topic: [Idr] Adoption of draft-chen-ebgp-error-handling-00.txt Thread-Index: Acvu5GjmX01l1oH5T/6tEJ2JiAfXow== Message-ID: <93EE4F8A-CF33-4967-B714-7C47D7CB75C2@juniper.net> References: <004901cb816e$64169ba0$2c43d2e0$@com> <4CDBD869.4050102@uclouvain.be> In-Reply-To: <4CDBD869.4050102@uclouvain.be> 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] Adoption of draft-chen-ebgp-error-handling-00.txt 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, 30 Mar 2011 14:13:01 -0000 Belated announcement to the list -- this has been accepted as IDR work. Th= e authors have been asked to work on a merged draft, the goal being to move= forward with a single revised or expanded error handling spec rather than = several. I expect there will be significant discussion and revision as we = proceed. --John On Nov 11, 2010, at 3:02 PM, Susan Hares wrote: > The authors of >=20 >=20 >=20 > draft-chen-ebgp-error-handling-00 > >=20 >=20 >=20 >=20 > Revised Error Handling for BGP Updates from External Neighbors > >=20 >=20 >=20 > have requested this document to be a working group document, and to be > combined with draft-ietf-idr-optional-transitive-03 > . >=20 > Do you support adoption of this draft's content as IDR work? >=20 > This starts a two week call for feedback on adoption. It will end on > 11/25/10. >=20 > Sue From jgs@juniper.net Wed Mar 30 07:13:28 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 03DC03A6B64 for ; Wed, 30 Mar 2011 07:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 WUM-7PskzlbV for ; Wed, 30 Mar 2011 07:13:27 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 3AE5B3A6A34 for ; Wed, 30 Mar 2011 07:13:27 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTZM66ZKj5a4UcZdOYl6c8lJedmdzVv0l@postini.com; Wed, 30 Mar 2011 07:15:06 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; Wed, 30 Mar 2011 07:12:41 -0700 From: John Scudder To: "idr@ietf.org List" Date: Wed, 30 Mar 2011 07:14:08 -0700 Thread-Topic: [Idr] Adoption of draft-chen-ebgp-error-handling-00.txt Thread-Index: Acvu5Ifr5HUQ0ryhR12RhMNi9/bb2w== Message-ID: <6D89B98E-8DB2-42AF-AB50-BDCE439F2670@juniper.net> References: <004901cb816e$64169ba0$2c43d2e0$@com> <4CDBD869.4050102@uclouvain.be> In-Reply-To: <4CDBD869.4050102@uclouvain.be> 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] Adoption of draft-chen-ebgp-error-handling-00.txt 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, 30 Mar 2011 14:13:28 -0000 Belated announcement to the list -- this has been accepted as IDR work. Th= e authors have been asked to work on a merged draft, the goal being to move= forward with a single revised or expanded error handling spec rather than = several. I expect there will be significant discussion and revision as we = proceed. --John On Nov 11, 2010, at 3:02 PM, Susan Hares wrote: > The authors of >=20 >=20 >=20 > draft-chen-ebgp-error-handling-00 > >=20 >=20 >=20 >=20 > Revised Error Handling for BGP Updates from External Neighbors > >=20 >=20 >=20 > have requested this document to be a working group document, and to be > combined with draft-ietf-idr-optional-transitive-03 > . >=20 > Do you support adoption of this draft's content as IDR work? >=20 > This starts a two week call for feedback on adoption. It will end on > 11/25/10. >=20 > Sue From ietfc@btconnect.com Wed Mar 30 10:19: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 086B43A6BA6 for ; Wed, 30 Mar 2011 10:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, J_CHICKENPOX_25=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 E8--Ez4ykS+8 for ; Wed, 30 Mar 2011 10:18:59 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by core3.amsl.com (Postfix) with ESMTP id 1EC773A6BAF for ; Wed, 30 Mar 2011 10:18:54 -0700 (PDT) Received: from host217-44-145-1.range217-44.btcentralplus.com (HELO pc6) ([217.44.145.1]) by c2bthomr07.btconnect.com with SMTP id CNA21847; Wed, 30 Mar 2011 18:20:30 +0100 (BST) Message-ID: <01b701cbeef6$5159db80$4001a8c0@gateway.2wire.net> From: "t.petch" To: "John Scudder" , References: Date: Wed, 30 Mar 2011 18:19:56 +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.0A0B0303.4D93665D.00D2, actions=TAG X-Junkmail-Premium-Raw: score=26/50, refid=2.7.2:2011.3.30.103320:17:26.894, ip=217.44.145.1, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __CP_URI_IN_BODY, BODY_SIZE_1500_1599, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, __URI_NS, SXL_IP_DYNAMIC[1.145.44.217.fur], BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=26/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4D93665E.012E,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-issues 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, 30 Mar 2011 17:19:00 -0000 ----- Original Message ----- From: "John Scudder" To: Sent: Wednesday, March 30, 2011 3:03 PM Subject: [Idr] WGLC for draft-ietf-idr-bgp-issues > Folks, > > This is to start a working group last call for draft-ietf-idr-bgp-issues, "Issues in Revising BGP-4 (RFC1771 to RFC4271)". As a reminder, this was a working document used to track the process of updating the BGP base spec. We want to publish it as an Informational document for posterity. Weeelll not really. As the I-D says, it tracks updates from Aug 2002 onwards by which time there had been many revisions and many issues raised and at least some resolved. It should not claim to be a comprehensive record of decisions taken, rather it should make it clear, in the Abstract, that it only covers those taken in a limited time span. A lot of work was done before the first appearance of the issue list (and I recall no formal discussion of having an issue list, it seemed as if someone thought it a good idea and did it - sometimes it helped, other times it hindered). Also, in perhaps many places it is'wrong' in that what it says is not what is now in the RFC, just an interim state on the way to the consensus that did appear in the RFC. Again, I think this needs calling out more clearly. Tom Petch > Please post any comments by April 13, 2011. (However in light of the great length of the draft, we will extend the WGLC if anyone requests it.) > > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-issues-04.txt > > Thanks, > > --John From jgs@juniper.net Wed Mar 30 11:33: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 4A85D3A6A83 for ; Wed, 30 Mar 2011 11:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.967 X-Spam-Level: X-Spam-Status: No, score=-5.967 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_25=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 a5qgi-eK5PqB for ; Wed, 30 Mar 2011 11:33:48 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id C8E3C3A6A7D for ; Wed, 30 Mar 2011 11:33:47 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTZN37ayGbNfnqc7SP/PoIC07oWeQbFPY@postini.com; Wed, 30 Mar 2011 11:35:27 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 30 Mar 2011 11:32:28 -0700 From: John Scudder To: t.petch Date: Wed, 30 Mar 2011 11:33:58 -0700 Thread-Topic: [Idr] WGLC for draft-ietf-idr-bgp-issues Thread-Index: AcvvCNIBd5WxcQs3TTGEdrcWZfDFtA== Message-ID: <2D161C6C-7111-4B1B-9685-2B6A1FE93431@juniper.net> References: <01b701cbeef6$5159db80$4001a8c0@gateway.2wire.net> In-Reply-To: <01b701cbeef6$5159db80$4001a8c0@gateway.2wire.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 Cc: "idr@ietf.org" Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-issues 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, 30 Mar 2011 18:33:51 -0000 On Mar 30, 2011, at 6:19 PM, t.petch wrote: > As the I-D says, it tracks updates from Aug 2002 onwards by which time th= ere had > been many revisions and many issues raised and at least some resolved. I= t > should not claim to be a comprehensive record of decisions taken, rather = it > should make it clear, in the Abstract, that it only covers those taken in= a > limited time span. =20 That seems reasonable. > A lot of work was done before the first appearance of the > issue list (and I recall no formal discussion of having an issue list, it= seemed > as if someone thought it a good idea and did it - sometimes it helped, ot= her > times it hindered). Of course this was well before the beginning of my service as co-chair and = I don't recall the details. I found the list useful but YMMV. =20 > Also, in perhaps many places it is'wrong' in that what it says is not wha= t is > now in the RFC, just an interim state on the way to the consensus that di= d > appear in the RFC. Again, I think this needs calling out more clearly. That also seems reasonable (and much more reasonable than the probably-poin= tless task of trying to make the document comprehensive). If you have any specific edits to suggest, that would be helpful. By the way, do you agree that it's worth having this document around in som= e form for posterity? Thanks, --John= From jgs@juniper.net Wed Mar 30 12:03: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 4B0863A6873 for ; Wed, 30 Mar 2011 12:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.057, 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 kWnr1ftvgDHj for ; Wed, 30 Mar 2011 12:03:38 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 83D503A6AAB for ; Wed, 30 Mar 2011 12:03:37 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTZN+7G8zO2pL1TygIP3uJA3BkUdluf5c@postini.com; Wed, 30 Mar 2011 12:05:17 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; Wed, 30 Mar 2011 12:02:43 -0700 From: John Scudder To: "idr@ietf.org List" Date: Wed, 30 Mar 2011 12:04:13 -0700 Thread-Topic: WGLC for draft-ietf-idr-deprecate-as-sets Thread-Index: AcvvDQvRaS8HbXAzT8WlB6K0mq1joQ== 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-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: Wed, 30 Mar 2011 19:03:39 -0000 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= From danny@tcb.net Wed Mar 30 12:55: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 730F43A6BC1 for ; Wed, 30 Mar 2011 12:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 cPNxX8ugdXnk for ; Wed, 30 Mar 2011 12:55:31 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 9F77F3A6BBE for ; Wed, 30 Mar 2011 12:55:31 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id AF7BE2684EA; Wed, 30 Mar 2011 13:57:10 -0600 (MDT) Received: from dhcp-43bd.meeting.ietf.org (dhcp-43bd.meeting.ietf.org [130.129.67.189]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 30 Mar 2011 13:57:10 -0600 (MDT) (envelope-from danny@tcb.net) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Wed, 30 Mar 2011 15:57:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John Scudder , warren@kumari.net X-Mailer: Apple Mail (2.1082) 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.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 19:55:32 -0000 If you're looking for positive acks, I support publication of this = document. All minor nits and recommendations below. -danny --- S.1 s/multiple routes into a new route/multiple routes into a single new = route/ s/route. These can cause/route which can cause/ --- S.3 s/filtering routers that contain/filtering routes that contain/ Also, perhaps a more appropriate title for S.3 is "Recommendation=20 to Network Operators" --- S.3=20 REPLACE: "Operators are strongly advised to not generate any new = announcements containing AS_SETs or AS_CONFED_SETs and to withdraw any existing routes containing them as soon as possible." WITH: "Operators are strongly advised to not generate any new = announcements containing AS_SETs or AS_CONFED_SETs, and to remove any AS_SETS or=20 AS_CONFED_SETS from existing routes, should they exist." --- S.5 s/RPKI/Resource PKI (RPKI)/ and add reference? =20 Also, shouldn't all those references be Informative? 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 From jgs@juniper.net Wed Mar 30 13:42: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 D750228C1AA for ; Wed, 30 Mar 2011 13:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 lPzeJMuneSJZ for ; Wed, 30 Mar 2011 13:42:45 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id EFF6528C1AD for ; Wed, 30 Mar 2011 13:42:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTZOWJ6N23I8uwf1y2PsUQ/7Bgt2lIW38@postini.com; Wed, 30 Mar 2011 13:44:24 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; Wed, 30 Mar 2011 13:40:27 -0700 From: John Scudder To: "idr@ietf.org List" Date: Wed, 30 Mar 2011 13:41:56 -0700 Thread-Topic: Final agenda for IDR posted Thread-Index: AcvvGrMArXekkQgcQCKuhqFL4S8jfw== Message-ID: <70B86E19-034B-4EEB-8398-16FE11733F61@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: [Idr] Final agenda for IDR posted 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, 30 Mar 2011 20:42:47 -0000 FYI the final agenda (including links to slides) is at http://www.ietf.org/= proceedings/80/agenda/idr.html --John= From enkechen@cisco.com Wed Mar 30 16:22: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 207413A6ACD for ; Wed, 30 Mar 2011 16:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, 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 pvl0lNeX8xC3 for ; Wed, 30 Mar 2011 16:22:45 -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 DF20A3A69AE for ; Wed, 30 Mar 2011 16:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=5082; q=dns/txt; s=iport; t=1301527465; x=1302737065; h=message-id:date:from:mime-version:to:cc:subject; bh=hyu3GiQbp5C9a1eeyE3eEkhCNJUgOpF5vg83ROr3CtY=; b=dUVu6oLKZdNtJpdfPpNB3UdYM7BVbgmRBUtCsObaSmkaLfVdf+o+GPdx vIV9uLe7S7QUsKr+PCGBy08RvDTy6JQeq1m/4qYD8RkH3gFabMb0cBmf2 t4uNFf+18RMloomrH2NVTwtcLlCTf1JzePG2RRUNOm21cNiteku+hilBI M=; X-Files: Attached Message Part : 253 X-IronPort-AV: E=Sophos;i="4.63,270,1299456000"; d="txt'208?scan'208,208,217";a="673459272" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2011 23:24:25 +0000 Received: from dhcp-171-71-139-27.cisco.com (dhcp-171-71-139-27.cisco.com [171.71.139.27]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2UNOPk9015080; Wed, 30 Mar 2011 23:24:25 GMT Message-ID: <4D93BC71.4010708@cisco.com> Date: Wed, 30 Mar 2011 16:27:45 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Lightning/1.0b1 Thunderbird/3.0.11 MIME-Version: 1.0 To: "idr@ietf.org" Content-Type: multipart/mixed; boundary="------------060708060402090205070908" Subject: [Idr] Fwd: I-D Action:draft-keyur-bgp-enhanced-route-refresh-02.txt 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, 30 Mar 2011 23:22:47 -0000 This is a multi-part message in MIME format. --------------060708060402090205070908 Content-Type: multipart/alternative; boundary="------------030009080305000501090302" --------------030009080305000501090302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. -- Enke -------- Original Message -------- Subject: I-D Action:draft-keyur-bgp-enhanced-route-refresh-02.txt Date: Wed, 30 Mar 2011 16:00:02 -0700 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enhanced Route Refresh Capability for BGP-4 Author(s) : K. Patel, et al. Filename : draft-keyur-bgp-enhanced-route-refresh-02.txt Pages : 6 Date : 2011-03-30 In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate on-line, non-disruptive consistency validations of BGP routing updates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-keyur-bgp-enhanced-route-refresh-02.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. --------------030009080305000501090302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.    -- Enke

-------- Original Message --------
Subject: I-D Action:draft-keyur-bgp-enhanced-route-refresh-02.txt
Date: Wed, 30 Mar 2011 16:00:02 -0700
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Enhanced Route Refresh Capability for BGP-4
	Author(s)       : K. Patel, et al.
	Filename        : draft-keyur-bgp-enhanced-route-refresh-02.txt
	Pages           : 6
	Date            : 2011-03-30

In this document we enhance the existing BGP route refresh mechanisms
to provide for the demarcation of the beginning and the ending of a
route refresh.  The enhancement can be used to facilitate on-line,
non-disruptive consistency validations of BGP routing updates.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-keyur-bgp-enhanced-route-refresh-02.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.
--------------030009080305000501090302-- --------------060708060402090205070908 Content-Type: Message/External-body; name="draft-keyur-bgp-enhanced-route-refresh-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-keyur-bgp-enhanced-route-refresh-02.txt" Content-Type: text/plain Content-ID: <2011-03-30155855.I-D@ietf.org> --------------060708060402090205070908 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------060708060402090205070908-- From randy@psg.com Wed Mar 30 19:40: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 A845828C104 for ; Wed, 30 Mar 2011 19:40:23 -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 u2w1N1tz6l52 for ; Wed, 30 Mar 2011 19:40:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id F09B73A6BF1 for ; Wed, 30 Mar 2011 19:40:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-6391.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q57oU-000Aw8-G6; Thu, 31 Mar 2011 02:40:46 +0000 Date: Thu, 31 Mar 2011 04:40:45 +0200 Message-ID: From: Randy Bush To: John Scudder In-Reply-To: References: 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] 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: Thu, 31 Mar 2011 02:40:23 -0000 yes, please randy From jgs@juniper.net Thu Mar 31 00:26: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 8645328C23D for ; Thu, 31 Mar 2011 00:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 uyeW8upRA8m2 for ; Thu, 31 Mar 2011 00:26:23 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id BAA5E28C23E for ; Thu, 31 Mar 2011 00:26:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTZQtAt/kc492eVCGb9zXA67ZOxQB0QMT@postini.com; Thu, 31 Mar 2011 00:28:02 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; Thu, 31 Mar 2011 00:24:35 -0700 From: John Scudder To: "idr@ietf.org List" Date: Thu, 31 Mar 2011 00:26:06 -0700 Thread-Topic: [Idr] BGP Persistent Route Oscillation Solutions as WG item Thread-Index: AcvvdK9r26Ud/el4TH+SbR4jTTlVkg== Message-ID: <726E8DAC-A0ED-44A7-9D8D-0A55BA364B5B@juniper.net> References: <1D23749D4168CC4D8B8652397B5F643204E57756@XMB-RCD-206.cisco.com> In-Reply-To: <1D23749D4168CC4D8B8652397B5F643204E57756@XMB-RCD-206.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: "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, 31 Mar 2011 07:26:26 -0000 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. --John =20 On Mar 30, 2011, at 11:34 AM, Alvaro Retana (aretana) wrote: > 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 From curtis@occnc.com Thu Mar 31 00:32: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 E571128C25D for ; Thu, 31 Mar 2011 00:32:34 -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 iitafC8X7sNO for ; Thu, 31 Mar 2011 00:32:34 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id E47EC28C1FD for ; Thu, 31 Mar 2011 00:32:33 -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 p2V7YCbx046854; Thu, 31 Mar 2011 03:34:12 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103310734.p2V7YCbx046854@harbor.orleans.occnc.com> To: John Scudder From: Curtis Villamizar In-reply-to: Your message of "Wed, 30 Mar 2011 12:04:13 PDT." Date: Thu, 31 Mar 2011 03:34:12 -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.9 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, 31 Mar 2011 07:32:35 -0000 In message John Scudder writes: > > 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 This will also simplify the design, implementation and deployment of bonging work in the Secure Inter-Domain Routing Working Group. Bonging work? Yes sometimes it seems like SIDR has been passing the bong, but somehow I suspect the word "ongoing" was supposed to go here. As someone involved in possibly the only major user of AS_SET and a former strong advocate of AS_SET, I certainly don't have any evidence that that usage still remains. I have no objection to removing it at this point if no one has indicated using it. This leaves no mechanisms for route aggregation in BGP that preserves the BGP AS loop suppression and it might be worth mentioning this in the document. One sentence might be enough. Someone may want to solve that problem in the future, or maybe not, but it is worth one sentence to note that the problem exists. Curtis From jhaas@slice.pfrc.org Thu Mar 31 01: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 4FEA328C0DC for ; Thu, 31 Mar 2011 01:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.115 X-Spam-Level: X-Spam-Status: No, score=-102.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 6tVfR9luwla5 for ; Thu, 31 Mar 2011 01:52:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id D0FAD3A6B00 for ; Thu, 31 Mar 2011 01:52:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7B8EB224275; Thu, 31 Mar 2011 08:54:01 +0000 (UTC) Date: Thu, 31 Mar 2011 08:54:01 +0000 From: Jeffrey Haas To: Curtis Villamizar Message-ID: <20110331085401.GD20140@slice> References: <201103310734.p2V7YCbx046854@harbor.orleans.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103310734.p2V7YCbx046854@harbor.orleans.occnc.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:52:23 -0000 On Thu, Mar 31, 2011 at 03:34:12AM -0400, Curtis Villamizar wrote: > As someone involved in possibly the only major user of AS_SET and a > former strong advocate of AS_SET, I certainly don't have any evidence > that that usage still remains. I have no objection to removing it at > this point if no one has indicated using it. > > This leaves no mechanisms for route aggregation in BGP that preserves > the BGP AS loop suppression and it might be worth mentioning this in > the document. One sentence might be enough. As someone who had to try to divine why some things were in the protocol from it's functional behavior when I couldn't manage to get history from some of the involved parties, here's some observations: An AS_SET is less specific route being generated from a set of more specific routes and implies: - All contributing ASes do *not* get the aggregate (they're in the set after all) - And thus must all have all contributing routes themselves OR are reaching each other via the aggregator via default or similar. In order to reduce the information in the routing system, the more specific contributors would be suppressed. If we consider the case there may be different aggregating parties, we may have different aggregate routes with different set contents. This would permit the contributors to potentially get the aggregates. For this to be more useful than default or the contributors within the AS region being aggregated... I can't quite picture the use case. > Someone may want to solve that problem in the future, or maybe not, > but it is worth one sentence to note that the problem exists. The history of why the feature was useful might be in the archives but if so I didn't have the persistence to find it. When you find a moment, it might be helpful to talk about the the history of the feature for posterity. -- Jeff P.S. At the time I was becoming involved in BGP standards, the archives were somewhat divided between Merit and, I think ANS? From jakob.heitz@ericsson.com Thu Mar 31 02:32:31 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 A116C28C22B for ; Thu, 31 Mar 2011 02:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 YBN--Lv1kFTz for ; Thu, 31 Mar 2011 02:32:30 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 97B7A3A694C for ; Thu, 31 Mar 2011 02:32:10 -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 p2V9XnWm027023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 31 Mar 2011 04:33:49 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 31 Mar 2011 05:33:48 -0400 From: Jakob Heitz To: idr Date: Thu, 31 Mar 2011 05:33:50 -0400 Thread-Topic: draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label? Thread-Index: Acvvhr0U1syIigpuS7CjI50gYSsSkQ== Message-ID: <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: [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: Thu, 31 Mar 2011 09:32:31 -0000 After the link to the CE fails, the PE1 uses the repair label to send to PE= 2. If the link to the CE is never restored, does PE1 ever use the regular labe= l 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. -- Jakob Heitz. From curtis@occnc.com Thu Mar 31 02:54:05 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 331063A6949 for ; Thu, 31 Mar 2011 02:54:05 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whBEQ7vpQU6U for ; Thu, 31 Mar 2011 02:54:04 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 9E6133A680E for ; Thu, 31 Mar 2011 02:54: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 p2V9tgHK060368; Thu, 31 Mar 2011 05:55:42 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103310955.p2V9tgHK060368@harbor.orleans.occnc.com> To: Jeffrey Haas From: Curtis Villamizar In-reply-to: Your message of "Thu, 31 Mar 2011 08:54:01 -0000." <20110331085401.GD20140@slice> Date: Thu, 31 Mar 2011 05:55:42 -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.9 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, 31 Mar 2011 09:54:05 -0000 In message <20110331085401.GD20140@slice> Jeffrey Haas writes: > > On Thu, Mar 31, 2011 at 03:34:12AM -0400, Curtis Villamizar wrote: > > As someone involved in possibly the only major user of AS_SET and a > > former strong advocate of AS_SET, I certainly don't have any evidence > > that that usage still remains. I have no objection to removing it at > > this point if no one has indicated using it. > > > > This leaves no mechanisms for route aggregation in BGP that preserves > > the BGP AS loop suppression and it might be worth mentioning this in > > the document. One sentence might be enough. > > As someone who had to try to divine why some things were in the protocol > from it's functional behavior when I couldn't manage to get history from > some of the involved parties, here's some observations: > > An AS_SET is less specific route being generated from a set of more > specific routes and implies: > - All contributing ASes do *not* get the aggregate (they're in the set after > all) > - And thus must all have all contributing routes themselves OR > are reaching each other via the aggregator via default or similar. > > In order to reduce the information in the routing system, the more specific > contributors would be suppressed. > > If we consider the case there may be different aggregating parties, we may > have different aggregate routes with different set contents. This would > permit the contributors to potentially get the aggregates. For this to be > more useful than default or the contributors within the AS region being > aggregated... I can't quite picture the use case. > > > Someone may want to solve that problem in the future, or maybe not, > > but it is worth one sentence to note that the problem exists. > > The history of why the feature was useful might be in the archives but if > so I didn't have the persistence to find it. When you find a moment, it > might be helpful to talk about the the history of the feature for posterity. > > -- Jeff The issue was AS-X and AS-Y agree to aggregate a common set of prefixes. A classis example from the past was ANS and Internet-MCI aggregating different parts of CANET and saving a few thousand more specific prefixes. AS-X and AS-Y aggregate and pass the aggregates to each other, optionally also sending the more specifics, leaving out prefixes learned from the other in the aggregate. On the way out to any other party, AS-X puts both AS-X and AS-Y in the AS_SET along with all the AS that made up their AS_SET. And AS-Y does the same. In this example, ANS and Internet-MCI where protecting the aggregated prefix from partition in addition to aggregating to the outside world. CANET fractured into many smaller AS due to privatizing the national network among a number of entities that now had different AS numbers. That was probably the largest use of AS_SET although it was used widely at the time (~1995). The issue was that two AS were configured to aggregate the same prefix, though neither had connectivity to the whole thing. Getting the config right and the AS_SET made sure that neither advertised an aggregate based only on the aggregate learned from the other at another peering. The alternative was a few thousand prefixes that would have been bad for some of the routers taking global routes at the time. This provided a protocol based protection that you don't include someone else's aggregate of the same prefix as a result of a "drop all AS and reoriginate as your own" rule. A rule that allows only more specifics in an aggregate also fixes this. > P.S. At the time I was becoming involved in BGP standards, the archives were > somewhat divided between Merit and, I think ANS? I don't know that BGP discussion was ever archived at ANS, but it might have been archived at Merit. Curtis From ietfc@btconnect.com Thu Mar 31 03:37: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 ED67128C122 for ; Thu, 31 Mar 2011 03:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_25=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 UAkdRJeLfaJM for ; Thu, 31 Mar 2011 03:37:34 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by core3.amsl.com (Postfix) with ESMTP id 8F36728C113 for ; Thu, 31 Mar 2011 03:37:33 -0700 (PDT) Received: from host217-44-145-1.range217-44.btcentralplus.com (HELO pc6) ([217.44.145.1]) by c2bthomr07.btconnect.com with SMTP id CNF68639; Thu, 31 Mar 2011 11:39:10 +0100 (BST) Message-ID: <00a801cbef87$6a387760$4001a8c0@gateway.2wire.net> From: "t.petch" To: "John Scudder" References: <01b701cbeef6$5159db80$4001a8c0@gateway.2wire.net> <2D161C6C-7111-4B1B-9685-2B6A1FE93431@juniper.net> Date: Thu, 31 Mar 2011 11:38:05 +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.0A0B0303.4D9459CD.00F7, actions=TAG X-Junkmail-Premium-Raw: score=26/50, refid=2.7.2:2011.3.30.103320:17:26.894, ip=217.44.145.1, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, __URI_NS, SXL_IP_DYNAMIC[1.145.44.217.fur], BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=26/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4D9459CE.01CD,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: idr Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-issues 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, 31 Mar 2011 10:37:35 -0000 ---- Original Message ----- From: "John Scudder" To: "t.petch" Cc: Sent: Wednesday, March 30, 2011 8:33 PM On Mar 30, 2011, at 6:19 PM, t.petch wrote: > As the I-D says, it tracks updates from Aug 2002 onwards by which time there had > been many revisions and many issues raised and at least some resolved. It > should not claim to be a comprehensive record of decisions taken, rather it > should make it clear, in the Abstract, that it only covers those taken in a > limited time span. That seems reasonable. > A lot of work was done before the first appearance of the > issue list (and I recall no formal discussion of having an issue list, it seemed > as if someone thought it a good idea and did it - sometimes it helped, other > times it hindered). Of course this was well before the beginning of my service as co-chair and I don't recall the details. I found the list useful but YMMV. > Also, in perhaps many places it is'wrong' in that what it says is not what is > now in the RFC, just an interim state on the way to the consensus that did > appear in the RFC. Again, I think this needs calling out more clearly. That also seems reasonable (and much more reasonable than the probably-pointless task of trying to make the document comprehensive). If you have any specific edits to suggest, that would be helpful. By the way, do you agree that it's worth having this document around in some form for posterity? In principle, having a record of why and how a part of a specification was arrived at is good. I have seen plenty of requests on various lists for such an explanation, often answered by those who were around at the time. The devil is in the detail, in getting it comprehensive and in getting it accurate, which is why I flagged the need to make it clear that this will never be comprehensive. (Getting this far will have been a lot of work for Andrew and making it comprehensive would involve even more, going back over lengthy threads, and I do not think that that effort could be justified, even if there were an academic with post-grads looking for a project:-) As to getting it right, I did look at it when it first appeared, in 2005, and put it on the shelf for further study, where it has remained ever since. Probably I never will go through it all to see if it corresponds with my own notes, my own archives from 2002/2003 but I intend to dip into it some of the topics during this WGLC; as you know, it is big. Is it worth having around? Um, don't know. I rely on my own archives for that which I was involved with and so am unlikely to need it. Others? It would be interesting to hear the views of Susan and Benjamin. The problem I had at the time (and still have) is that issues are fuzzy things, hard to nail down, not at all object-oriented (I think that the IETF issue tracker has the same problem). In at least one case, probably several, I raised an issue, the issue evolved and my original point was lost and so I re-reraised it, creating a fresh issue (3.13.5). Tom Petch Thanks, --John= From gih@apnic.net Thu Mar 31 04:26: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 AFF4728C136 for ; Thu, 31 Mar 2011 04:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 lJKREeUKwjZk for ; Thu, 31 Mar 2011 04:26:18 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 8D0CB28C112 for ; Thu, 31 Mar 2011 04:26:18 -0700 (PDT) Received: from dhcp-1178.meeting.ietf.org (dhcp-1178.meeting.ietf.org [130.129.17.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 214E9B681F; Thu, 31 Mar 2011 21:27:55 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 31 Mar 2011 22:27:46 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <29F7E931-9062-448F-B8A3-1CC1DC5B2FA4@apnic.net> References: To: John Scudder X-Mailer: Apple Mail (2.1082) 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.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:26:19 -0000 On 31/03/2011, at 6:04 AM, 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 agreed - please ship it. Geoff From sds@dcs.gla.ac.uk Thu Mar 31 04:32:52 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 2B1543A6B0F for ; Thu, 31 Mar 2011 04:32:52 -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 g9EpINInzGZA for ; Thu, 31 Mar 2011 04:32:51 -0700 (PDT) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id 3DF253A6875 for ; Thu, 31 Mar 2011 04:32:51 -0700 (PDT) Received: from dhcp-16e4.meeting.ietf.org ([130.129.22.228]:41610) by mr1.dcs.gla.ac.uk with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.42) id 1Q5G8y-0006eQ-4Q; Thu, 31 Mar 2011 12:34:28 +0100 From: "Stephen D. Strowes" To: Randy Bush In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 31 Mar 2011 13:34:26 +0200 Message-ID: <1301571266.31409.5.camel@ikeq> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit 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.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:32:52 -0000 +1 -S. On Thu, 2011-03-31 at 03:40 +0100, Randy Bush wrote: > yes, please > > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From curtis@occnc.com Thu Mar 31 05:34: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 C3F803A6767 for ; Thu, 31 Mar 2011 05:34:56 -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 mVxb+3Wx7Bwx for ; Thu, 31 Mar 2011 05:34:56 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id CA0193A6B0E for ; Thu, 31 Mar 2011 05:34:55 -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 p2VCaW3H084347; Thu, 31 Mar 2011 08:36:32 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103311236.p2VCaW3H084347@harbor.orleans.occnc.com> To: "Stephen D. Strowes" From: Curtis Villamizar In-reply-to: Your message of "Thu, 31 Mar 2011 13:34:26 +0200." <1301571266.31409.5.camel@ikeq> Date: Thu, 31 Mar 2011 08:36:32 -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.9 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, 31 Mar 2011 12:34:56 -0000 I'm OK with shipping as is. Sorry to top post. Curtis In message <1301571266.31409.5.camel@ikeq> "Stephen D. Strowes" writes: +1 -S. On Thu, 2011-03-31 at 03:40 +0100, Randy Bush wrote: > yes, please > > randy > _______________________________________________ > 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 raszuk@cisco.com Thu Mar 31 06:30: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 D90CD3A6B0E for ; Thu, 31 Mar 2011 06:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 rtwQ4-gadkgW for ; Thu, 31 Mar 2011 06:30:29 -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 DC5873A6AB2 for ; Thu, 31 Mar 2011 06:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=268; q=dns/txt; s=iport; t=1301578329; x=1302787929; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=yyo/KnQQAkYzyaBVSMYYhyH0Ye96QiM/oZni/28ODJw=; b=A/6cIh89r+4cv6jdBShL4hE66VpjjhfHhbIo+qJ3JboaLIMTtIOmLbW6 l5brN02YGOipOEMq7vdEFnc8dj3QgDLhMi+Dd0jfayz/l5Pz08PPerp3g ZfyFpb95nwCij+gYQWkEnaez+GhXSHNzVfTjHsUVm9bTb6dOGJA9BkuP7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK+BlE2rRDoH/2dsb2JhbAClTHejBYJwDgGZE4VrBI0Rg1U X-IronPort-AV: E=Sophos;i="4.63,275,1299456000"; d="scan'208";a="328184347" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 31 Mar 2011 13:31:40 +0000 Received: from [10.21.106.8] (sjc-vpnasa-517.cisco.com [10.21.106.8]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2VDVdF0015205 for ; Thu, 31 Mar 2011 13:31:40 GMT Message-ID: <4D94823E.9070806@cisco.com> Date: Thu, 31 Mar 2011 15:31: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: "idr@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] Dissemination of Flow Specification Rules for IPv6 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, 31 Mar 2011 13:30:30 -0000 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 Thu Mar 31 06:32:52 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 4EF7E28C139 for ; Thu, 31 Mar 2011 06:32:52 -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 lft+26PwdxRP for ; Thu, 31 Mar 2011 06:32:51 -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 890D63A6B0E for ; Thu, 31 Mar 2011 06:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=273; q=dns/txt; s=iport; t=1301578471; x=1302788071; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=F1PIoX+Sa8i6gyCcebEdcGXIn+htweb4A+rkzi0Gops=; b=b9V9Thrcy58BqOZdEQO+lVCyE2sVEh1G5kEujGN0qZRnFodnTfZwoPL/ 91E2Qwb+0wHcWzo+o31b3nUts7nG2Qi8F3haJ9mFAhrUoe1CPAKxLE3cz n7q5rm0vexCSsX3E3Ce+V+wPLynvMVBTs/HpgbZV4lc+gfkoKGwbnOrXl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPqBlE2rRDoG/2dsb2JhbAClTHejCIJwDgGZE4VrBI0Rg1U X-IronPort-AV: E=Sophos;i="4.63,275,1299456000"; d="scan'208";a="421621557" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 31 Mar 2011 13:34:31 +0000 Received: from [10.21.106.8] (sjc-vpnasa-517.cisco.com [10.21.106.8]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2VDYSn0009186 for ; Thu, 31 Mar 2011 13:34:30 GMT Message-ID: <4D9482E7.5010905@cisco.com> Date: Thu, 31 Mar 2011 15:34:31 +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] 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, 31 Mar 2011 13:32:52 -0000 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 jeff.tantsura@ericsson.com Thu Mar 31 06:33: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 A801328C13A for ; Thu, 31 Mar 2011 06:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.472 X-Spam-Level: X-Spam-Status: No, score=-5.472 tagged_above=-999 required=5 tests=[AWL=1.127, 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 GBSiMPaVAclI for ; Thu, 31 Mar 2011 06:33:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id C55BD3A6B0E for ; Thu, 31 Mar 2011 06:33:46 -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 p2VDZOSa000727; Thu, 31 Mar 2011 08:35:25 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 31 Mar 2011 09:35:18 -0400 From: Jeff Tantsura To: "raszuk@cisco.com" Date: Thu, 31 Mar 2011 09:35:14 -0400 Thread-Topic: [Idr] Dissemination of Flow Specification Rules for IPv6 Thread-Index: AcvvqHnP0t/bG1pQScWWX4m4dRSG7Q== Message-ID: <1C015943-E564-4E39-B30F-D4060EB40D9E@ericsson.com> References: <4D94823E.9070806@cisco.com> In-Reply-To: <4D94823E.9070806@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] 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: Thu, 31 Mar 2011 13:33:47 -0000 +1 Regards, Jeff On Mar 31, 2011, at 15:32, "Robert Raszuk" wrote: >=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 it= em. >=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 From jhaas@slice.pfrc.org Thu Mar 31 07:17: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 47BAA3A6B13 for ; Thu, 31 Mar 2011 07:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 6LHde9L2SWOL for ; Thu, 31 Mar 2011 07:17:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 6D2D83A6AD7 for ; Thu, 31 Mar 2011 07:17:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 07B86224235; Thu, 31 Mar 2011 14:19:02 +0000 (UTC) Date: Thu, 31 Mar 2011 14:19:02 +0000 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20110331141901.GA27491@slice> References: <4D94823E.9070806@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D94823E.9070806@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "idr@ietf.org List" 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: Thu, 31 Mar 2011 14:17:23 -0000 On Thu, Mar 31, 2011 at 03:31:42PM +0200, Robert Raszuk wrote: > 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. I support adoption of this draft as a working group work item. -- Jeff From ilya@nobulus.com Thu Mar 31 07:44: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 BA13E3A6B33 for ; Thu, 31 Mar 2011 07:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=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 ptbo4AQkrdAN for ; Thu, 31 Mar 2011 07:44:47 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id C92F43A6B10 for ; Thu, 31 Mar 2011 07:44:46 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id C8D0617159 for ; Thu, 31 Mar 2011 16:46: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 ZqQ-itZwUGlF for ; Thu, 31 Mar 2011 16:46:23 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:df8:0:16:3419:669:c0c4:faa1]) by nobulus.com (Postfix) with ESMTPA id F27D117177 for ; Thu, 31 Mar 2011 16:46:20 +0200 (CEST) Message-ID: From: "iLya" To: Date: Thu, 31 Mar 2011 16:46:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original 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 Subject: [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: Thu, 31 Mar 2011 14:44:47 -0000 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 From wim.henderickx@alcatel-lucent.com Thu Mar 31 08:25: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 BCF3628C102 for ; Thu, 31 Mar 2011 08:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.545 X-Spam-Level: X-Spam-Status: No, score=-5.545 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, HELO_EQ_FR=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 JinrrDAvlwwB for ; Thu, 31 Mar 2011 08:25:58 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id AA03728C0EF for ; Thu, 31 Mar 2011 08:25:57 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2VFIv6Q004806 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Mar 2011 17:27:32 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 31 Mar 2011 17:27:14 +0200 From: "Henderickx, Wim (Wim)" To: "raszuk@cisco.com" , "idr@ietf.org List" Date: Thu, 31 Mar 2011 17:27:12 +0200 Thread-Topic: [Idr] Dissemination of Flow Specification Rules for IPv6 Thread-Index: AcvvqBJZgLnVit3QR0Kk3BI+oiePOgAEAc5A Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67182EA143@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <4D94823E.9070806@cisco.com> In-Reply-To: <4D94823E.9070806@cisco.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 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: Thu, 31 Mar 2011 15:25:58 -0000 support -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: donderdag 31 maart 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 jie.dong@huawei.com Thu Mar 31 08:52: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 3429A3A6B32 for ; Thu, 31 Mar 2011 08:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 N7sVdTfPtQ8q for ; Thu, 31 Mar 2011 08:52:39 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3F4E23A684E for ; Thu, 31 Mar 2011 08:52:39 -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 <0LIX00095IU8IP@szxga03-in.huawei.com> for idr@ietf.org; Thu, 31 Mar 2011 23:54:08 +0800 (CST) Received: from szxeml204-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 <0LIX000W2IU85J@szxga03-in.huawei.com> for idr@ietf.org; Thu, 31 Mar 2011 23:54:08 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml204-edg.china.huawei.com (172.24.2.56) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 31 Mar 2011 23:54:01 +0800 Received: from SZXEML508-MBX.china.huawei.com ([169.254.6.115]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Thu, 31 Mar 2011 23:54:07 +0800 Date: Thu, 31 Mar 2011 15:54:07 +0000 From: Jie Dong X-Originating-IP: [172.24.2.40] To: "idr@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C927AD400A@szxeml508-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: WG adoption of "IPv6 AF Extensions for Route Target Distribution" Thread-index: AQHL77veohlgKlPj5Eu+rRghEYxDvQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [Idr] WG adoption of "IPv6 AF Extensions for Route Target Distribution" 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, 31 Mar 2011 15:52:40 -0000 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 From bashandy@cisco.com Thu Mar 31 09:15: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 A90A83A6C0F for ; Thu, 31 Mar 2011 09:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 LqnjTSOhd+B7 for ; Thu, 31 Mar 2011 09:15:36 -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 2FB9F3A684E for ; Thu, 31 Mar 2011 09:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=1242; q=dns/txt; s=iport; t=1301588233; x=1302797833; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=uKP7fogkXVtsA+uWpFxU4pOTXg60y0xHE359KuFNsQk=; b=JLAhuRxGVF7TQyNelegynEDaEUN4aK8pgx7S9FY2wo5vle/Xy04zcYM7 QMyiASBmhKFiC6Fbglgzi3PxX/Rjkn3lCm03U2nKVlAn9UtiFabbvXDj4 bpBcZNF7f9MhqaHnrgouYNXwWoVKJ8V7sjwaCE4jJqCpvTaEEnq6JpjbB M=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.63,276,1299456000"; d="asc'?scan'208";a="328297880" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 31 Mar 2011 16:17:13 +0000 Received: from [10.21.87.67] ([10.21.87.67]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2VGHBq9019378; Thu, 31 Mar 2011 16:17:12 GMT Message-ID: <4D94A903.7020604@cisco.com> Date: Thu, 31 Mar 2011 18:17:07 +0200 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: raszuk@cisco.com References: <4D94823E.9070806@cisco.com> In-Reply-To: <4D94823E.9070806@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3820A06380699F1C785C74D2" Cc: "idr@ietf.org List" Subject: Re: [Idr] Dissemination of Flow Specification Rules for IPv6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bashandy@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:15:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3820A06380699F1C785C74D2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it should be adopted Thanks Ahmed On 3/31/2011 3:31 PM, Robert Raszuk wrote: > > Authors of "Dissemination of Flow Specification Rules for IPv6" draft d= ocument would like to propose the adoption of this work as the IDR WG ite= m. > > 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 --------------enig3820A06380699F1C785C74D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFNlKkI+G19kFA5zIYRAt0kAJ9RO37/xdQLLDQaWby/021ycvIBswCfWE+g mqDhJvbvvpuaMAJt5qmV7zE= =Kwmx -----END PGP SIGNATURE----- --------------enig3820A06380699F1C785C74D2-- From ilya@nobulus.com Thu Mar 31 09:26: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 967423A684E for ; Thu, 31 Mar 2011 09:26: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.001, 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 k46js5g6E0dp for ; Thu, 31 Mar 2011 09:26:44 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 5FC243A6844 for ; Thu, 31 Mar 2011 09:26:44 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 89AFB17177 for ; Thu, 31 Mar 2011 18:28: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 UJjurc-OxDE6 for ; Thu, 31 Mar 2011 18:28:21 +0200 (CEST) Received: from hnivarlas1 (unknown [IPv6:2001:df8:0:16:3419:669:c0c4:faa1]) by nobulus.com (Postfix) with ESMTPA id 040B6170D5 for ; Thu, 31 Mar 2011 18:28:20 +0200 (CEST) Message-ID: <47700E9AB13447D4A449E7B1ED746EC1@hnivarlas1> From: "iLya" To: References: <4D94823E.9070806@cisco.com> In-Reply-To: <4D94823E.9070806@cisco.com> Date: Thu, 31 Mar 2011 18:28:20 +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 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: Thu, 31 Mar 2011 16:26:45 -0000 support /iLya -------------------------------------------------- From: "Robert Raszuk" Sent: Thursday, March 31, 2011 3:31 PM To: Subject: [Idr] Dissemination of Flow Specification Rules for IPv6 > > 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 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From tom@someaddress.net Thu Mar 31 09:48:52 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 A4CF53A6A63 for ; Thu, 31 Mar 2011 09:48: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARHiBS9aqxLq for ; Thu, 31 Mar 2011 09:48:51 -0700 (PDT) Received: from zinc.someaddress.net (zinc.someaddress.net [82.152.104.99]) by core3.amsl.com (Postfix) with ESMTP id 53EEC3A684E for ; Thu, 31 Mar 2011 09:48:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zinc.someaddress.net (Postfix) with ESMTPS id 3CE383C001025 for ; Thu, 31 Mar 2011 17:49:59 +0100 (BST) Date: Thu, 31 Mar 2011 17:49:59 +0100 (BST) From: Tom Hodgson X-X-Sender: tom@zinc To: "idr@ietf.org List" In-Reply-To: <4D94823E.9070806@cisco.com> Message-ID: References: <4D94823E.9070806@cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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: Thu, 31 Mar 2011 16:48:52 -0000 On Thu, 31 Mar 2011, Robert Raszuk wrote: > 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 > +1 support this proposal. -- Tom Hodgson tom@someaddress.net From hritter@cisco.com Thu Mar 31 10:12: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 EC3123A6A63 for ; Thu, 31 Mar 2011 10:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bATV5bphD7DT for ; Thu, 31 Mar 2011 10:12:38 -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 E79C43A69C1 for ; Thu, 31 Mar 2011 10:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hritter@cisco.com; l=5917; q=dns/txt; s=iport; t=1301591658; x=1302801258; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=tpkeGynzTAl2fQ8t8+HIPjnl9rSqhMWK5cozSSet0w0=; b=gyWeUCIP+CcrrqqZ1kekKtP7w3YmBEZ6uQ4/Q6Lx3tdbSMBbcPE1T/5c M6OxiNMxoo5WHMqHlPc1hpSgL4Ey+kpKQiJPWgUJuw2cQCuhvgC6TT+RP GVKL97hF6XlQNT3749rT0WjWn4eQmjtQM4RQr8VrNp1qSZe+KJ+aCmnMY E=; X-IronPort-AV: E=Sophos;i="4.63,276,1299456000"; d="scan'208,217";a="286698179" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2011 17:14:17 +0000 Received: from [10.86.252.33] ([10.86.252.33]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2VHEGW4023976; Thu, 31 Mar 2011 17:14:17 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-31--985574263 From: Harold Ritter In-Reply-To: <4D94823E.9070806@cisco.com> Date: Thu, 31 Mar 2011 13:14:16 -0400 Message-Id: <432ECD69-11B3-40FA-88E1-244644FFAACF@cisco.com> References: <4D94823E.9070806@cisco.com> To: raszuk@cisco.com X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" 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: Thu, 31 Mar 2011 17:12:39 -0000 --Apple-Mail-31--985574263 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I support this proposal. Le 2011-03-31 =E0 09:31, Robert Raszuk a =E9crit : >=20 > 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. >=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 Harold Ritter Directeur Technique/Technical Leader Advanced Services Central Engineering CCIE 4168 (R&S, SP) harold@cisco.com T=E9l=E9phone: 514 847 6856 Les Syst=E8mes Cisco=20 1800 McGill College Suite 700 Montr=E9al, Qu=E9bec H3A 3J6 Canada =20 =20 --Apple-Mail-31--985574263 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = support this proposal.

Le 2011-03-31 =E0 09:31, Robert = Raszuk a =E9crit :


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
_______________________________________________
Idr = mailing = list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


Harold = Ritter
Directeur Technique/Technical = Leader
Advanced Services Central = Engineering
CCIE 4168 (R&S, = SP)

 514 847 = 6856

Les Syst=E8mes = Cisco 
1800 McGill = College
Suite 700
Montr=E9al, Qu=E9bec = H3A 3J6
Canada

 

=


 


= --Apple-Mail-31--985574263-- From danny@tcb.net Thu Mar 31 14:00:01 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 623FD3A6BB0 for ; Thu, 31 Mar 2011 14:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.285 X-Spam-Level: X-Spam-Status: No, score=-110.285 tagged_above=-999 required=5 tests=[AWL=0.314, 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 UP+PRO6ycGaH for ; Thu, 31 Mar 2011 14:00:00 -0700 (PDT) Received: from farnsworth.verisignlabs.com (farnsworth.verisignlabs.com [72.13.58.64]) by core3.amsl.com (Postfix) with ESMTP id 8A85C3A69AB for ; Thu, 31 Mar 2011 14:00:00 -0700 (PDT) Received: from monsoon.verisignlabs.com (h87.s239.verisign.com [216.168.239.87]) by farnsworth.verisignlabs.com (Postfix) with ESMTP id BEED890B2; Thu, 31 Mar 2011 21:01:33 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (dul1dmcphers-m2.vcorp.ad.vrsn.com [10.100.0.40]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 6751824247D; Thu, 31 Mar 2011 17:01:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <4D94823E.9070806@cisco.com> Date: Thu, 31 Mar 2011 17:01:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D94823E.9070806@cisco.com> To: raszuk@cisco.com X-Mailer: Apple Mail (2.1082) Cc: "idr@ietf.org List" 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: Thu, 31 Mar 2011 21:00:01 -0000 Not surprisingly, I support, and would also note that this=20 was an expressly requested action item during IESG review at=20 the time the base BGP Flow Specification draft was published. -danny On Mar 31, 2011, at 9:31 AM, Robert Raszuk wrote: >=20 > 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. >=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