From idr-bounces@ietf.org Mon Jul 02 17:30:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5TSt-0005sk-K7; Mon, 02 Jul 2007 17:29:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5TSr-0005s1-KK; Mon, 02 Jul 2007 17:29:46 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5TRz-0004JU-J6; Mon, 02 Jul 2007 17:29:45 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 788F2328F4; Mon, 2 Jul 2007 21:28:51 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5TRz-0003B7-CV; Mon, 02 Jul 2007 17:28:51 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 02 Jul 2007 17:28:51 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: idr mailing list , idr chair , Internet Architecture Board , RFC Editor Subject: [Idr] Protocol Action: 'Avoid BGP Best Path Transitions from One External to Another' to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org The IESG has approved the following document: - 'Avoid BGP Best Path Transitions from One External to Another ' as a Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Dave Ward and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-avoid-transition-05.txt Technical Summary This document describes a revision to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed revision would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external paths from one BGP speaker contribute to the churn. Working Group Summary The WG had consensus to advance this document. Protocol Quality Bill Fenner reviewed this document for the IESG. The implementation report is available at http://www.ietf.org/IESG/Implementations/implem_EBGP.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 09 08:23:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7sGr-0000WY-2P; Mon, 09 Jul 2007 08:23:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7sGa-000856-I8 for idr@ietf.org; Mon, 09 Jul 2007 08:23:00 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7sGX-0005fy-Rh for idr@ietf.org; Mon, 09 Jul 2007 08:23:00 -0400 Received: from dhcp-239-0.jakma.org (dhcp-239-0.jakma.org [192.168.0.239]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l69CMK9f012576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2007 13:22:24 +0100 Date: Mon, 9 Jul 2007 13:22:20 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Robert Raszuk Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-Reply-To: <467CFD97.2050706@juniper.net> Message-ID: References: <467799C6.3020302@firstpr.com.au><4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <467CD2D4.20700@firstpr.com.au> <467CFD97.2050706@juniper.net> 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 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.1.12 (hibernia.jakma.org [212.17.55.49]); Mon, 09 Jul 2007 13:22:27 +0100 (IST) X-Spam-Score: -2.8 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Tony Li , idr , "K. Sriram" , Noel Chiappa X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, On Sat, 23 Jun 2007, Robert Raszuk wrote: > technology. Geoff's data that most churn is generated by roughly > 10% of bad netizens of the Internet and recent proposals from > tli/geoff have IMHO very good potential to vastly reduce churn > leaving more BGP dedicated CPUs for actual BGP update/best-path > processing. These efforts are extremely interesting and admirable, the observations in that document are particularly insightful. However, let's be mindful that the proposals in the RFC are mostly 'fine-tuning' of BGP to accomodate current conditions. As the RFC notes, the suggestions are heuristics - and heuristics tend only to go so far. > problems from flat BGP to a new mapping plane ? And if this mapping > plane is free from such issues, why current BGP control plane could > not be ? After all only scalable & realistic deployment model is to > use those same CPUs and the same routers for all the work. A hierarchy can alleviate scaling problems by reducing the amount of global state that must be kept - i.e. localising details. Hierarchies are not without their own cost, obviously (the hierarchy may require administration; the reduction of global state will reduce flexibility). > * From my point of view the biggest gain one could envision while > introducing some form of mapping abstraction between EID & locators > are not those which are listed in the IAB report. Agreed. One of the most obvious areas for information-reduction through hierarchy would be to note that we have two distinct number-spaces, the connectedness of one being a subset of the other, yet we propogate routing information for the /aggregate/ of the two spaces. I.e. we can observe that: - ASes form a topology (Information about ASes in BGP today can only be used reliably for loop-detection, but the statement is true, and even today there's enough information in BGP to work out the AS topology; witness that there are tools available that do so) - AS topology is a strict subset of IP topology (I.e. if you know the AS topology, and you know the IP:AS mappings, you must know enough to do inter-AS IP routing) So in theory we could propogate messages to describe former seperately from the latter, describing AS routing via traditional Distance-Vector, and describing the IP:AS mappings in some other way (e.g. by flooding). That would gain some efficiency in IDR messaging, retaining the policy-amienable DV routing we know from BGP, at the cost of IDR "traffic engineering" no longer being able to act directly on IP topology, but only on AS topology. Sadly there's no such thing as a free lunch. ;) If careful fine-tuning of BGP doesn't work (as per Li and Hustons' draft), then we'll have to start looking at more radical things (like the above, or not ;) ) - which implies having to make some difficult choices on trade-offs between flexibility and information.. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Nothing shortens a journey so pleasantly as an account of misfortunes at which the hearer is permitted to laugh. -- Quentin Crisp _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 09 09:28:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7tI6-00051I-2x; Mon, 09 Jul 2007 09:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7tHz-0004a4-FC for idr@ietf.org; Mon, 09 Jul 2007 09:28:31 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7tHv-0007Ww-54 for idr@ietf.org; Mon, 09 Jul 2007 09:28:31 -0400 Received: from yxu1b30.hopcount.ca ([199.212.90.30]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I7tKF-000J7Y-LB; Mon, 09 Jul 2007 13:30:51 +0000 In-Reply-To: References: <467799C6.3020302@firstpr.com.au><4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <467CD2D4.20700@firstpr.com.au> <467CFD97.2050706@juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <363B9546-0285-473B-B196-795B7437A8B9@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping Date: Mon, 9 Jul 2007 09:28:03 -0400 To: Paul Jakma X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Tony Li , Noel Chiappa , "K. Sriram" , idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On 9-Jul-2007, at 08:22, Paul Jakma wrote: > - ASes form a topology > > (Information about ASes in BGP today can only be used reliably for > loop-detection, but the statement is true, and even today there's > enough information in BGP to work out the AS topology; witness > that there are tools available that do so) > > - AS topology is a strict subset of IP topology > > (I.e. if you know the AS topology, and you know the IP:AS mappings, > you must know enough to do inter-AS IP routing) It ought also to be mentioned that there's an additional mapping between prefix propagation and particular edges between ASes (i.e. not every connection between the same pair of ASes involves the same exchange of reachability information; ISPs advertise the same prefixes with different attributes across different links, or different sets of prefixes.) Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 09 09:57:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7tjU-00052P-Bq; Mon, 09 Jul 2007 09:56:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7tjT-00052C-8H for idr@ietf.org; Mon, 09 Jul 2007 09:56:55 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7tjD-00085H-Mi for idr@ietf.org; Mon, 09 Jul 2007 09:56:55 -0400 Received: from dhcp-239-0.jakma.org (dhcp-239-0.jakma.org [192.168.0.239]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l69Du9wY013793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2007 14:56:13 +0100 Date: Mon, 9 Jul 2007 14:56:09 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Joe Abley Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-Reply-To: <363B9546-0285-473B-B196-795B7437A8B9@ca.afilias.info> Message-ID: References: <467799C6.3020302@firstpr.com.au><4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <467CD2D4.20700@firstpr.com.au> <467CFD97.2050706@juniper.net> <363B9546-0285-473B-B196-795B7437A8B9@ca.afilias.info> 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 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.1.12 (hibernia.jakma.org [192.168.0.3]); Mon, 09 Jul 2007 14:56:13 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Tony Li , Noel Chiappa , "K. Sriram" , idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Mon, 9 Jul 2007, Joe Abley wrote: > It ought also to be mentioned that there's an additional mapping > between prefix propagation and particular edges between ASes (i.e. > not every connection between the same pair of ASes involves the > same exchange of reachability information; ISPs advertise the same > prefixes with different attributes across different links, or > different sets of prefixes.) Aye. A lot of that detail would be lost in an AS-topology routed scheme; the disadvantage would be loss of IP-topology-scale traffic engineering. I'm not saying such a scheme would be the one to go for; I'm saying we may (or may not ;) ) one day have to face having to decide on trade-offs of "detail" Vs "scaleability", like the one in that scheme. ;) regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: You can have peace. Or you can have freedom. Don't ever count on having both at once. -- Lazarus Long _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 09 10:50:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7uZJ-00039z-EB; Mon, 09 Jul 2007 10:50:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7uZG-0002om-CV for idr@ietf.org; Mon, 09 Jul 2007 10:50:26 -0400 Received: from out001.apptix.savvis.net ([216.91.32.44] helo=out001a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7uZC-0001PW-3z for idr@ietf.org; Mon, 09 Jul 2007 10:50:26 -0400 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out001a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 09:50:22 -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 Subject: RE: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping Date: Mon, 9 Jul 2007 09:50:19 -0500 Message-ID: <2DC6358FAE5D5F44A12DC5ABFDA8AC4D013B60BF@s228130hz1ew24.apptix-01.savvis.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping Thread-Index: AcfCMQi2s72Kpo3xS0S+Lj4y7DoseQAAt5Ig From: "Schliesser, Benson" To: "Paul Jakma" , "Joe Abley" X-OriginalArrivalTime: 09 Jul 2007 14:50:22.0009 (UTC) FILETIME=[79C26A90:01C7C238] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Tony Li , idr , Noel Chiappa , "K. Sriram" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org (Sorry; I have 3 topics in 1 email. Please feel free to split the thread if appropriate.) Paul Jakma [mailto:paul@clubi.ie] wrote: > Aye. A lot of that detail would be lost in an AS-topology routed=20 > scheme; the disadvantage would be loss of IP-topology-scale traffic=20 > engineering. >=20 > I'm not saying such a scheme would be the one to go for; I'm saying=20 > we may (or may not ;) ) one day have to face having to decide on=20 > trade-offs of "detail" Vs "scaleability", like the one in that=20 > scheme. ;) I agree that we need more discussion on detail vs scale. I have a gut feeling that they are naturally opposing features of a routing system. Maybe somebody more expert than me (and more mathematically inclined) can comment on this? Now pragmatically: On average, for TE purposes, the normal Internet AS needs something less granular than per-prefix attributes but more granular than per-AS. Thus I would imagine that in an AS-topology routed scheme each network operator would end up with multiple AS numbers, where each was used as a TE equivalence-class identifier. This makes "AS" a bit of a misnomer in such a system. :) In the Internet today, "traffic engineering" is already quite imprecise. For the most part, the tools available are side-effects ("hacks"?) of explicit features. If we were to build TE as an explicit feature of the routing system, what would that look like? For that matter, what TE capabilities are required? I have my own list (below), but some discussion around this would be valuable, I think. Inter-AS/Global TE Features I'd like (non-exhaustive): -control traffic proportions/balance across my available inter-network links -control whether and where I use multi-path for a given class of traffic -direct certain classes of traffic to specific links What other TE requirements are out there? (I know there are some, just not at the tip of my fingers now.) Cheers, -Benson _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 12 02:34:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sFb-0007mU-Gw; Thu, 12 Jul 2007 02:34:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sFZ-0007ex-Vy for idr@ietf.org; Thu, 12 Jul 2007 02:34:06 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8sFY-00007o-FO for idr@ietf.org; Thu, 12 Jul 2007 02:34:05 -0400 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 <0JL100JZIZJ2LE@szxga03-in.huawei.com> for idr@ietf.org; Thu, 12 Jul 2007 14:33:02 +0800 (CST) Received: from m50376k ([10.111.12.130]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL100BL4ZIZS6@szxga03-in.huawei.com> for idr@ietf.org; Thu, 12 Jul 2007 14:33:02 +0800 (CST) Date: Thu, 12 Jul 2007 14:32:58 +0800 From: Michael Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping To: Tony Li Message-id: <00ac01c7c44e$7d4f4a30$820c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <4B079921-73F4-4909-8CAC-83E85E58F90C@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Tony, How to distinguish route changes due to a real topology change or a path hunting? as I understand, a real topology change is one of the reasons triggering a path hunting, other reasons include the reconfiguration of route policies or management and maintenance etc. And with respect to a very far AS, a BGP peer inside it can not tell what real reason causes it change. Best, Michael ----- Original Message ----- From: "Tony Li" To: "Robin Whittle" Cc: "idr" ; "K. Sriram" Sent: Saturday, June 23, 2007 5:01 AM Subject: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping > > Hi Robin, > > >> Your I-D also states that "path hunting" occurs when a prefix is >> first advertised, but that seems pretty natural and hard to >> prevent. > > > Please read the rest of the draft. ;-) > > >> I don't think this would be as destructive as the MRAI >> timer holding back a withdrawal for 30 seconds just after an AA+ >> has been sent. > > > MRAI is simply one other cause of diffraction, resulting in path > hunting and more unnecessary messaging. > > >> "Path hunting" after a first advertisement is a consequence of >> the path-vector protocol. Maybe your proposed Path Length >> Damping would be marginally effective at reducing the >> propagation of sub-optimal "best paths" sometimes before the >> final, stable, optimal "best path", by expediting the >> announcements of shorter paths and withdrawals, and delaying >> longer path announcements. > > > Please read the rest of the draft. ;-) In particular the sections > on optimal path damping and delayed best path selection. > > >> So more than 2/3 of activity is seems clearly to be associated >> with delays caused by the MRAI timer in a small triangle of >> routers/ASes, or in more complex mesh structures. > > > Your assumption here seems to be that all delays are due to MRAI. > That seems highly unlikely. MRAI just gives larger delays. There > are others that are of influence as well. > > >> Getting rid >> of that mechanism would greatly reduce the burden of messages >> and speed up the propagation of withdrawals. Sequences of >> multiple messages might be replaced by a single message, which >> is more informative, and propagates quickly. > > > Exactly why some implementations have taken that path. > > >>>> I also believe that it is a major mistake to treat >>>> advertisements differently than withrawns, specially from a >>>> queuing/timing point of view. The only thing you are going to >>>> get out of that is weird blackholes and more instability... >> >> This is written by someone who presumably knows far more about >> BGP than I do, but I don't see why this would be true. > > > Yes, Pedro knows a good bit about BGP. I put high value on his opinion. > > To understand his perspective, I think you also need to consider > cases where there are link failures within a more meshed topology. > Rapid propagation of withdrawals (bad news) and slow propagation of > alternate paths (good news) means that convergence to alternate paths > will go through unnecessary churn. For example, the withdrawal might > rapidly propagate up past the point where the alternate path would > come into play and result in a blackhole while the alternate path > information slowly catches up. As these are the cases where you > really would like to converge quickly, this is problematic. > > >>>> AFAIK, no major vendor implements their advertisement >>>> rate-controller/queueing in a way as to threat updates and >>>> withrawns differently. >> >> Lets say we have 500,000 prefixes. Do we have a single down >> counter for each prefix? I guess so. As far as I know, the >> same announcements go to all peers. > > > This is fundamentally incorrect. Policy is peer specific. > > >> This is a major challenge to implement. It is either a massive >> number of downcounters each with its own pointers to whatever it >> affects, or some kind of linked list of events to remember in >> the future, which could get very long, and would require tricky >> methods to take things out of and to incrementally chew through >> and take action upon as time passes by. >> >> There would never be 500,000 timers active at once, so maybe it >> could be implemented by having a pool of downcounters, say a few >> thousand, which are used by the first instances which need them >> and which are returned to the pool once they time out or no >> longer needed. > > > It's not particularly hard to set up a router that has multiple > copies of the full routing table, prefers only one of them, and then > has all of the preferred routes withdrawn. So, yes, you need to > provision for all 500,000 timers. This assumes you're willing to > bound your implementation to that number. FWIW, that number is no > longer competitive and would need to be more like 1-2M. Certain > folks seem to already be claiming 10M. > > >> Then there is the question of each router's message queue to >> each peer being throttled via TCP, with the software being able >> to find messages in the queue and delete them if something else >> happens after they were put in the queue. > > > Removing messages after they are placed into the TCP stream is not a > practical approach. Once the message has been played out of BGP and > into the TCP socket, it is quite effectively "gone". The best that a > BGP implementation can do is to ensure that it has filled the socket > and not computed too many additional messages. Such messages would > have to be explicitly buffered in BGP, which is expensive. It's far > more effective to simply not compute updates faster than they are > consumed and leave the data in BGP's internal data structures. > > >> Yet by 2002, we are told that Cisco, Juniper et. al. had given >> up on following RFC 1771's strict instructions to exempt >> withdrawals from the MRAI mechanism. > > > You're assuming that they complied with it in the first place. > > >> They presumably didn't do this lightly. > > > True, but they didn't spend eons thinking about the problem either. > > >> Now the cost of this simplification in implementations - now >> mandated by the RFC 4271 - is either unacceptable or so costly >> that the simple MRAI function needs to be replaced by something >> fussier. >> >> CPUs and memories of newer routers have become faster, so maybe >> it is easier now to have the more complex MRAI-like timer. On >> the other hand, there are now far more prefixes and maybe more >> peers it has to be implemented for. > > > The problem has not gotten easier. > > >> Implementing a more complex MRAI-like timer in new firmware >> upgrades to older routers may be prohibitive. >> >> So I guess the trick is to find the simplest solution which will >> solve the problem. > > > Isn't it always? ;-) > > >> It would be interesting to know what the difficulty was - >> because those difficulties may still be important and might >> prevent the adoption of Path Length Damping or some other >> mechanisms as your I-D suggests. > > > Rather than 'difficulty', I would say that developers made the > judgement call that the cost/benefit ratio was unacceptable. > > Tony > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 12 02:39:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sKc-0007Bw-U3; Thu, 12 Jul 2007 02:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sKc-0007Bm-50 for idr@ietf.org; Thu, 12 Jul 2007 02:39:18 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8sKY-0000Ar-Rj for idr@ietf.org; Thu, 12 Jul 2007 02:39:18 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Jul 2007 02:39:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJ9plUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,530,1175486400"; d="scan'208"; a="125847380:sNHT27090506" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6C6dEqs030950; Thu, 12 Jul 2007 02:39:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6C6dEs0028402; Thu, 12 Jul 2007 06:39:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 02:39:13 -0400 Received: from [192.168.0.101] ([10.82.240.72]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 02:39:13 -0400 In-Reply-To: <00ac01c7c44e$7d4f4a30$820c6f0a@china.huawei.com> References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <4B079921-73F4-4909-8CAC-83E85E58F90C@cisco.com> <00ac01c7c44e$7d4f4a30$820c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping Date: Wed, 11 Jul 2007 23:39:10 -0700 To: Michael X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jul 2007 06:39:13.0682 (UTC) FILETIME=[5C81CF20:01C7C44F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=658; t=1184222354; x=1185086354; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20Re=3A=20BGP=20path=20hunting, =20MRAI=20timer= 20and=20Path=20Length=20Damping |Sender:=20 |To:=20Michael=20; bh=k05UQ9v73p5Hr/rul33+NVIMSb6wZRGEuxarFPyWnSU=; b=GzKhw0LVeRcZwO2OJFZdSLsYCdYLKnMea4n2Ry0Cg05I6T+EkW+C/zW74luMGtJy02maFUys XL3+z9a5AnaZKi/slJ/IByx2yUT7NmqNBCuQhxDae4Bn6vevaKN3w6Vz; Authentication-Results: rtp-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Jul 11, 2007, at 11:32 PM, Michael wrote: > How to distinguish route changes due to a real topology change or a > path hunting? as I understand, a real topology change is one of the > reasons triggering a path hunting, other reasons include the > reconfiguration of route policies or management and maintenance > etc. And with respect to a very far AS, a BGP peer inside it can > not tell what real reason causes it change. That is exactly why the mechanisms that we are exploring are heuristics. There is no explicit information to tell us and the best that we can do is to make some educated guesses. Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 12 12:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91IS-0000rX-3x; Thu, 12 Jul 2007 12:13:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91IQ-0000mA-OC for idr@ietf.org; Thu, 12 Jul 2007 12:13:38 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I91IB-0005eN-Fu for idr@ietf.org; Thu, 12 Jul 2007 12:13:38 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D64797325DF; Thu, 12 Jul 2007 09:12:50 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21012-06; Thu, 12 Jul 2007 09:12:50 -0700 (PDT) Received: from [127.0.0.1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 62BFE7325DA; Thu, 12 Jul 2007 09:12:50 -0700 (PDT) Message-ID: <46965303.7030400@redback.com> Date: Thu, 12 Jul 2007 09:12:51 -0700 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Tony Li Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <4B079921-73F4-4909-8CAC-83E85E58F90C@cisco.com> <00ac01c7c44e$7d4f4a30$820c6f0a@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Tony Li wrote: > > On Jul 11, 2007, at 11:32 PM, Michael wrote: > >> How to distinguish route changes due to a real topology change or a >> path hunting? as I understand, a real topology change is one of the >> reasons triggering a path hunting, other reasons include the >> reconfiguration of route policies or management and maintenance etc. >> And with respect to a very far AS, a BGP peer inside it can not tell >> what real reason causes it change. > > > That is exactly why the mechanisms that we are exploring are > heuristics. There is no explicit information to tell us and the best > that we can do is to make some educated guesses. Real information is always better than heuristic guesses. Can we invent an attribute to add this: maybe "reason for update" ? > > Regards, > Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 12 12:36:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91ek-0003H4-GR; Thu, 12 Jul 2007 12:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91ej-0003Gy-24 for idr@ietf.org; Thu, 12 Jul 2007 12:36:41 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I91ef-0001li-N5 for idr@ietf.org; Thu, 12 Jul 2007 12:36:41 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 12 Jul 2007 09:36:37 -0700 X-IronPort-AV: i="unknown"; a="502561205:sNHT0" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6CGaaN2029814; Thu, 12 Jul 2007 09:36:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6CGaWGY008010; Thu, 12 Jul 2007 16:36:32 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 09:36:31 -0700 Received: from [171.70.221.242] ([171.70.221.242]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 09:33:23 -0700 In-Reply-To: <46965303.7030400@redback.com> References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <4B079921-73F4-4909-8CAC-83E85E58F90C@cisco.com> <00ac01c7c44e$7d4f4a30$820c6f0a@china.huawei.com> <46965303.7030400@redback.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0848FBF8-77EC-448D-8349-ABBC7DC03CF5@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping Date: Thu, 12 Jul 2007 09:33:20 -0700 To: Jakob Heitz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jul 2007 16:33:23.0492 (UTC) FILETIME=[5D731E40:01C7C4A2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=968; t=1184258196; x=1185122196; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20Re=3A=20BGP=20path=20hunting, =20MRAI=20timer= 20and=20Path=20Length=20Damping |Sender:=20; bh=iL93Gv5VtgxKbDXairGk6ztO95mNDMxlLYp27AFw5YI=; b=GrhOjnUdoIiedXhATk0ZHIAECz9Ri4MfE+37RD7drx2eyRqhrJYZ+RqzOCFXiv6hpDbLe7QD W77TSTJ2bq3M7IaPEDDbu+mvbtbLESLZOlEfeOA8fomyssdxt1SwUVlciJSqjLyC4NA27Ef9WK ZO5Fr4Ovan0vWYAdysyAzD/qY=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Jul 12, 2007, at 9:12 AM, Jakob Heitz wrote: >>> How to distinguish route changes due to a real topology change or >>> a path hunting? as I understand, a real topology change is one of >>> the reasons triggering a path hunting, other reasons include the >>> reconfiguration of route policies or management and maintenance >>> etc. And with respect to a very far AS, a BGP peer inside it can >>> not tell what real reason causes it change. >> That is exactly why the mechanisms that we are exploring are >> heuristics. There is no explicit information to tell us and the >> best that we can do is to make some educated guesses. > > Real information is always better than heuristic guesses. > Can we invent an attribute to add this: maybe "reason for update" ? We could try, but I'm not sure that we can maintain that information accurately. Specifically, when would we ever fill in the field with "path hunting"? Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 12 14:20:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93Gn-0002x4-Iv; Thu, 12 Jul 2007 14:20:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93Gk-0002mn-7v for idr@ietf.org; Thu, 12 Jul 2007 14:20:02 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I93GV-0002e9-EN for idr@ietf.org; Thu, 12 Jul 2007 14:20:02 -0400 Received: from dhcp-239-0.jakma.org (dhcp-239-0.jakma.org [192.168.0.239]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l6CIJ65F025116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 19:19:08 +0100 Date: Thu, 12 Jul 2007 19:18:52 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Tony Li Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-Reply-To: <0848FBF8-77EC-448D-8349-ABBC7DC03CF5@cisco.com> Message-ID: References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <4B079921-73F4-4909-8CAC-83E85E58F90C@cisco.com> <00ac01c7c44e$7d4f4a30$820c6f0a@china.huawei.com> <46965303.7030400@redback.com> <0848FBF8-77EC-448D-8349-ABBC7DC03CF5@cisco.com> 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 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.1.12 (hibernia.jakma.org [212.17.55.49]); Thu, 12 Jul 2007 19:19:09 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, 12 Jul 2007, Tony Li wrote: > We could try, but I'm not sure that we can maintain that information > accurately. Specifically, when would we ever fill in the field with "path > hunting"? Hmm, Jakob might be right... We don't need to maintain 'path hunting' state, we need to maintain "where in the network did the withdraw start?". If we do that, then we can detect subsets of the topology that must be as dead as the path the withdraw is for. E.g., Geoff's example: http://www.potaroo.net/ispcol/2007-06/fig1.jpg 5 could easily note that, given the withdrawal by 2 of 2_1, its other paths of 3_2_1 and 4_3_2_1 all go through 2 - and just avoid/defer picking those as new best-paths. This doesn't work if the failure is once (or more) removed, or for more complex cycles, e.g.: | | 5---6-\ / / \ \ 1-2-3-4 9 E | \ / / | 7--8 / A--B--C--D 6 has: 1_2_5 1_2_3_4 1_2_7_8_9 1_A_B_C_D_E If 1-2 fails, then 6 should get successive withdraws. It can't immediately tell where the failure occured. On the second withdraw, it could, by comparison, note that 1_2 is common, and theorise that the other paths with 1_2 in the path have a higher probability of imminent withdrawal than the 1_A_B_C_D_E path. That's still heuristics though, and a more complicated version of 3.4 'path length damping' from your stability draft. However, we could allow 6 to determine with /certainty/, if we had some kind of transitive Withdraw-Originater-AS attribute. With such: - 1_2 fails - 2 starts sending withdraws to 5, 3 and 7, each marked with some "AS2 started this.." - 6 receives a withdraw (from 5, 4 or 9, matters not which) - 6 starts best-path selection, taking the withdraw-originator into account - each path containing AS2 it can discount - leaving it to pick 1_A_B_C_D_E I.e. use the AS_PATH to do what it's there for - detect cycles ;). (just on the withdraw side). ;) (there'd be some additional details to take care of in the above scheme obviously..) regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Bad cafeteria food landed all the sysadmins in the hospital. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 12 15:50:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94fb-0003T4-R0; Thu, 12 Jul 2007 15:49:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94fa-0003Q7-VI for idr@ietf.org; Thu, 12 Jul 2007 15:49:46 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I94fV-0003Ks-Oi for idr@ietf.org; Thu, 12 Jul 2007 15:49:46 -0400 Received: from [203.37.10.108] (unknown [203.37.10.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 63309D5F33; Fri, 13 Jul 2007 05:49:39 +1000 (EST) Message-ID: <4696864B.7080304@apnic.net> Date: Fri, 13 Jul 2007 05:51:39 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Paul Jakma Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <4B079921-73F4-4909-8CAC-83E85E58F90C@cisco.com> <00ac01c7c44e$7d4f4a30$820c6f0a@china.huawei.com> <46965303.7030400@redback.com> <0848FBF8-77EC-448D-8349-ABBC7DC03CF5@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Tony Li , idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Paul Jakma wrote: > On Thu, 12 Jul 2007, Tony Li wrote: > >> We could try, but I'm not sure that we can maintain that information >> accurately. Specifically, when would we ever fill in the field with >> "path hunting"? > > Hmm, Jakob might be right... > > We don't need to maintain 'path hunting' state, we need to maintain > "where in the network did the withdraw start?". If we do that, then we > can detect subsets of the topology that must be as dead as the path the > withdraw is for. E.g., Geoff's example: > > http://www.potaroo.net/ispcol/2007-06/fig1.jpg > > 5 could easily note that, given the withdrawal by 2 of 2_1, its other > paths of 3_2_1 and 4_3_2_1 all go through 2 - and just avoid/defer > picking those as new best-paths. defer, not avoid - it may be that AS2 may have withdrawn the routing due to a policy change with respect to AS5 rather than the commencement of a path exploration leading to withdrawal. There have been a number of proposals I've seen in the literature on this topic that attempt to address Jakob's desire to explicitly mark the "path exploration" phase. The "this is a withdrawal at origin" flag appears to be a common thread, where a withdrawal is intended to be marked with a flag that says "this origin is pulling this prefix, don't listen to path exploration updates as all hope is already lost!" In response to this flag a bgp speak upon receiving such a flagged withdrawal would not advertise any withdrawal-triggered updates. Variants of this propose a flag to say "this AS path pair of origin and nexthop is dead - no not use any adj-rib entry that includes this path pair for this prefix" This explicit flagging would be more effective than attempting to second guess what is a path exploration update sequence, but there are likely some further considerations with the approach of explicit flagging of such events. - Its a change to all BGP deployments to be effective, not just a local change to the way in which updates are interpreted. By no means a major concern, but it does imply some morphing of the BGP spec to apply some transitive attribute to withdrawals that are essentially not in the spec at the moment. - While there are relatively simple topologies where this information of "complete withdrawal at source" is accessible, more complex topologies are tougher for a BGP speaker to determine whether to set such a flag or not. If thats the case then such explicit flagging of withdrawal "type" would only be present some of the time, leaving the issue of passive detection and damping of path exploration updates as one that would have some leverage in reducing the BGP update load. I suspect that there is still a valid case for the passive detection of path exploration update detection using the relatively simple heuristic of detecting sequences of update messages where the common characteristic is a) closely coupled in time, b) refer to the same prefix, c) refer to the same origin AS, and d) contain AS path vectors of increasing length. I also suspect (but I'm not convinced as yet) that a mechanism of deferral of further propagation of such detected updates could be a reasonable replacement for both route flap damping and the MRAI timer in BGP, given that both these mechanisms were similarly motivated by a desire to suppress the update load associated with the behaviour of distance vector algorithms in the face of a withdrawal. I should add however that this last suspicion (of potentially using this instead of MRAI and RFD) is pretty speculative, and the work I've done recently in looking at this used an approach of placing this detection on top of existing MRAI behaviour, so its not a case of have to use one or the other - both is a possible as well. Geoff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 12 21:37:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9A5F-0000aD-1e; Thu, 12 Jul 2007 21:36:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9A5D-0000a4-Q4 for idr@ietf.org; Thu, 12 Jul 2007 21:36:35 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9A4x-0007KM-UD for idr@ietf.org; Thu, 12 Jul 2007 21:36:35 -0400 Received: from dhcp-239-0.jakma.org (dhcp-239-0.jakma.org [192.168.0.239]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l6D1Zvkr031018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 02:35:59 +0100 Date: Fri, 13 Jul 2007 02:35:42 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Geoff Huston Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-Reply-To: <4696864B.7080304@apnic.net> Message-ID: References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <4B079921-73F4-4909-8CAC-83E85E58F90C@cisco.com> <00ac01c7c44e$7d4f4a30$820c6f0a@china.huawei.com> <46965303.7030400@redback.com> <0848FBF8-77EC-448D-8349-ABBC7DC03CF5@cisco.com> <4696864B.7080304@apnic.net> 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 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.1.12 (hibernia.jakma.org [192.168.0.3]); Fri, 13 Jul 2007 02:36:00 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Tony Li , idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Fri, 13 Jul 2007, Geoff Huston wrote: > - Its a change to all BGP deployments to be effective, not just a local > change to the way in which updates are interpreted. By no means a major > concern, but it does imply some morphing of the BGP spec to apply some > transitive attribute to withdrawals that are essentially not in the spec at > the moment. Indeed. However, given Curtis' email and his indication that there isn't any churn problem, least not of significance to justify any significant changes to BGP, is this idea feasible? To attach attributes to withdrawals means using MP_UNREACH_NLRI style UPDATE messages. Information that would only be transitive until the first non-MP capable session. However, '5' (or 6 in my more complex example topology), would only need /one/ withdrawal to get through with this extra information for it to be useful to do withdrawal-cycle detection on the /remaining/ paths it has to choose from (see below). > - While there are relatively simple topologies where this > information of "complete withdrawal at source" is accessible, more > complex topologies are tougher for a BGP speaker to determine > whether to set such a flag or not. If thats the case then such > explicit flagging of withdrawal "type" would only be present some > of the time, leaving the issue of passive detection and damping of > path exploration updates as one that would have some leverage in > reducing the BGP update load. Well, someone has to 'originate' the withdrawal. Indeed, let's not call it a withdrawal, call it an update - a poisoned update, to make it more clear. We know poisoning works from other DV protocols, and we can do a more precise (better) job in BGP than that other DV protocol thanks to the AS_PATH attribute. This poisoned update would withdraw the prefix, and provide an ASN which is 'poisoned' - any other path containing this ASN definitely is unuseable. There'd be two possibilities for a speaker sending such an UPDATE to another 'poison aware' speaker: a) There's an existing path-poison-ASN, leave that. b) There's none, sending speaker inserts its own - it's either the originator of the withdraw, or the closest speaker this direction of the 'fault' able to insert path-poison. Normal withdraws would be sent to speakers not aware of this mechanism, however that could /still/ allow remote speakers to take advantage of this scheme, e.g: 2 / \ -1 4 \ / 3 1 must withdraw some prefix. 2 is not poison-asn capable, 3 and 4 are. 4 receives: - normal withdraw from 2 - path-poison withdraw from 3, with ASN 1. I.e. 4 can still receive the poison update, and use it to invalidate whatever other remaining paths it may have to the prefix concerned. It means that, if it received 2's withdraw first, 4 still would have 'hunted', but the hunting stops once the poisoned-path withdraw is received from 3. I.e. there'd be some incremental deployment benefit. Does this seem worth pursuing? > I suspect that there is still a valid case for the passive > detection of path exploration update detection using the relatively > simple heuristic of detecting sequences of update messages where > the common characteristic is a) closely coupled in time, b) refer > to the same prefix, c) refer to the same origin AS, and d) contain > AS path vectors of increasing length. Yes indeed, that could still be applied to traditional withdrawals. It has the risks you mention in the draft though, which poisoning does not. Poisoning would allow suppression of bad paths with certainty, I think. > I also suspect (but I'm not convinced as yet) that a mechanism of > deferral of further propagation of such detected updates could be a > reasonable replacement for both route flap damping and the MRAI > timer in BGP, given that both these mechanisms were similarly > motivated by a desire to suppress the update load associated with > the behaviour of distance vector algorithms in the face of a > withdrawal. The band-stop model of damping seems useful. With empirical data, as you've been gathering, we could find update-frequencies and path-selection hold times that could be shown to suppress X% of hunts, with Y% false suppressions of new better paths. (i.e. use band-stop filtering, as per 3.3 of your draft, to influence whether to apply the delayed path-selection of 3.6 to a prefix). Obviously we'd need to: - ensure data gathered was representative - gather new data periodically (every few years?) and review the parameters to ensure they were still correct That seems a slight pain, when we could squash hunting with precision through poison (course, poisoning has the greater deployment barrier). > I should add however that this last suspicion (of potentially using > this instead of MRAI and RFD) is pretty speculative, and the work > I've done recently in looking at this used an approach of placing > this detection on top of existing MRAI behaviour, so its not a case > of have to use one or the other - both is a possible as well. Very interesting stuff :) regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Truth is the most valuable thing we have -- so let us economize it. -- Mark Twain _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 12 21:50:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9AIh-0000IE-Kq; Thu, 12 Jul 2007 21:50:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9AIg-0000I8-Bx for idr@ietf.org; Thu, 12 Jul 2007 21:50:30 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9AIb-0004f2-HK for idr@ietf.org; Thu, 12 Jul 2007 21:50:30 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL300AZHH2J9C@szxga04-in.huawei.com> for idr@ietf.org; Fri, 13 Jul 2007 09:49:31 +0800 (CST) Received: from m50376k ([10.111.12.130]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL300CA0H2HLE@szxga04-in.huawei.com> for idr@ietf.org; Fri, 13 Jul 2007 09:49:31 +0800 (CST) Date: Fri, 13 Jul 2007 09:49:29 +0800 From: Michael Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping To: Paul Jakma , Tony Li Message-id: <004701c7c4f0$0d9719f0$820c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <4B079921-73F4-4909-8CAC-83E85E58F90C@cisco.com> <00ac01c7c44e$7d4f4a30$820c6f0a@china.huawei.com> <46965303.7030400@redback.com> <0848FBF8-77EC-448D-8349-ABBC7DC03CF5@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi,Paul: The question is at some AS, a withdrawal message will stop propagating and it will be replaced by a new route advertisement if there is an alternate route available, in other words, the original route is withdrawn implicitly. It is this implicit withdrawal that blurs the difference between a withdrawal due to a real topology change (link down etc) and a state transition due to local route-chosen policy or reconfiguration of route policies. It is difficult to distinghish them. As I see, only the AS adjacent to the failed link can identify a real reason caused to its flap. Best, Michael ----- Original Message ----- From: "Paul Jakma" To: "Tony Li" Cc: "idr" Sent: Friday, July 13, 2007 2:18 AM Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping > On Thu, 12 Jul 2007, Tony Li wrote: > >> We could try, but I'm not sure that we can maintain that information >> accurately. Specifically, when would we ever fill in the field with "path >> hunting"? > > Hmm, Jakob might be right... > > We don't need to maintain 'path hunting' state, we need to maintain > "where in the network did the withdraw start?". If we do that, then > we can detect subsets of the topology that must be as dead as the > path the withdraw is for. E.g., Geoff's example: > > http://www.potaroo.net/ispcol/2007-06/fig1.jpg > > 5 could easily note that, given the withdrawal by 2 of 2_1, its other > paths of 3_2_1 and 4_3_2_1 all go through 2 - and just avoid/defer > picking those as new best-paths. > > This doesn't work if the failure is once (or more) removed, or for > more complex cycles, e.g.: > > | > | > 5---6-\ > / / \ \ > 1-2-3-4 9 E > | \ / / > | 7--8 / > A--B--C--D > > 6 has: > > 1_2_5 > 1_2_3_4 > 1_2_7_8_9 > 1_A_B_C_D_E > > If 1-2 fails, then 6 should get successive withdraws. It can't > immediately tell where the failure occured. On the second withdraw, > it could, by comparison, note that 1_2 is common, and theorise that > the other paths with 1_2 in the path have a higher probability of > imminent withdrawal than the 1_A_B_C_D_E path. > > That's still heuristics though, and a more complicated version of 3.4 > 'path length damping' from your stability draft. > > However, we could allow 6 to determine with /certainty/, if we had > some kind of transitive Withdraw-Originater-AS attribute. With such: > > - 1_2 fails > - 2 starts sending withdraws to 5, 3 and 7, each marked with > some "AS2 started this.." > - 6 receives a withdraw (from 5, 4 or 9, matters not which) > - 6 starts best-path selection, taking the withdraw-originator into > account > - each path containing AS2 it can discount > - leaving it to pick 1_A_B_C_D_E > > > I.e. use the AS_PATH to do what it's there for - detect cycles ;). > (just on the withdraw side). ;) > > (there'd be some additional details to take care of in the above > scheme obviously..) > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > Bad cafeteria food landed all the sysadmins in the hospital. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 12 23:58:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9CHz-0003Jy-Uq; Thu, 12 Jul 2007 23:57:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9CHy-0003Jt-Uy for idr@ietf.org; Thu, 12 Jul 2007 23:57:54 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9CHj-00028D-EM for idr@ietf.org; Thu, 12 Jul 2007 23:57:54 -0400 Received: from dhcp-239-0.jakma.org (dhcp-239-0.jakma.org [192.168.0.239]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l6D3vJQN032660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 04:57:22 +0100 Date: Fri, 13 Jul 2007 04:57:05 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Michael Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-Reply-To: <004701c7c4f0$0d9719f0$820c6f0a@china.huawei.com> Message-ID: References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <4B079921-73F4-4909-8CAC-83E85E58F90C@cisco.com> <00ac01c7c44e$7d4f4a30$820c6f0a@china.huawei.com> <46965303.7030400@redback.com> <0848FBF8-77EC-448D-8349-ABBC7DC03CF5@cisco.com> <004701c7c4f0$0d9719f0$820c6f0a@china.huawei.com> 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 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.1.12 (hibernia.jakma.org [212.17.55.49]); Fri, 13 Jul 2007 04:57:22 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Tony Li , idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Fri, 13 Jul 2007, Michael wrote: > Hi,Paul: > > The question is at some AS, a withdrawal message will stop > propagating and it will be replaced by a new route advertisement if > there is an alternate route available, in other words, the original > routeis withdrawn implicitly. Sure. At present, that alternate route may in fact be another dead-path, for which a withdrawal will soon be received - the hunting behaviour Li and Huston describe and are trying to address. With poisoning, the speaker would be able to discern with certainty between such 'also-dead' paths and other, hopefully viable, paths. If, with the help of poisoning, a viable path can be picked, and so the speaker stops propogating the poison then that's fine - that's exactly what the poison is for. Poison should only serve to kill bad paths, not viable paths. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: What passes for optimism is most often the effect of an intellectual error. -- Raymond Aron, "The Opium of the Intellectuals" _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jul 13 00:23:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Cgl-0001l1-Ay; Fri, 13 Jul 2007 00:23:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Cgk-0001kv-1k for idr@ietf.org; Fri, 13 Jul 2007 00:23:30 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Cgf-0008RL-O7 for idr@ietf.org; Fri, 13 Jul 2007 00:23:30 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6D4Mhuv073523; Fri, 13 Jul 2007 00:22:43 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707130422.l6D4Mhuv073523@harbor.brookfield.occnc.com> To: Tony Li From: Curtis Villamizar Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-reply-to: Your message of "Thu, 12 Jul 2007 09:33:20 PDT." <0848FBF8-77EC-448D-8349-ABBC7DC03CF5@cisco.com> Date: Fri, 13 Jul 2007 00:22:43 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message <0848FBF8-77EC-448D-8349-ABBC7DC03CF5@cisco.com> Tony Li writes: > > > > Real information is always better than heuristic guesses. > > Can we invent an attribute to add this: maybe "reason for update" ? > > > We could try, but I'm not sure that we can maintain that information > accurately. Specifically, when would we ever fill in the field with > "path hunting"? > > Tony Just provide an update RFC3514 documenting this usage with BGP. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jul 13 00:31:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9CoL-0002z6-OB; Fri, 13 Jul 2007 00:31:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9CoJ-0002yj-W9 for idr@ietf.org; Fri, 13 Jul 2007 00:31:20 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9CoI-0002sD-8J for idr@ietf.org; Fri, 13 Jul 2007 00:31:19 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6D4ULD5075072; Fri, 13 Jul 2007 00:30:21 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707130430.l6D4ULD5075072@harbor.brookfield.occnc.com> To: Paul Jakma From: Curtis Villamizar Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-reply-to: Your message of "Thu, 12 Jul 2007 19:18:52 BST." Date: Fri, 13 Jul 2007 00:30:21 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Tony Li , idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message Paul Jakma writes: > > http://www.potaroo.net/ispcol/2007-06/fig1.jpg > > 5 could easily note that, given the withdrawal by 2 of 2_1, its other > paths of 3_2_1 and 4_3_2_1 all go through 2 - and just avoid/defer > picking those as new best-paths. Ignoring the fact that this means saving AS Path information for withdrawn routes ... What about if AS2 made a policy change and decided not to announce to AS5, rather than AS2 lost the route. How long would you suppress any and all alternates that went through AS1-AS2? Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jul 13 09:24:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9L7e-0000Z3-38; Fri, 13 Jul 2007 09:23:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9L7c-0000UN-P8 for idr@ietf.org; Fri, 13 Jul 2007 09:23:48 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9L7U-0001tm-54 for idr@ietf.org; Fri, 13 Jul 2007 09:23:48 -0400 Received: from dhcp-239-0.jakma.org (dhcp-239-0.jakma.org [192.168.0.239]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l6DDMll7006586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 14:22:50 +0100 Date: Fri, 13 Jul 2007 14:22:33 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Curtis Villamizar Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-Reply-To: <200707130430.l6D4ULD5075072@harbor.brookfield.occnc.com> Message-ID: References: <200707130430.l6D4ULD5075072@harbor.brookfield.occnc.com> 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 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.1.12 (hibernia.jakma.org [192.168.0.3]); Fri, 13 Jul 2007 14:22:51 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Tony Li , idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Fri, 13 Jul 2007, Curtis Villamizar wrote: > Ignoring the fact that this means saving AS Path information for > withdrawn routes ... Ah, actually it doesn't. the speaker just has to examine its RIB and flag other routes as dead (1 bit), and setup a timer to re-examine those routes (a pointer and an entry on a list perhaps). NB: Even it did mean saving AS-path info, the stability draft suggests this for some of its optimisations, iirc. > What about if AS2 made a policy change and decided not to announce > to AS5, rather than AS2 lost the route. How long would you > suppress any and all alternates that went through AS1-AS2? For some short-period of time. Geoff Huston's column seems to suggest that BGP converges globally within 2 to 3 minutes, so that would be a suitable time-out. That's a question that'll be common to all alterate-suppression approaches I think (e.g. suppression based on increasing path-length). This only works for cycles with connected nodes, i.e. from Geoff's exmaple, where 5 had a path via 2 and is about to hunt over to a path via 3: 5 / \ 2---3 1 It can't work for larger cycles, e.g.: 5-3 / | 2 4 \ / 6 1 We'd need explicit poison information injected into the protocol to spot those I think, as per other emails. > Curtis -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Confession is good for the soul, but bad for the career. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jul 13 12:36:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9O7z-0005wd-9d; Fri, 13 Jul 2007 12:36:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9O7x-0005wS-Iz for idr@ietf.org; Fri, 13 Jul 2007 12:36:21 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9O7m-0008G7-BB for idr@ietf.org; Fri, 13 Jul 2007 12:36:21 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6DGZ7SB021900; Fri, 13 Jul 2007 12:35:07 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707131635.l6DGZ7SB021900@harbor.brookfield.occnc.com> To: Paul Jakma From: Curtis Villamizar Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-reply-to: Your message of "Fri, 13 Jul 2007 14:22:33 BST." Date: Fri, 13 Jul 2007 12:35:07 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Tony Li , idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message Paul Jakma writes: > > On Fri, 13 Jul 2007, Curtis Villamizar wrote: > > > Ignoring the fact that this means saving AS Path information for > > withdrawn routes ... > > Ah, actually it doesn't. the speaker just has to examine its RIB and > flag other routes as dead (1 bit), and setup a timer to re-examine > those routes (a pointer and an entry on a list perhaps). > > NB: Even it did mean saving AS-path info, the stability draft > suggests this for some of its optimisations, iirc. If you are going to save per AS Path information for a short period of time, then implement Route Flap Damping as specified instead of per prefix only and it won't need to be considered harmfull anymore. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 19 10:30:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBX1c-0002mW-DI; Thu, 19 Jul 2007 10:30:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBX1a-0002mB-FX for idr@ietf.org; Thu, 19 Jul 2007 10:30:38 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBX1a-0001nW-6s for idr@ietf.org; Thu, 19 Jul 2007 10:30:38 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 19 Jul 2007 07:30:37 -0700 X-IronPort-AV: i="4.16,557,1175497200"; d="scan'208"; a="40047457:sNHT27009104" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l6JEUZO45121; Thu, 19 Jul 2007 07:30:35 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200707191430.l6JEUZO45121@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79084.1184855434.1@juniper.net> Date: Thu, 19 Jul 2007 07:30:35 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: skh@nexthop.com Subject: [Idr] presentations X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, If you are on the agenda for Chicago, please send Sue and me your presentations. We would like to post as many of these as possible before the meeting starts. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jul 20 17:37:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC09l-0007jI-Ub; Fri, 20 Jul 2007 17:37:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC09k-0007ix-Ir for idr@ietf.org; Fri, 20 Jul 2007 17:37:00 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IC09k-0002gC-AH for idr@ietf.org; Fri, 20 Jul 2007 17:37:00 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 20 Jul 2007 14:36:59 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l6KLaxO62825 for ; Fri, 20 Jul 2007 14:36:59 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200707202136.l6KLaxO62825@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <92146.1184967418.1@juniper.net> Date: Fri, 20 Jul 2007 14:36:58 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Idr] mistake on the agenda X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, The agenda has one mistake - instead of draft-li-bgp-stability-00.txt it should be draft-li-bgp-stability-01.txt Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 26 09:56:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE3nu-0005fk-Ey; Thu, 26 Jul 2007 09:54:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE3nq-0005fd-UU for idr@ietf.org; Thu, 26 Jul 2007 09:54:54 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE3np-0005uQ-NQ for idr@ietf.org; Thu, 26 Jul 2007 09:54:54 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 26 Jul 2007 06:54:53 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l6QDsqO68829 for ; Thu, 26 Jul 2007 06:54:52 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200707261354.l6QDsqO68829@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10442.1185458092.1@juniper.net> Date: Thu, 26 Jul 2007 06:54:52 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Idr] presentations are available X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, All the presentations for today's IDR WG meeting are available on the web. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jul 26 15:21:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8sK-0001VO-WB; Thu, 26 Jul 2007 15:19:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8sK-0001VI-27 for idr@ietf.org; Thu, 26 Jul 2007 15:19:52 -0400 Received: from mint.apnic.net ([202.12.29.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE8sJ-0005iJ-1X for idr@ietf.org; Thu, 26 Jul 2007 15:19:51 -0400 Received: from [130.129.23.125] (dhcp-177d.ietf69.org [130.129.23.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 2A02AD5F36 for ; Fri, 27 Jul 2007 05:19:48 +1000 (EST) Message-ID: <46A8F44A.7070601@apnic.net> Date: Fri, 27 Jul 2007 05:21:46 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: idr Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Subject: [Idr] Minutes from IETF69 IDR WG meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org here's what I heard in the meeting! regards, Geoff IDR 26 June 2007-07-27, 1:00 pm Minutes: Geoff Huston Agenda was bashed 1. Document Status: Change since IETF68 - 4-octet AS published: RFC4893 - Autonomous System Confederatuiobn for BGP - revised draft submitted to RFC Editor - Avoid BGP best path transitions from one external to another - moved to RFC Editor queue - New WG document - draft-ietf-idr-v4nlri-v6nh-00.txt 2. PWE3 - Dynamic placement of MS-PW (draft-ietf-pwe3-dynamic-ms-pw-05.txt) Introduced to IDR to solicit comment on how BGP is to used in this pwe3 context. [slides to illustrate the proposed mechanism] Routing information (reachability) and provisioning (signalling) is used in VPLS autodiscovery, while dynamic ms-pw uses only reachability as provisioning is static The BGP NLRI is a 96 bit quantity of 3 x 32 bit components (global-ID, prefix and AC-ID) Requesting early allocation process for allocation of BGP SAFI = 6 for this NLRI Questions/Comments: The WG Chair noted that this is a PWE3 WG document, and the chair of the PWE3 WG has the role to manage the early allocation process Question on the use of private AS numbers in the Global-ID field of the NLRI? Does it have to be an AS or any globally unique 32 bit value? Response is that any 32 bit unique value oculd be used here. Question put to the WG if there was any WG comment on the PWE3 WG early allocation action? No comments from the WG. 2. Flow-spec (draft-marques-idr-slow-spec-04.txt) [slides] Approach to convey network transport layer attributes with a given NLRI in BGP. Adopt this as a WG document? Is this a capabilities exchange? Yes, this is exchanged only if there is a capabilities exchange here, so it will / should not leak inadvertently beyond understood scope. Operational deployment exists. Chairs will poll the mailing list with the document adoption question. 4. BGP Encapsulation SAFI and BGP Tunnel Encapsulation attributed (draft-pmohapat-idr-info-safi-02.txt) [slides] Adoption as a WG document? Noted that this is intended to be a normative reference by the softwires mesh framework in the Softwires WG. This is a similar case to the v4nlri-v6nh document. Chairs will poll the mailing list with the document adoption question. 5. BGP Stability Improvements (draft-li-bgp-stability) [slides] Document is work in progress. Considers the model of BGP as an ideal of information dissemination through single wavefront, but BGP, as deployed, has differing propagation speeds in differing networks, leading to "diffraction" of this information wavefront that amplifies the original information event into multiple events. The document explores some approaches to improve the dynamic behaviour in BGP based on using additional information related to heuristics that attempt to identify "diffraction" in BGP information propagation. Tony called for collaborators - literature search, analysis, coding and testing EFT. Questions / Comments: John Scudder suggests a worked example for each of the suggested mechanisms as some of the description is not clear. Also suggests that the goal here is to maximize connectivity here. For example removal of the MRAI timer is consistent with this. Illjitsch van Beijnum commented that these suppression techniques are poor as they negatively impact some particular use cases. Sue Hares noted that some "crisis" examples (failure) where failures would trigger motivations for rapid repair rather than damped convergence Yakov asked for more information about the small proportion of prefixes that are the subject of large volumes of updates John Scuddr on best path latching and the combination of this with path exploration is interesting - what is the effect of best path latching in isolation and is this useful? Tony commented that by itself there are some strange interactions here that do not necessarily "do no harm: Yakov - section 4.3.1 question about peak rate per hour? Clarified as a peak per second rate, expressed in hourly intervals. Lixia noted that there is a large set of literature on BGP analysis, and there are many ideas in this topic in this literature. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jul 27 11:01:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERJd-0008HN-0p; Fri, 27 Jul 2007 11:01:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERJb-0008HH-TJ for idr@ietf.org; Fri, 27 Jul 2007 11:01:15 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IERJb-0006TT-8Z for idr@ietf.org; Fri, 27 Jul 2007 11:01:15 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 27 Jul 2007 08:01:15 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l6RF1EO05626 for ; Fri, 27 Jul 2007 08:01:14 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200707271501.l6RF1EO05626@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36961.1185548473.1@juniper.net> Date: Fri, 27 Jul 2007 08:01:14 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, IDR WG chairs received a request to accept draft-marques-idr-flow-spec-04.txt as an IDR WG document (see attached). Comments are greatly appreciated. The deadline for comments is August 10, 2007. Yakov. ------- Forwarded Message Date: Thu, 26 Jul 2007 12:33:27 -0600 From: Danny McPherson To: Hares Susan , Yakov Rekhter cc: Pedro Roque Marques , raszuk@juniper.net Subject: Fwd: I-D ACTION:draft-marques-idr-flow-spec-04.txt Susan/Yakov, As discussed in the meeting today, could you please ask the WG about this becoming a WG item? - -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: July 8, 2007 4:15:02 PM MDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-marques-idr-flow-spec-04.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Dissemination of flow specification rules > Author(s) : P. Marques, et al. > Filename : draft-marques-idr-flow-spec-04.txt > Pages : 25 > Date : 2007-7-8 > > This document defines a new BGP NLRI encoding format that can be used > to distribute traffic flow specifications. This allows the routing > system to propagate information regarding more-specific > components of > the traffic aggregate defined by an IP destination prefix. > > Additionally it defines two applications of that encoding format. > One that can be used to automate inter-domain coordination of > traffic > filtering, such as what is required in order to mitigate > (distributed) denial of service attacks. And a second > application to > traffic filtering in the context of a BGP/MPLS VPN service. > > The information is carried via the Border Gateway Protocol (BGP), > thereby reusing protocol algorithms, operational experience and > administrative processes such as inter-provider peering agreements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-marques-idr-flow-spec-04.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-marques-idr-flow-spec-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-marques-idr-flow-spec-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-7-8172242.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jul 27 11:18:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERaV-0006ld-St; Fri, 27 Jul 2007 11:18:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERaU-0006lO-96 for idr@ietf.org; Fri, 27 Jul 2007 11:18:42 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERaS-0006eS-Qb for idr@ietf.org; Fri, 27 Jul 2007 11:18:42 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 27 Jul 2007 08:18:41 -0700 X-IronPort-AV: i="4.16,589,1175497200"; d="scan'208"; a="44650064:sNHT79653982" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l6RFIdO09187 for ; Fri, 27 Jul 2007 08:18:39 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200707271518.l6RFIdO09187@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37704.1185549519.1@juniper.net> Date: Fri, 27 Jul 2007 08:18:39 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Subject: [Idr] comments on the minutes X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, If you have any comments on the minutes (see attached) please send them to me. The deadline is August 10, 2007. Yakov. ------- Forwarded Message Date: Fri, 27 Jul 2007 05:21:46 +1000 From: Geoff Huston To: idr Subject: [Idr] Minutes from IETF69 IDR WG meeting here's what I heard in the meeting! regards, Geoff IDR 26 June 2007-07-27, 1:00 pm Minutes: Geoff Huston Agenda was bashed 1. Document Status: Change since IETF68 - 4-octet AS published: RFC4893 - Autonomous System Confederatuiobn for BGP - revised draft submitted to RFC Editor - Avoid BGP best path transitions from one external to another - moved to RFC Editor queue - New WG document - draft-ietf-idr-v4nlri-v6nh-00.txt 2. PWE3 - Dynamic placement of MS-PW (draft-ietf-pwe3-dynamic-ms-pw-05.txt) Introduced to IDR to solicit comment on how BGP is to used in this pwe3 context. [slides to illustrate the proposed mechanism] Routing information (reachability) and provisioning (signalling) is used in VPLS autodiscovery, while dynamic ms-pw uses only reachability as provisioning is static The BGP NLRI is a 96 bit quantity of 3 x 32 bit components (global-ID, prefix and AC-ID) Requesting early allocation process for allocation of BGP SAFI = 6 for this NLRI Questions/Comments: The WG Chair noted that this is a PWE3 WG document, and the chair of the PWE3 WG has the role to manage the early allocation process Question on the use of private AS numbers in the Global-ID field of the NLRI? Does it have to be an AS or any globally unique 32 bit value? Response is that any 32 bit unique value oculd be used here. Question put to the WG if there was any WG comment on the PWE3 WG early allocation action? No comments from the WG. 2. Flow-spec (draft-marques-idr-slow-spec-04.txt) [slides] Approach to convey network transport layer attributes with a given NLRI in BGP. Adopt this as a WG document? Is this a capabilities exchange? Yes, this is exchanged only if there is a capabilities exchange here, so it will / should not leak inadvertently beyond understood scope. Operational deployment exists. Chairs will poll the mailing list with the document adoption question. 4. BGP Encapsulation SAFI and BGP Tunnel Encapsulation attributed (draft-pmohapat-idr-info-safi-02.txt) [slides] Adoption as a WG document? Noted that this is intended to be a normative reference by the softwires mesh framework in the Softwires WG. This is a similar case to the v4nlri-v6nh document. Chairs will poll the mailing list with the document adoption question. 5. BGP Stability Improvements (draft-li-bgp-stability) [slides] Document is work in progress. Considers the model of BGP as an ideal of information dissemination through single wavefront, but BGP, as deployed, has differing propagation speeds in differing networks, leading to "diffraction" of this information wavefront that amplifies the original information event into multiple events. The document explores some approaches to improve the dynamic behaviour in BGP based on using additional information related to heuristics that attempt to identify "diffraction" in BGP information propagation. Tony called for collaborators - literature search, analysis, coding and testing EFT. Questions / Comments: John Scudder suggests a worked example for each of the suggested mechanisms as some of the description is not clear. Also suggests that the goal here is to maximize connectivity here. For example removal of the MRAI timer is consistent with this. Illjitsch van Beijnum commented that these suppression techniques are poor as they negatively impact some particular use cases. Sue Hares noted that some "crisis" examples (failure) where failures would trigger motivations for rapid repair rather than damped convergence Yakov asked for more information about the small proportion of prefixes that are the subject of large volumes of updates John Scuddr on best path latching and the combination of this with path exploration is interesting - what is the effect of best path latching in isolation and is this useful? Tony commented that by itself there are some strange interactions here that do not necessarily "do no harm: Yakov - section 4.3.1 question about peak rate per hour? Clarified as a peak per second rate, expressed in hourly intervals. Lixia noted that there is a large set of literature on BGP analysis, and there are many ideas in this topic in this literature. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jul 27 11:21:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERcf-0007ya-MF; Fri, 27 Jul 2007 11:20:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERce-0007qf-CY for idr@ietf.org; Fri, 27 Jul 2007 11:20:56 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERce-0006i4-42 for idr@ietf.org; Fri, 27 Jul 2007 11:20:56 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 27 Jul 2007 08:20:55 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l6RFKjO09704; Fri, 27 Jul 2007 08:20:45 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200707271520.l6RFKjO09704@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37829.1185549645.1@juniper.net> Date: Fri, 27 Jul 2007 08:20:45 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: skh@nexthop.com Subject: [Idr] draft-pmohapat-idr-info-safi-02.txt as an IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, The authors of draft-pmohapat-idr-info-safi-02.txt asked the IDR WG to accept their draft as an IDR WG document. Comments are greatly appreciated. The deadline for comments is August 10, 2007. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jul 27 11:26:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERhp-0005rd-28; Fri, 27 Jul 2007 11:26:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERho-0005rR-0W for idr@ietf.org; Fri, 27 Jul 2007 11:26:16 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERhm-0006qQ-QM for idr@ietf.org; Fri, 27 Jul 2007 11:26:15 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 27 Jul 2007 08:26:13 -0700 X-IronPort-AV: i="4.16,589,1175497200"; d="scan'208"; a="44653199:sNHT31554904" Received: from [172.23.11.37] ([172.23.11.37]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l6RFQBO10884 for ; Fri, 27 Jul 2007 08:26:11 -0700 (PDT) (envelope-from raszuk@juniper.net) Message-ID: <46AA0E90.8070603@juniper.net> Date: Fri, 27 Jul 2007 17:26:08 +0200 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: idr@ietf.org Subject: Re: [Idr] draft-pmohapat-idr-info-safi-02.txt as an IDR WG document References: <200707271520.l6RFKjO09704@merlot.juniper.net> In-Reply-To: <200707271520.l6RFKjO09704@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Robert Raszuk List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org I think we have agreed to call this draft with the new name reflecting it's content. Can it be reposted by authors as draft-pmohapat-idr-encap-safi before accepting it as WG item ? Thx, R. > Folks, > > The authors of draft-pmohapat-idr-info-safi-02.txt asked > the IDR WG to accept their draft as an IDR WG document. > > Comments are greatly appreciated. The deadline for comments is > August 10, 2007. > > Yakov. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 30 04:31:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFQeO-0001Ai-Ss; Mon, 30 Jul 2007 04:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFQeN-0001A0-N1 for idr@ietf.org; Mon, 30 Jul 2007 04:30:47 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFQeL-0004nF-9t for idr@ietf.org; Mon, 30 Jul 2007 04:30:47 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id BA23859DE9; Mon, 30 Jul 2007 18:30:38 +1000 (EST) Message-ID: <46ADA1A2.9000308@firstpr.com.au> Date: Mon, 30 Jul 2007 18:30:26 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: idr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Idr] Is the best-path decision affected by congestion? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org If someone can help me with this, I would really appreciate it. This more a question about BGP implementations and router behavior than about the protocol itself. I am thinking primarily of a transit router in a mesh of other transit routers, with for some reason this particular transit router being regarded by many others as part of the "best-path" for one or more prefixes which carry a lot of traffic. Q1 - Does a BGP router ever change its best-path for any prefix (which it uses for forwarding itself, and which it tells its peers) based on traffic levels and congestion? If so, then I could imagine a situation where changes in the way one or more prefixes A, B etc. were forwarded by other routers, (or changes in traffic on those prefixes) could affect congestion on one link or one peer of a given router, which would cause it to change its "best path" for some other prefixes N, M etc. I think this could lead to ongoing instability and oscillation throughout the network as other routers also adapted to the changed traffic flows for prefixes N, M etc. Q2 - Alternatively, if BGP routers never consider congestion when deciding on their best path, then doesn't this lead to problems unless everyone ensures, somehow, that their router and its datalinks are never congested? The only way I could imagine this being achieved is by some manual or automatic change to what best paths the router advertises, based on traffic levels and actual, or potential, congestion - which seems to be an instance of "yes" for the first question. The funnelling of traffic to one router or another might change from time to time without any action on the part of a particular router - and traffic levels vary enormously. I don't see how a router operator could ensure their router remains uncongested at all times, without some change to how the router announces best routes, at least for some prefixes. BTW, I am corresponding with one of the people at the iPlane project: http://iplane.cs.washington.edu I wanted to know roughly how many BGP routers there are, and how many of them are in the DFZ. Apparently their "Lists of alias clusters" doesn't quite show this, and they are going to get back to me about this next week. I will report whatever I find on this list. - Robin _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 30 09:25:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVEy-0000o1-Qh; Mon, 30 Jul 2007 09:24:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVEw-0000no-US for idr@ietf.org; Mon, 30 Jul 2007 09:24:50 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFVEw-00053l-9N for idr@ietf.org; Mon, 30 Jul 2007 09:24:50 -0400 Received: from hibernia.jakma.org (IDENT:U2FsdGVkX1/KZK0Flj73M5fn1YUqkMJ7m6fMhf5mZBI@hibernia.jakma.org [212.17.55.49] (may be forged)) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l6UDOJqG002007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jul 2007 14:24:24 +0100 Date: Mon, 30 Jul 2007 14:24:19 +0100 (IST) From: Paul Jakma X-X-Sender: paul@hibernia.jakma.org To: Tony Li Subject: Re: [Idr] Re: draft-ietf-idr-as-pathlimit-03.txt In-Reply-To: Message-ID: References: <77ead0ec0706071402p48baaa24yef6f17cb1d2e8cd6@mail.gmail.com> 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 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (hibernia.jakma.org [212.17.55.49]); Mon, 30 Jul 2007 14:24:24 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Inter-Domain Routing List X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Tony, A query on the following language in the draft: If the AS_PATHLIMIT attribute is attached to a prefix by a private AS, then when the prefix is advertised outside of the parent AS, the AS number contained in the AS_PATHLIMIT attribute should be replaced by the AS number of the parent AS. Could it be made more explicit here as to which speaker is responsible here? E.g. is it the responsibility of /all/ pathlimit capable speakers to update a private-AS in a pathlimit with a public one (the attribute may transit one or more non-pathlimit capable ASes while containing a private AS)? Should a speaker with a private AS, implementing this attribute, be pro-active and, when sending an UPDATE to a non-private-AS, set the pathlimit AS in such an UPDATE to the peer's ASN? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: No man would listen to you talk if he didn't know it was his turn next. -- E.W. Howe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 30 09:36:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVQA-0006jt-Na; Mon, 30 Jul 2007 09:36:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVQ9-0006jn-He for idr@ietf.org; Mon, 30 Jul 2007 09:36:25 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFVQ8-0006fA-9x for idr@ietf.org; Mon, 30 Jul 2007 09:36:25 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2007 06:36:23 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGqFrUarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.19,198,1183359600"; d="scan'208"; a="389006913:sNHT27852194" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6UDaNmh022296; Mon, 30 Jul 2007 06:36:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6UDaN6C021832; Mon, 30 Jul 2007 13:36:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 06:36:23 -0700 Received: from [192.168.0.6] ([10.21.82.43]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 06:36:22 -0700 In-Reply-To: References: <77ead0ec0706071402p48baaa24yef6f17cb1d2e8cd6@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8568F506-61F6-4518-B221-739F978547C3@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Re: draft-ietf-idr-as-pathlimit-03.txt Date: Mon, 30 Jul 2007 06:36:13 -0700 To: Paul Jakma X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Jul 2007 13:36:23.0042 (UTC) FILETIME=[9E9A8E20:01C7D2AE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1526; t=1185802583; x=1186666583; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20Re=3A=20draft-ietf-idr-as-pathlimit-03.txt |Sender:=20; bh=ICHRBRsSm4gNvSnoF2AwRhin578KDuCacClgh7jxiWI=; b=LhBhyY0J7F8w/iiYkrIzrygkk6yOcITxNa0R8yLJwMmS7/QG/ji03l7pUg5W5Ps72hJOrrEB o+2jDzjRNSFqQcb9QkBZ4rOrN9HHcTUPVTivRXQNiM0UU20I9YxvqMsL; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Inter-Domain Routing List X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Paul, > If the AS_PATHLIMIT attribute is attached to a prefix by a private > AS, then when the prefix is advertised outside of the parent AS, > the > AS number contained in the AS_PATHLIMIT attribute should be > replaced > by the AS number of the parent AS. > > Could it be made more explicit here as to which speaker is > responsible here? Certainly. Wording improvements are certainly welcome. > E.g. is it the responsibility of /all/ pathlimit capable speakers > to update a private-AS in a pathlimit with a public one (the > attribute may transit one or more non-pathlimit capable ASes while > containing a private AS)? Hmm... Well, I'd like to say yes, but then we have to explain how a speaker that is remote from the private-AS should behave. What number does it insert? Unless it has implemented some type of oracle, I don't see how it can reasonably infer the correct public AS number. > Should a speaker with a private AS, implementing this attribute, be > pro-active and, when sending an UPDATE to a non-private-AS, set the > pathlimit AS in such an UPDATE to the peer's ASN? I had always thought of this as the responsibility of the speakers within the public AS infrastructure, as they are already responsible for stripping the private ASNs from the AS_PATH. However, what you propose certainly sounds reasonable. I'm amenable if there's consensus around specific wording. Do you have a proposal? Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 30 09:58:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVlK-0000xp-Ue; Mon, 30 Jul 2007 09:58:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVlK-0000xk-1O for idr@ietf.org; Mon, 30 Jul 2007 09:58:18 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFVlJ-0005oy-AZ for idr@ietf.org; Mon, 30 Jul 2007 09:58:17 -0400 Received: from hibernia.jakma.org (IDENT:U2FsdGVkX1/AQyBTp5oqj+jvxqTK0tVNW/yeiP7ygzg@hibernia.jakma.org [192.168.0.3]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l6UDwA41002456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jul 2007 14:58:13 +0100 Date: Mon, 30 Jul 2007 14:58:10 +0100 (IST) From: Paul Jakma X-X-Sender: paul@hibernia.jakma.org To: Tony Li Subject: Re: [Idr] Re: draft-ietf-idr-as-pathlimit-03.txt In-Reply-To: <8568F506-61F6-4518-B221-739F978547C3@cisco.com> Message-ID: References: <77ead0ec0706071402p48baaa24yef6f17cb1d2e8cd6@mail.gmail.com> <8568F506-61F6-4518-B221-739F978547C3@cisco.com> 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 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (hibernia.jakma.org [192.168.0.3]); Mon, 30 Jul 2007 14:58:13 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Inter-Domain Routing List X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Mon, 30 Jul 2007, Tony Li wrote: >> E.g. is it the responsibility of /all/ pathlimit capable speakers >> to update a private-AS in a pathlimit with a public one (the >> attribute may transit one or more non-pathlimit capable ASes while >> containing a private AS)? > Hmm... Well, I'd like to say yes, but then we have to explain how > a speaker that is remote from the private-AS should behave. What > number does it insert? Unless it has implemented some type of > oracle, I don't see how it can reasonably infer the correct public > AS number. Indeed. Though, in such a situation, is it better to update the private AS (in the belief that closest identifiable public AS to the source is better than a private AS)? I guess that's best of a bad lot.. > I had always thought of this as the responsibility of the speakers > within the public AS infrastructure, as they are already > responsible for stripping the private ASNs from the AS_PATH. > However, what you propose certainly sounds reasonable. It seems like it add a bit of pro-active robustness for mixed-speaker environments (?). > I'm amenable if there's consensus around specific wording. Do you > have a proposal? Hmm, how about adding an example? If the AS_PATHLIMIT attribute is attached to a prefix by a private AS, then when the prefix is advertised outside of the parent AS, the AS number contained in the AS_PATHLIMIT attribute should be replaced by the AS number of the parent AS. E.g. When sending an AS_PATHLIMIT with a private-ASN to an EBGP neighbour outside of the parent AS, a speaker should update the ASN in the attribute with preferrably its own ASN, if that is a public ASN, or else the ASN of the EBGP peer the attribute is being sent to, if that is a public ASN. That still allows for the discretion around determining 'parent AS' which the original wording carefully put there, but gives a gentle hint as to expected behaviour.. Or somesuch.. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: If in doubt, mumble. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 30 10:07:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVuQ-0006EU-VF; Mon, 30 Jul 2007 10:07:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVuQ-00068n-5A for idr@ietf.org; Mon, 30 Jul 2007 10:07:42 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFVuP-000623-NJ for idr@ietf.org; Mon, 30 Jul 2007 10:07:42 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2007 07:07:41 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABaOrUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.19,198,1183359600"; d="scan'208"; a="191093714:sNHT27873846" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6UE7f1F018504; Mon, 30 Jul 2007 07:07:41 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6UE7cSd012461; Mon, 30 Jul 2007 14:07:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 07:07:36 -0700 Received: from [192.168.0.6] ([10.21.88.211]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 07:07:36 -0700 In-Reply-To: <46ADA1A2.9000308@firstpr.com.au> References: <46ADA1A2.9000308@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2F73BE08-8AD6-4F4C-82BC-F757E9BA6E1C@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Is the best-path decision affected by congestion? Date: Mon, 30 Jul 2007 07:07:18 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Jul 2007 14:07:36.0401 (UTC) FILETIME=[FB367410:01C7D2B2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1947; t=1185804461; x=1186668461; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20Is=20the=20best-path=20decision=20affected=20 by=20congestion? |Sender:=20; bh=XlrZhZntU3ieTJcgFxtjxGmElaUZ6fc1ekW0aMa9djw=; b=J5K3PZ5K5Jmgmmpv1im5GqX0KYDAewYWmm6fDpT2BW66GExCN0m/BuhGtIfy3qgH12jIUVCv VIr/O1aeFc5lfs2VCppASEdw0/uRhPes8uHkWGnZMIUqyHCoBlp+DrL6; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Robin, On Jul 30, 2007, at 1:30 AM, Robin Whittle wrote: > Q1 - Does a BGP router ever change its best-path for any > prefix (which it uses for forwarding itself, and which it > tells its peers) based on traffic levels and congestion? Nope. > I think this could lead to ongoing instability and oscillation > throughout the network as other routers also adapted to the > changed traffic flows for prefixes N, M etc. That's why... We never figured out how to make it stable. Someone with enough background in control theory and development time could conceivably install enough low pass filtering to make this stable and conclusively prove that it's stable, but no one has done this to date. Maybe when I retire... ;-) > Q2 - Alternatively, if BGP routers never consider congestion when > deciding on their best path, then doesn't this lead to > problems unless everyone ensures, somehow, that their router > and its datalinks are never congested? > > The only way I could imagine this being achieved is by some manual > or automatic change to what best paths the router advertises, > based on traffic levels and actual, or potential, congestion - > which seems to be an instance of "yes" for the first question. Correct. There are a slew of mechanisms for doing exactly this. For example, intra-domain traffic engineering with MPLS, manipulation of IGP metrics, tweaks to local pref, etc. > The funnelling of traffic to one router or another might change > from time to time without any action on the part of a particular > router - and traffic levels vary enormously. I don't see how a > router operator could ensure their router remains uncongested at > all times, without some change to how the router announces best > routes, at least for some prefixes. ... and then you hire a staff full of smart people, 24 x 7, to turn the knobs. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 30 10:12:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVyl-0007tP-KF; Mon, 30 Jul 2007 10:12:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVyk-0007tH-GA for idr@ietf.org; Mon, 30 Jul 2007 10:12:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFVyk-00067G-1l for idr@ietf.org; Mon, 30 Jul 2007 10:12:10 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2007 07:12:10 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAePrUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.19,198,1183359600"; d="scan'208"; a="508355686:sNHT27321006" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6UEC9vJ026133; Mon, 30 Jul 2007 07:12:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6UEC5Tf020571; Mon, 30 Jul 2007 14:12:05 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 07:12:04 -0700 Received: from [192.168.0.6] ([10.21.88.211]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 07:12:00 -0700 In-Reply-To: References: <77ead0ec0706071402p48baaa24yef6f17cb1d2e8cd6@mail.gmail.com> <8568F506-61F6-4518-B221-739F978547C3@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68357C8C-66C0-4520-8316-CACA1C431CCE@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Re: draft-ietf-idr-as-pathlimit-03.txt Date: Mon, 30 Jul 2007 07:11:59 -0700 To: Paul Jakma X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Jul 2007 14:12:04.0313 (UTC) FILETIME=[9AE69490:01C7D2B3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1858; t=1185804729; x=1186668729; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20Re=3A=20draft-ietf-idr-as-pathlimit-03.txt |Sender:=20; bh=RiM9o66nl5toAy7n10M3MCv0YO67LtFzrD+ABtVv3vo=; b=bmpp8o9HLWsfdhMogEi8HaoH46cksch/UmPl3tlgiSgDyqHxt+RZdhMhQWcbPAylbWRzSHKi WK0RKU9cgdiaPRk6jZjbXJ+HxPNqtS+5XB65/5eVsN1C7CxG0rSZm1mZ; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Inter-Domain Routing List X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org >> Hmm... Well, I'd like to say yes, but then we have to explain how >> a speaker that is remote from the private-AS should behave. What >> number does it insert? Unless it has implemented some type of >> oracle, I don't see how it can reasonably infer the correct public >> AS number. > > Though, in such a situation, is it better to update the private AS > (in the belief that closest identifiable public AS to the source is > better than a private AS)? I guess that's best of a bad lot.. Agreed. >> I had always thought of this as the responsibility of the speakers >> within the public AS infrastructure, as they are already >> responsible for stripping the private ASNs from the AS_PATH. >> However, what you propose certainly sounds reasonable. > > It seems like it add a bit of pro-active robustness for mixed- > speaker environments (?). > >> I'm amenable if there's consensus around specific wording. Do you >> have a proposal? > > Hmm, how about adding an example? > > If the AS_PATHLIMIT attribute is attached to a prefix by a private > AS, then when the prefix is advertised outside of the parent AS, > the > AS number contained in the AS_PATHLIMIT attribute should be > replaced > by the AS number of the parent AS. > > E.g. When sending an AS_PATHLIMIT with a private-ASN to an EBGP > neighbour outside of the parent AS, a speaker should update the > ASN in the attribute with preferrably its own ASN, if that is a > public ASN, or else the ASN of the EBGP peer the attribute is > being sent to, if that is a public ASN. > > That still allows for the discretion around determining 'parent AS' > which the original wording carefully put there, but gives a gentle > hint as to expected behaviour.. Works for me. Other folks? Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 30 10:23:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFW9C-00059f-6B; Mon, 30 Jul 2007 10:22:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFW9A-00059Z-1f for idr@ietf.org; Mon, 30 Jul 2007 10:22:56 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFW99-0006Nb-GC for idr@ietf.org; Mon, 30 Jul 2007 10:22:55 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id AE05559E41; Tue, 31 Jul 2007 00:22:49 +1000 (EST) Message-ID: <46ADF42D.3090806@firstpr.com.au> Date: Tue, 31 Jul 2007 00:22:37 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: idr Subject: Re: [Idr] Is the best-path decision affected by congestion? References: <46ADA1A2.9000308@firstpr.com.au> <2F73BE08-8AD6-4F4C-82BC-F757E9BA6E1C@cisco.com> In-Reply-To: <2F73BE08-8AD6-4F4C-82BC-F757E9BA6E1C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Tony Li X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Tony, Thanks very much for your reply - which answers all my questions. > ... and then you hire a staff full of smart people, 24 x 7, to turn the > knobs. I understand from this that routers which have too much traffic are reconfigured to announce best-paths to their peers which are longer than they otherwise would be, with the effect that more traffic goes via other routers instead. Ideally, I guess, this is done reasonably wisely and smoothly, so there is no oscillations as other routers are reconfigured when their traffic volumes go up. - Robin _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jul 30 10:49:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWYK-0003ZG-NI; Mon, 30 Jul 2007 10:48:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWYJ-0003ZB-1n for idr@ietf.org; Mon, 30 Jul 2007 10:48:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFWYH-0008IR-T2 for idr@ietf.org; Mon, 30 Jul 2007 10:48:55 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Jul 2007 10:48:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgeAIaWrUZAZnme/2dsb2JhbACENg X-IronPort-AV: i="4.19,198,1183348800"; d="scan'208"; a="127401904:sNHT24418830" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6UEmr79029761; Mon, 30 Jul 2007 10:48:53 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6UEmrWI029511; Mon, 30 Jul 2007 14:48:53 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id l6UEmjqK007142; Mon, 30 Jul 2007 10:48:53 -0400 To: Robert Raszuk Subject: Re: [Idr] draft-pmohapat-idr-info-safi-02.txt as an IDR WG document In-reply-to: Your message of Fri, 27 Jul 2007 17:26:08 +0200. <46AA0E90.8070603@juniper.net> Date: Mon, 30 Jul 2007 10:48:45 -0400 Message-ID: <7141.1185806925@erosen-linux> From: Eric Rosen DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=190; t=1185806933; x=1186670933; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20[Idr]=20draft-pmohapat-idr-info-safi-02.txt=20as=20an =20IDR=20WG=20document=20 |Sender:=20 |To:=20Robert=20Raszuk=20; bh=FdxhEuuN+qYsdvvSVEodX19VGIhSNZtoogRHsOIwztY=; b=p3v6cyHwicr+vtvhSuLHEVVTBB4qvkfRByhJtqCujLOF7KTWjlZDi2H2CjXDW2L6txGkOy4k 96dnlFhIroWBD5sFkAFZPmsPLwl9w7DukrEHJFrUMnCDKHH0i9UJk/VH; Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org > Can it be reposted by authors as draft-pmohapat-idr-encap-safi before > accepting it as WG item ? No, but if it is accepted it will be posted as draft-ietf-idr-encaps-safi-00 ;-) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr