From routing-discussion-admin@ietf.org Fri Aug 1 01:53:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27344 for ; Fri, 1 Aug 2003 01:53:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iSpd-00077B-CF; Fri, 01 Aug 2003 01:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iSpI-00076q-7s for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 01:51:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27321 for ; Fri, 1 Aug 2003 01:51:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iSpE-0002XF-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 01:51:36 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19iSpD-0002X6-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 01:51:35 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 90DA520299 for ; Thu, 31 Jul 2003 23:53:42 -0600 (MDT) Subject: The Natural Entropy of the Internet? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: routing-discussion@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <08B07F65-C3E4-11D7-BD2D-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 23:50:19 -0600 Content-Transfer-Encoding: 7bit On Thursday, July 31, 2003, at 07:57 PM, Mark Prior wrote: > Having this new stuff separate from the production stuff is good > and the more separate the better. And this is where the problem arises. "the more separate the better" perhaps holds true when simply considering complexity increase of a system, but what about *other* pragmatic factors such as competitiveness, economies or commercial market forces? The reality is that service providers are converging networks in order to decrease operational expenditures associated with maintaining multiple parallel [overlay] networks (networks that likely already employ the same transport substrate), all while continuing to expand service offerings, associated footprints and overall service availability. Anyone that doesn't buy this, go talk to your marketing, finance or business folks -- or customers, it's reality, whether we like it or not. Much of the arguable complexity being added to BGP and other routing protocols is simply a result of its success (e.g., trivial to implement, leverages deployed code and protocols, existing operator knowledge base, ease of deployment, etc, etc..). The same holds true for the carriage of new services via IP networks (i.e., pseudo wires and the whole VPLS & L2/L3 VPN thing). "IP Everywhere", we asked for it! If it's really a good idea or not is far to often an afterthought. Success breeds repetition (as any network operator attempting to halt another "one-off" would likely attest to). My position, which isn't firmly within either of the two obvious "camps", is that allowing such "extensions" to continue unmetered will unquestionably have a negative impact on the global Internet, regardless of what scoped deployment scenarios the designers of any individual feature or extension initially envisioned. However, with that said, I fear the reality is that regardless of the outcome of these or any other [largely academic] discussions, the immediate tangible value of this whole passel of convergence-oriented subjects will prevail. Beyond increasing awareness of the intricacies and associated implications to the global Internet, and perhaps beginning work on some next-generation routing/signaling protocols, there's little we can do at this stage. -danny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 01:53:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27345 for ; Fri, 1 Aug 2003 01:53:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iSqV-0007Fx-5u for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 01:52:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h715qtIG027890 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 01:52:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iSpd-00077B-CF; Fri, 01 Aug 2003 01:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iSpI-00076q-7s for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 01:51:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27321 for ; Fri, 1 Aug 2003 01:51:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iSpE-0002XF-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 01:51:36 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19iSpD-0002X6-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 01:51:35 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 90DA520299 for ; Thu, 31 Jul 2003 23:53:42 -0600 (MDT) Subject: The Natural Entropy of the Internet? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: routing-discussion@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <08B07F65-C3E4-11D7-BD2D-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 23:50:19 -0600 Content-Transfer-Encoding: 7bit On Thursday, July 31, 2003, at 07:57 PM, Mark Prior wrote: > Having this new stuff separate from the production stuff is good > and the more separate the better. And this is where the problem arises. "the more separate the better" perhaps holds true when simply considering complexity increase of a system, but what about *other* pragmatic factors such as competitiveness, economies or commercial market forces? The reality is that service providers are converging networks in order to decrease operational expenditures associated with maintaining multiple parallel [overlay] networks (networks that likely already employ the same transport substrate), all while continuing to expand service offerings, associated footprints and overall service availability. Anyone that doesn't buy this, go talk to your marketing, finance or business folks -- or customers, it's reality, whether we like it or not. Much of the arguable complexity being added to BGP and other routing protocols is simply a result of its success (e.g., trivial to implement, leverages deployed code and protocols, existing operator knowledge base, ease of deployment, etc, etc..). The same holds true for the carriage of new services via IP networks (i.e., pseudo wires and the whole VPLS & L2/L3 VPN thing). "IP Everywhere", we asked for it! If it's really a good idea or not is far to often an afterthought. Success breeds repetition (as any network operator attempting to halt another "one-off" would likely attest to). My position, which isn't firmly within either of the two obvious "camps", is that allowing such "extensions" to continue unmetered will unquestionably have a negative impact on the global Internet, regardless of what scoped deployment scenarios the designers of any individual feature or extension initially envisioned. However, with that said, I fear the reality is that regardless of the outcome of these or any other [largely academic] discussions, the immediate tangible value of this whole passel of convergence-oriented subjects will prevail. Beyond increasing awareness of the intricacies and associated implications to the global Internet, and perhaps beginning work on some next-generation routing/signaling protocols, there's little we can do at this stage. -danny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 02:04:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00750 for ; Fri, 1 Aug 2003 02:04:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iT10-0007bx-Nr for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 02:03:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7163k9D029185 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 02:03:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iT0H-0007Ta-JO; Fri, 01 Aug 2003 02:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iSzl-0007Re-Mk for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 02:02:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29345 for ; Fri, 1 Aug 2003 02:02:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iSzi-0002Zh-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 02:02:26 -0400 Received: from dhcp108.yarralumla.aarnet.edu.au ([192.94.63.108] helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19iSzh-0002Ze-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 02:02:25 -0400 Received: from [192.94.63.108] (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h7162HGV001141; Fri, 1 Aug 2003 15:32:23 +0930 (CST) (envelope-from mrp@mrp.net) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: The Natural Entropy of the Internet? From: Mark Prior To: Danny McPherson , Message-ID: In-Reply-To: <08B07F65-C3E4-11D7-BD2D-000393D54EA6@tcb.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 15:32:16 +0930 Content-Transfer-Encoding: 7bit On 1/8/03 3:20 PM, "Danny McPherson" wrote: > > On Thursday, July 31, 2003, at 07:57 PM, Mark Prior wrote: > >> Having this new stuff separate from the production stuff is good >> and the more separate the better. > > And this is where the problem arises. "the more separate the > better" perhaps holds true when simply considering complexity > increase of a system, but what about *other* pragmatic factors > such as competitiveness, economies or commercial market > forces? > I agree there is a practical limit where extending the division makes no sense as these things need to operate on the same underlying infrastructure but having a mechanism that keeps them from affecting each other within the routing hardware would be a good thing. Having some new feature take out my production BGP process would be a bad thing. Worst still if it required a reboot into another version of the operating system to get a version of that process that didn't continually crash. Mark. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 02:36:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10422 for ; Fri, 1 Aug 2003 02:36:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTWD-0001h5-WA; Fri, 01 Aug 2003 02:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTVS-0001d8-WC for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 02:35:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10395 for ; Fri, 1 Aug 2003 02:35:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iTVP-0002md-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 02:35:11 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19iTVO-0002mN-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 02:35:10 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id A1BBA344A0; Thu, 31 Jul 2003 23:31:33 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h716YfYB020435; Thu, 31 Jul 2003 23:34:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: The Natural Entropy of the Internet? Message-ID: Thread-Topic: The Natural Entropy of the Internet? Thread-Index: AcNX8SGiu98GkzBHQyOpoBFJfjOgRwAANpuA From: "Tony Li" To: "Danny McPherson" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 23:34:40 -0700 Content-Transfer-Encoding: quoted-printable Folks, Thank you all for the intriguing discussion. Sorry I haven't been around to play, I've been off being a Scum Sucking Bottom Feeding Vendor again. ;-) I would like to take the opportunity to try to uplevel this discussion a bit. All of the discussions about how we should architect and implement software are charming, but the fundamental question that we should be wrestling with is at a higher level: what is the role of the IETF in making technical decisions that affect not only the Internet but=20 many IP networks elsewhere that are not necessarily connected? In Ye Olden Days, when we were young and na=EFve, we felt that we got to decide. Eric remembers this: Fortunately this is the IETF not the ITU-T, and we=20 make our decisions by dint of technical deliberations=20 rather than by having a popularity contest.=20 However, that age passed away a long time ago. If you weren't watching carefully, that age died at Kobe and we held the funeral in Boston. We still mourn its passing. The IETF today has to deal with complex commercial pressures from both vendors and operators, there are politics aplenty, and compromise is the name of the game. When the politics are too close to call, we simply let the market decide. We have a very hard time saying no, because anytime that the IETF says no, someone loses and doesn't necessarily do so gracefully. Thus, when we total up the forces driving a decision, we=20 look at all of the contributing factors and if the net sum is positive, there's a new RFC. This is reality. We don't have to like it, but we do have to live with it. Wake up and smell the coffee. Deal. Today, with the carriers in disarray, the commercial pressures are overwhelming. Profitability is the watchword and technical elegance and rationality are certainly in the back seat (if=20 they are still even on the bus -- which I sometimes doubt). In this particular case, the market has already decided what it wants (with some vendor influence) and technical matters did not intrude on the process. To try to influence the decision at this point will largely be in vain. At the very least, what do we offer to counter the commercial pressures of doing VPNs based on the Internet infrastructure? Without something at=20 least as weighty as market forces, we seem to be at something of a disadvantage. While it's true, we might be able to color some of the low level implementation details, at the higher level, no matter of the outcome, these applications will be placed squarely on the shoulders of the routing subsystem. This may be ill-advised, but can the IETF say 'no' and make it stick? That would seem unlikely in the extreme. What can we do and how can we make use of our resources? =20 Is fiddling around with "The Clone of BGP" going to help us do anything other than produce a B-grade monster flick? Our only upside here is our ability to influence deployments of the technology. To make all carriers aware of the implications of their choices, not only to their own infrastructures, but to the Internet as a whole. We need to give them an alternative that removes the yoke of VPNs from routing entirely. Let's not waste our breath micro-optimizing our architectures to bear an inappropriate load, let's do what we need to do to shoulder it for now and use our energy to move past this to a better solution at the architectural level. Regards, Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 02:36:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10425 for ; Fri, 1 Aug 2003 02:36:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTWg-0001lG-0p for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 02:36:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h716aT9a006595 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 02:36:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTWD-0001h5-WA; Fri, 01 Aug 2003 02:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTVS-0001d8-WC for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 02:35:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10395 for ; Fri, 1 Aug 2003 02:35:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iTVP-0002md-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 02:35:11 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19iTVO-0002mN-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 02:35:10 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id A1BBA344A0; Thu, 31 Jul 2003 23:31:33 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h716YfYB020435; Thu, 31 Jul 2003 23:34:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: The Natural Entropy of the Internet? Message-ID: Thread-Topic: The Natural Entropy of the Internet? Thread-Index: AcNX8SGiu98GkzBHQyOpoBFJfjOgRwAANpuA From: "Tony Li" To: "Danny McPherson" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 23:34:40 -0700 Content-Transfer-Encoding: quoted-printable Folks, Thank you all for the intriguing discussion. Sorry I haven't been around to play, I've been off being a Scum Sucking Bottom Feeding Vendor again. ;-) I would like to take the opportunity to try to uplevel this discussion a bit. All of the discussions about how we should architect and implement software are charming, but the fundamental question that we should be wrestling with is at a higher level: what is the role of the IETF in making technical decisions that affect not only the Internet but=20 many IP networks elsewhere that are not necessarily connected? In Ye Olden Days, when we were young and na=EFve, we felt that we got to decide. Eric remembers this: Fortunately this is the IETF not the ITU-T, and we=20 make our decisions by dint of technical deliberations=20 rather than by having a popularity contest.=20 However, that age passed away a long time ago. If you weren't watching carefully, that age died at Kobe and we held the funeral in Boston. We still mourn its passing. The IETF today has to deal with complex commercial pressures from both vendors and operators, there are politics aplenty, and compromise is the name of the game. When the politics are too close to call, we simply let the market decide. We have a very hard time saying no, because anytime that the IETF says no, someone loses and doesn't necessarily do so gracefully. Thus, when we total up the forces driving a decision, we=20 look at all of the contributing factors and if the net sum is positive, there's a new RFC. This is reality. We don't have to like it, but we do have to live with it. Wake up and smell the coffee. Deal. Today, with the carriers in disarray, the commercial pressures are overwhelming. Profitability is the watchword and technical elegance and rationality are certainly in the back seat (if=20 they are still even on the bus -- which I sometimes doubt). In this particular case, the market has already decided what it wants (with some vendor influence) and technical matters did not intrude on the process. To try to influence the decision at this point will largely be in vain. At the very least, what do we offer to counter the commercial pressures of doing VPNs based on the Internet infrastructure? Without something at=20 least as weighty as market forces, we seem to be at something of a disadvantage. While it's true, we might be able to color some of the low level implementation details, at the higher level, no matter of the outcome, these applications will be placed squarely on the shoulders of the routing subsystem. This may be ill-advised, but can the IETF say 'no' and make it stick? That would seem unlikely in the extreme. What can we do and how can we make use of our resources? =20 Is fiddling around with "The Clone of BGP" going to help us do anything other than produce a B-grade monster flick? Our only upside here is our ability to influence deployments of the technology. To make all carriers aware of the implications of their choices, not only to their own infrastructures, but to the Internet as a whole. We need to give them an alternative that removes the yoke of VPNs from routing entirely. Let's not waste our breath micro-optimizing our architectures to bear an inappropriate load, let's do what we need to do to shoulder it for now and use our energy to move past this to a better solution at the architectural level. Regards, Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 02:50:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00744 for ; Fri, 1 Aug 2003 02:04:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iT0H-0007Ta-JO; Fri, 01 Aug 2003 02:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iSzl-0007Re-Mk for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 02:02:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29345 for ; Fri, 1 Aug 2003 02:02:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iSzi-0002Zh-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 02:02:26 -0400 Received: from dhcp108.yarralumla.aarnet.edu.au ([192.94.63.108] helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19iSzh-0002Ze-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 02:02:25 -0400 Received: from [192.94.63.108] (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h7162HGV001141; Fri, 1 Aug 2003 15:32:23 +0930 (CST) (envelope-from mrp@mrp.net) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: The Natural Entropy of the Internet? From: Mark Prior To: Danny McPherson , Message-ID: In-Reply-To: <08B07F65-C3E4-11D7-BD2D-000393D54EA6@tcb.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 15:32:16 +0930 Content-Transfer-Encoding: 7bit On 1/8/03 3:20 PM, "Danny McPherson" wrote: > > On Thursday, July 31, 2003, at 07:57 PM, Mark Prior wrote: > >> Having this new stuff separate from the production stuff is good >> and the more separate the better. > > And this is where the problem arises. "the more separate the > better" perhaps holds true when simply considering complexity > increase of a system, but what about *other* pragmatic factors > such as competitiveness, economies or commercial market > forces? > I agree there is a practical limit where extending the division makes no sense as these things need to operate on the same underlying infrastructure but having a mechanism that keeps them from affecting each other within the routing hardware would be a good thing. Having some new feature take out my production BGP process would be a bad thing. Worst still if it required a reboot into another version of the operating system to get a version of that process that didn't continually crash. Mark. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 03:01:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10990 for ; Fri, 1 Aug 2003 03:01:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTut-00035X-UQ for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 03:01:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7171VGf011871 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 03:01:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTuQ-00031t-Eg; Fri, 01 Aug 2003 03:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTu9-000316-6l for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 03:00:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10946 for ; Fri, 1 Aug 2003 03:00:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iTu5-0002uT-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 03:00:41 -0400 Received: from nova.noc.catch.no ([193.69.2.2]) by ietf-mx with esmtp (Exim 4.12) id 19iTu3-0002uJ-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 03:00:39 -0400 Received: from [193.69.2.66] (callisto.noc.catch.no [193.69.2.66]) by nova.noc.catch.no (Postfix) with ESMTP id CF2341003E; Fri, 1 Aug 2003 09:00:07 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna From: Lars Erik Gullerud To: raszuk@cisco.com Cc: routing-discussion@ietf.org In-Reply-To: <3F294216.65FD655B@cisco.com> References: <3F2936E6.E8F46012@cisco.com> <1059668206.39692.547.camel@callisto.noc.catch.no> <3F294216.65FD655B@cisco.com> Content-Type: text/plain Message-Id: <1059721207.42058.12.camel@callisto.noc.catch.no> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 01 Aug 2003 09:00:07 +0200 Content-Transfer-Encoding: 7bit Of course you can use multiple sessions and build separate meshes, and for a lot of cases, this is in fact already the common way to do it. But that hardly scales ad infinitum, and in fact causes even more administrative hassles than if each service was carried in it's own completely separate protocol, as you now also need N addresses set up on each host to support N services in individual sessions. My point was that while you say that "that is what making each AFI/SAFI fully modular is all about", BGP has certain inherent properties that does NOT make them fully modular. If you really want BGP to be the generalized "stuff distribution protocol", then the protocol needs even more changes to generalize it to this level. Whether making a "BGP5" with these kinds of changes is the way to go or to create a brand new "stuff distribution protocol" is something I don't really have an opinion on - I just don't think BGP as we know it today is the answer. I'll just restate my earlier comment - it's about isolating each service so any failure will impact as small a portion of the customers as possible. And as the complexity increases, and the chances for failure with it, this becomes even more important. /leg On Thu, 2003-07-31 at 18:21, Robert Raszuk wrote: > Lars, > > There is nothing which would prohibit anyone today from using a > dedicated BGP session for each AF mesh. So all probles you are > describing are very valid, but can be already addressed today by few > extra config lines. > > Further from TCP point of view adding another protocol or using multiple > sessions for existing one is the same thing. > > R. > > > Lars Erik Gullerud wrote: > > > > On Thu, 2003-07-31 at 17:33, Robert Raszuk wrote: > > > > > Reg the sandwitch analogy ... > > > > > > Two (or N) smaller sandwitches could be easily done by cutting the 1 > > > meter (sorry 3 feet) long one into pieces (read modules) before > > > consumption. That is exactly what making each new AFI/SAFI fully modular > > > is all about. Notice also that once cutted it is packed in individual > > > bags for distribution (each AFI/SAFI uses a separate update msg). > > > > One problem as I see it right now though, is that if the contents of one > > of those bags isn't satisfactory (i.e. an update message is invalid), > > you throw the whole loaf of bread away (i.e. peer sends notification > > message and tears down the BGP session). And as more and more different > > sandwiches have to be made, the chances increase that a sloppy chef > > mistakenly puts ham on one of them instead of salami, so this is a real > > concern. > > > > But since we are starting to stretch this sandwich analogy, let's go > > back to cleartext - I have had the "pleasure" of observing the effects > > on a network where buggy router code from vendor X generated bad update > > messages for one AFI (in this case, vpnv4) and BGP sessions started > > dropping all over the place. Which then ended up affecting a > > substantially bigger portion of the customer mass than if only the VPN > > service had gone down. Without going into details, let's just say the > > guys in suits were not too happy, and the guys in jeans were sweating > > heavily that day. > > > > I'm not saying a separate protocol for every service is the preferred > > way to go, but from an operators POV, a "soft" failure of one service > > should ideally not affect all the other services being provided on the > > same infrastructure, but rather contain the failure to that particular > > service. Exactly how that is achieved however, is something we Ops guys > > usually prefer to leave as an exercise to the people we pay obscene > > amounts of money for those giant paperweights we stuff into our 19" > > racks. > > > > /leg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 03:47:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01881 for ; Fri, 1 Aug 2003 03:47:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUcv-0005IB-HQ; Fri, 01 Aug 2003 03:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iQqh-0002Vg-7b for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 23:44:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23314 for ; Thu, 31 Jul 2003 23:44:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iQqf-0001vz-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 23:44:57 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 19iQqe-0001vw-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 23:44:56 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 66A404F3DC; Thu, 31 Jul 2003 23:44:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16169.57898.113544.745292@durmstrang.padfoot.com> From: Henry Kilmer To: raszuk@cisco.com Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <3F2936E6.E8F46012@cisco.com> References: <3F2936E6.E8F46012@cisco.com> X-Mailer: VM 7.14 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 23:44:42 -0400 Content-Transfer-Encoding: 7bit Dorian can correct me if I'm wrong here but I think the operators would say that it is easier to do the Heimlich maneuver when the object stuck is small. Robert Raszuk writes: >Jeff, > >> > But, if you're eating the same amount of food either way, >> > then is it better to get a "bigger mouth," or a >> > "smaller sandwich?" >> >> Russ - >> To repeat myself, I don't think the issue is the raw >> amount of data. It is the complexity of the protocol >> and rate of convergence protocol convergence. (And I don't >> think that BGP is linear in convergence, so two smaller >> sandwichs would be better than one bigger one with the >> same wieght.) > >Reg the sandwitch analogy ... > >Two (or N) smaller sandwitches could be easily done by cutting the 1 >meter (sorry 3 feet) long one into pieces (read modules) before >consumption. That is exactly what making each new AFI/SAFI fully modular >is all about. Notice also that once cutted it is packed in individual >bags for distribution (each AFI/SAFI uses a separate update msg). > >Some folks on this list don't like to use knives and want to make small >sandwitches when there is only one piece of bread already in action. So >first let's make sure we have a bread ready on the table for a second >sandwitch then start putting salami on it :). > >R. > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 03:47:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01896 for ; Fri, 1 Aug 2003 03:47:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUcw-0005IJ-3F; Fri, 01 Aug 2003 03:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iQzZ-0002oT-3O for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 23:54:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23589 for ; Thu, 31 Jul 2003 23:54:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iQzW-0001y9-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 23:54:06 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 19iQzW-0001y6-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 23:54:06 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 9A10F4F3D8; Thu, 31 Jul 2003 23:53:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16169.58448.372462.810008@durmstrang.padfoot.com> From: Henry Kilmer To: routing-discussion@ietf.org Subject: Re: RP overloading: operational feedback In-Reply-To: <200307311443.h6VEheXw002982@rtp-core-1.cisco.com> References: <110611371345.20030731002953@psg.com> <200307311443.h6VEheXw002982@rtp-core-1.cisco.com> X-Mailer: VM 7.14 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 23:53:52 -0400 Content-Transfer-Encoding: 7bit What is the point of this message if we agree that we are all representing ourselves as individuals and not our companies as was previously discussed? If you want to make the below statement non-biased, it would be fair to say that both operators and vendors have supported at times the use of BGP for inappropriate purposes. It would also be true to say that both operators and vendors have prevented the misuse of BGP in the past as well. Eric Rosen writes: > >Of course, a survey of the PPVPN archives will show many messages from >operators supporting the extension of BGP. In fact, there are messages from >operators supporting the use of BGP for totally inappropriate purposes that >(IMHO) should be rejected by the IETF. > >Fortunately this is the IETF not the ITU-T, and we make our decisions by >dint of technical deliberations rather than by having a popularity contest. I'll go on record in saying that I am VERY concerned about the state of BGP today and adding to it will make it worse not better. Give me the ability to seperate my functions and information distribution as much as possible so I can track, monitor, restart or whatever else I need to do seperately. The extractions being made in the arguments on these threads frustrating and serve no productive purpose. Robert Raszuk writes: > >There is nothing which would prohibit anyone today from using a >dedicated BGP session for each AF mesh. So all probles you are >describing are very valid, but can be already addressed today by few >extra config lines. > >Further from TCP point of view adding another protocol or using multiple >sessions for existing one is the same thing. There is potentially a difference in the complexity of the programs being run. So while seperating into to BGP processes might seperate fate, it might be better engineered to have the process optimized for the purpose being used. -Hank _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 03:47:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01898 for ; Fri, 1 Aug 2003 03:47:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUdN-0005Qo-5a for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 03:47:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h717lTNB020789 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 03:47:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUcw-0005IJ-3F; Fri, 01 Aug 2003 03:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iQzZ-0002oT-3O for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 23:54:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23589 for ; Thu, 31 Jul 2003 23:54:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iQzW-0001y9-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 23:54:06 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 19iQzW-0001y6-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 23:54:06 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 9A10F4F3D8; Thu, 31 Jul 2003 23:53:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16169.58448.372462.810008@durmstrang.padfoot.com> From: Henry Kilmer To: routing-discussion@ietf.org Subject: Re: RP overloading: operational feedback In-Reply-To: <200307311443.h6VEheXw002982@rtp-core-1.cisco.com> References: <110611371345.20030731002953@psg.com> <200307311443.h6VEheXw002982@rtp-core-1.cisco.com> X-Mailer: VM 7.14 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 23:53:52 -0400 Content-Transfer-Encoding: 7bit What is the point of this message if we agree that we are all representing ourselves as individuals and not our companies as was previously discussed? If you want to make the below statement non-biased, it would be fair to say that both operators and vendors have supported at times the use of BGP for inappropriate purposes. It would also be true to say that both operators and vendors have prevented the misuse of BGP in the past as well. Eric Rosen writes: > >Of course, a survey of the PPVPN archives will show many messages from >operators supporting the extension of BGP. In fact, there are messages from >operators supporting the use of BGP for totally inappropriate purposes that >(IMHO) should be rejected by the IETF. > >Fortunately this is the IETF not the ITU-T, and we make our decisions by >dint of technical deliberations rather than by having a popularity contest. I'll go on record in saying that I am VERY concerned about the state of BGP today and adding to it will make it worse not better. Give me the ability to seperate my functions and information distribution as much as possible so I can track, monitor, restart or whatever else I need to do seperately. The extractions being made in the arguments on these threads frustrating and serve no productive purpose. Robert Raszuk writes: > >There is nothing which would prohibit anyone today from using a >dedicated BGP session for each AF mesh. So all probles you are >describing are very valid, but can be already addressed today by few >extra config lines. > >Further from TCP point of view adding another protocol or using multiple >sessions for existing one is the same thing. There is potentially a difference in the complexity of the programs being run. So while seperating into to BGP processes might seperate fate, it might be better engineered to have the process optimized for the purpose being used. -Hank _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 03:47:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01926 for ; Fri, 1 Aug 2003 03:47:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUdN-0005Qm-5P for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 03:47:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h717lTj0020790 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 03:47:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUcv-0005IB-HQ; Fri, 01 Aug 2003 03:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iQqh-0002Vg-7b for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 23:44:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23314 for ; Thu, 31 Jul 2003 23:44:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iQqf-0001vz-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 23:44:57 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 19iQqe-0001vw-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 23:44:56 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 66A404F3DC; Thu, 31 Jul 2003 23:44:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16169.57898.113544.745292@durmstrang.padfoot.com> From: Henry Kilmer To: raszuk@cisco.com Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <3F2936E6.E8F46012@cisco.com> References: <3F2936E6.E8F46012@cisco.com> X-Mailer: VM 7.14 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 23:44:42 -0400 Content-Transfer-Encoding: 7bit Dorian can correct me if I'm wrong here but I think the operators would say that it is easier to do the Heimlich maneuver when the object stuck is small. Robert Raszuk writes: >Jeff, > >> > But, if you're eating the same amount of food either way, >> > then is it better to get a "bigger mouth," or a >> > "smaller sandwich?" >> >> Russ - >> To repeat myself, I don't think the issue is the raw >> amount of data. It is the complexity of the protocol >> and rate of convergence protocol convergence. (And I don't >> think that BGP is linear in convergence, so two smaller >> sandwichs would be better than one bigger one with the >> same wieght.) > >Reg the sandwitch analogy ... > >Two (or N) smaller sandwitches could be easily done by cutting the 1 >meter (sorry 3 feet) long one into pieces (read modules) before >consumption. That is exactly what making each new AFI/SAFI fully modular >is all about. Notice also that once cutted it is packed in individual >bags for distribution (each AFI/SAFI uses a separate update msg). > >Some folks on this list don't like to use knives and want to make small >sandwitches when there is only one piece of bread already in action. So >first let's make sure we have a bread ready on the table for a second >sandwitch then start putting salami on it :). > >R. > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 03:49:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10989 for ; Fri, 1 Aug 2003 03:01:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTuQ-00031t-Eg; Fri, 01 Aug 2003 03:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iTu9-000316-6l for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 03:00:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10946 for ; Fri, 1 Aug 2003 03:00:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iTu5-0002uT-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 03:00:41 -0400 Received: from nova.noc.catch.no ([193.69.2.2]) by ietf-mx with esmtp (Exim 4.12) id 19iTu3-0002uJ-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 03:00:39 -0400 Received: from [193.69.2.66] (callisto.noc.catch.no [193.69.2.66]) by nova.noc.catch.no (Postfix) with ESMTP id CF2341003E; Fri, 1 Aug 2003 09:00:07 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna From: Lars Erik Gullerud To: raszuk@cisco.com Cc: routing-discussion@ietf.org In-Reply-To: <3F294216.65FD655B@cisco.com> References: <3F2936E6.E8F46012@cisco.com> <1059668206.39692.547.camel@callisto.noc.catch.no> <3F294216.65FD655B@cisco.com> Content-Type: text/plain Message-Id: <1059721207.42058.12.camel@callisto.noc.catch.no> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 01 Aug 2003 09:00:07 +0200 Content-Transfer-Encoding: 7bit Of course you can use multiple sessions and build separate meshes, and for a lot of cases, this is in fact already the common way to do it. But that hardly scales ad infinitum, and in fact causes even more administrative hassles than if each service was carried in it's own completely separate protocol, as you now also need N addresses set up on each host to support N services in individual sessions. My point was that while you say that "that is what making each AFI/SAFI fully modular is all about", BGP has certain inherent properties that does NOT make them fully modular. If you really want BGP to be the generalized "stuff distribution protocol", then the protocol needs even more changes to generalize it to this level. Whether making a "BGP5" with these kinds of changes is the way to go or to create a brand new "stuff distribution protocol" is something I don't really have an opinion on - I just don't think BGP as we know it today is the answer. I'll just restate my earlier comment - it's about isolating each service so any failure will impact as small a portion of the customers as possible. And as the complexity increases, and the chances for failure with it, this becomes even more important. /leg On Thu, 2003-07-31 at 18:21, Robert Raszuk wrote: > Lars, > > There is nothing which would prohibit anyone today from using a > dedicated BGP session for each AF mesh. So all probles you are > describing are very valid, but can be already addressed today by few > extra config lines. > > Further from TCP point of view adding another protocol or using multiple > sessions for existing one is the same thing. > > R. > > > Lars Erik Gullerud wrote: > > > > On Thu, 2003-07-31 at 17:33, Robert Raszuk wrote: > > > > > Reg the sandwitch analogy ... > > > > > > Two (or N) smaller sandwitches could be easily done by cutting the 1 > > > meter (sorry 3 feet) long one into pieces (read modules) before > > > consumption. That is exactly what making each new AFI/SAFI fully modular > > > is all about. Notice also that once cutted it is packed in individual > > > bags for distribution (each AFI/SAFI uses a separate update msg). > > > > One problem as I see it right now though, is that if the contents of one > > of those bags isn't satisfactory (i.e. an update message is invalid), > > you throw the whole loaf of bread away (i.e. peer sends notification > > message and tears down the BGP session). And as more and more different > > sandwiches have to be made, the chances increase that a sloppy chef > > mistakenly puts ham on one of them instead of salami, so this is a real > > concern. > > > > But since we are starting to stretch this sandwich analogy, let's go > > back to cleartext - I have had the "pleasure" of observing the effects > > on a network where buggy router code from vendor X generated bad update > > messages for one AFI (in this case, vpnv4) and BGP sessions started > > dropping all over the place. Which then ended up affecting a > > substantially bigger portion of the customer mass than if only the VPN > > service had gone down. Without going into details, let's just say the > > guys in suits were not too happy, and the guys in jeans were sweating > > heavily that day. > > > > I'm not saying a separate protocol for every service is the preferred > > way to go, but from an operators POV, a "soft" failure of one service > > should ideally not affect all the other services being provided on the > > same infrastructure, but rather contain the failure to that particular > > service. Exactly how that is achieved however, is something we Ops guys > > usually prefer to leave as an exercise to the people we pay obscene > > amounts of money for those giant paperweights we stuff into our 19" > > racks. > > > > /leg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 03:56:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02130 for ; Fri, 1 Aug 2003 03:56:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUld-0005pr-EX; Fri, 01 Aug 2003 03:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUlT-0005pZ-AC for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 03:55:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02119 for ; Fri, 1 Aug 2003 03:55:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iUlQ-0003J4-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 03:55:48 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19iUlQ-0003J1-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 03:55:48 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h717tGpp001115; Fri, 1 Aug 2003 00:55:17 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJW30060; Fri, 1 Aug 2003 00:49:58 -0700 (PDT) Message-ID: <3F2A1CE0.8809F987@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Erik Gullerud CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <3F2936E6.E8F46012@cisco.com> <1059668206.39692.547.camel@callisto.noc.catch.no> <3F294216.65FD655B@cisco.com> <2b369a$v07j8@sj-iport-3.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 09:55:12 +0200 Content-Transfer-Encoding: 7bit Lars, Agree with your comment. So while putting aside the debate if evlution of BGP4 into BGP5 makes sens or not could we focus on actually listing problems in BGP4 by name which are giving you the impresion that "BGP has certain inherent properties that does NOT make them fully modular." No - I am not saying that BGP4 is perfect as is today - but I am trying to get some constrictive feedback for us vendors to make sure that the areas we need to improve in BGP4 are in line with what you folks are struggling the most with while running daily operation. We have first one: 1. Separate BGP sessions for each AFI/SAFI require "trashing" IGP with new addresses (IBGP) or multiple interfaces (EBGP) cases. Thx ! R. > Lars Erik Gullerud wrote: > > Of course you can use multiple sessions and build separate meshes, and > for a lot of cases, this is in fact already the common way to do it. But > that hardly scales ad infinitum, and in fact causes even more > administrative hassles than if each service was carried in it's own > completely separate protocol, as you now also need N addresses set up on > each host to support N services in individual sessions. > > My point was that while you say that "that is what making each AFI/SAFI > fully modular is all about", BGP has certain inherent properties that > does NOT make them fully modular. If you really want BGP to be the > generalized "stuff distribution protocol", then the protocol needs even > more changes to generalize it to this level. Whether making a "BGP5" > with these kinds of changes is the way to go or to create a brand new > "stuff distribution protocol" is something I don't really have an > opinion on - I just don't think BGP as we know it today is the answer. > > I'll just restate my earlier comment - it's about isolating each service > so any failure will impact as small a portion of the customers as > possible. And as the complexity increases, and the chances for failure > with it, this becomes even more important. > > /leg > > On Thu, 2003-07-31 at 18:21, Robert Raszuk wrote: > > Lars, > > > > There is nothing which would prohibit anyone today from using a > > dedicated BGP session for each AF mesh. So all probles you are > > describing are very valid, but can be already addressed today by few > > extra config lines. > > > > Further from TCP point of view adding another protocol or using multiple > > sessions for existing one is the same thing. > > > > R. > > > > > Lars Erik Gullerud wrote: > > > > > > On Thu, 2003-07-31 at 17:33, Robert Raszuk wrote: > > > > > > > Reg the sandwitch analogy ... > > > > > > > > Two (or N) smaller sandwitches could be easily done by cutting the 1 > > > > meter (sorry 3 feet) long one into pieces (read modules) before > > > > consumption. That is exactly what making each new AFI/SAFI fully modular > > > > is all about. Notice also that once cutted it is packed in individual > > > > bags for distribution (each AFI/SAFI uses a separate update msg). > > > > > > One problem as I see it right now though, is that if the contents of one > > > of those bags isn't satisfactory (i.e. an update message is invalid), > > > you throw the whole loaf of bread away (i.e. peer sends notification > > > message and tears down the BGP session). And as more and more different > > > sandwiches have to be made, the chances increase that a sloppy chef > > > mistakenly puts ham on one of them instead of salami, so this is a real > > > concern. > > > > > > But since we are starting to stretch this sandwich analogy, let's go > > > back to cleartext - I have had the "pleasure" of observing the effects > > > on a network where buggy router code from vendor X generated bad update > > > messages for one AFI (in this case, vpnv4) and BGP sessions started > > > dropping all over the place. Which then ended up affecting a > > > substantially bigger portion of the customer mass than if only the VPN > > > service had gone down. Without going into details, let's just say the > > > guys in suits were not too happy, and the guys in jeans were sweating > > > heavily that day. > > > > > > I'm not saying a separate protocol for every service is the preferred > > > way to go, but from an operators POV, a "soft" failure of one service > > > should ideally not affect all the other services being provided on the > > > same infrastructure, but rather contain the failure to that particular > > > service. Exactly how that is achieved however, is something we Ops guys > > > usually prefer to leave as an exercise to the people we pay obscene > > > amounts of money for those giant paperweights we stuff into our 19" > > > racks. > > > > > > /leg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 04:22:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02469 for ; Fri, 1 Aug 2003 04:22:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVAm-0006z6-RV; Fri, 01 Aug 2003 04:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVAW-0006yo-1e for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 04:21:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02461 for ; Fri, 1 Aug 2003 04:21:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iVAT-0003Q1-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 04:21:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iVAS-0003Py-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 04:21:40 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iVAT-000Dbd-7t for routing-discussion@ietf.org; Fri, 01 Aug 2003 08:21:41 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <182700830751.20030801012053@psg.com> To: Routing Discussion Subject: RP overloading: Next Steps MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 01:20:53 -0700 Content-Transfer-Encoding: 7bit Folks- Below is my suggestion on how we move forward, as well as a reply to the messages from Russ and Robert. Comments are welcome. 1. Define routing-related and non-routing related information and guidelines for acceptance of RP extensions. Since we already had a discussion on this topic on the rtg-dir, I would suggest that we ask the rtg-dir to come up with the draft on this topic and then discuss it here. 2. Document concerns/considerations on overloading RPs with non-routing related information. dmm et al seem to be working on this part already. I suggest we formalize this as a design team and ask them to come back to this list with the document for further discussion. 3. Document "meanwhile recommendations" for MP-BGP While we are discussing alternative distribution mechanisms, we may want document the considerations that we believe are important to know to deal with the stuff in the pipe already. It seems it should be possible to come up with an architecture-level document operating in terms defined within the BGP spec, not getting into the code-level details, and yet providing a list of requirements/recommendations that MP-BGP implementations should support. 4. Start exploring the alternative space There is a considerable part of the community who believe that overloading MP-BGP is not the right thing in the long run. This was clear at the meeting, and is clear on this list too. While not all of us may agree with this, ignoring this would be plain wrong, I believe. I also believe that until we have some documented understanding of the functional requirements and design considerations for the alternative, the situation will not change and all our discussions will remain purely theoretical. Writing requirement and framework documents is not a pleasant exercise, but it seems that in this case we need something all of us can read and discuss. In fact, I think Eric's posting to the list could be a good start. What I think we should do is form a design team that would group people who believe that we DO need an alternative to MP-BGP for non-routing info distribution and know what functions it should perform. This team would then be asked to come up with these two documents, that would be discussed on this list and in Minneapolis (we would either bring it to the open RTG area meeting, or have a BOF for this topic explicitly.) Comments to the messages inline below. Russ White wrote : > My general take: It might be nice to have a new protocol to carry stuff > around between routers in. Especially if that stuff doesn't relate to > routing. My questions, though, are: > > -- How long will it wait to develop, deploy, and debug, the stuff protocol? we don't know > -- Will the providers stop asking for new features that require carrying > non routing information between routers until the stuff protocol is fully > deployed? of course not > I think the answers to these two questions make it apparent that > might be useful to create such a stuff protocol, but we need to > think realisitically about: > > -- What do we mean by "non routing stuff?" we need an agree upon definition of routing-related stuff. everything else would be non-routing. > -- What are we going to do with "non routing stuff" in the meantime? I see the following possible options for a given app: a. an app-specific protocol is designed--might very well be the case for some apps b. we keep putting it on MP-BGP as we've been doing till now c. we put it on MP-BGP with a different TCP port number, assigned specifically for non-routing apps--this should encourage separation at least at the transport level > -- What do we do when some mission critical app rolls out on the stuff > protocol, and people start calling for us not to change it any more, since > it will introduce stuff instability, and thus we need a "stuff 2" protocol > to break out the "new stuff" from the "old stuff?" I wouldn't think so. If folk don't feel comfortable putting some critical app on the "stuff" transport, a separate protocol for that app seems like the right choice. > -- Should, if we do a stuff protocol, go back and rip the "nonrouting > stuff" out of BGP, if we can actually determine what that is, and put it in > the stuff protocol? I personally don't think so, but I could see how some people would want this to happen. Robert Raszuk said: > IMHO the best thing that can be done today by RTG directorate/ADs/IETF > is to mandate the clear separation of so called "non-routing" > information being distributed into their own AFI/SAFIs. That for one > will long term provide easy migration into a new transport (when such is > available & deployed) as well kind of "force" better software > engineering and code architecture. To make sure I understand this correctly, do you mean that the recommendation should be to introduce a new AFI/SAFI for each new app, as opposed to overload NLRI and attributes for existing AFI/SAFIs? > It could be said that it is recommended by each implementation to have > such a new AFI/SAFIs separated into their own RIBs, their own > maintenance & operation routines given AFI/SAFI specific and be > demultiplexed by general BGP inbound process based on the AFI/SAFI > values very early. I guess I can see two parts here: a) a better description of the protocol model (including RIBs) that can be added to the updated MP-BGP spec, and b) implementation recommendations generally, this is the field that we don't want to step in, but if there's a strong agreement that this is the right thing to do, the topic is important enough to make an exception > Looking realistically otherwise what we will see soon would an explosion > of extended/flexible communities or new attribiutes use under current > AFI/SAFIs which may in fact have very negative impact on current > Internet stability. Thanks. Alex Zinin _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 04:22:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02468 for ; Fri, 1 Aug 2003 04:22:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVBF-00070I-3V for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 04:22:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h718MSNb026918 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 04:22:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVAm-0006z6-RV; Fri, 01 Aug 2003 04:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVAW-0006yo-1e for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 04:21:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02461 for ; Fri, 1 Aug 2003 04:21:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iVAT-0003Q1-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 04:21:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iVAS-0003Py-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 04:21:40 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iVAT-000Dbd-7t for routing-discussion@ietf.org; Fri, 01 Aug 2003 08:21:41 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <182700830751.20030801012053@psg.com> To: Routing Discussion Subject: RP overloading: Next Steps MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 01:20:53 -0700 Content-Transfer-Encoding: 7bit Folks- Below is my suggestion on how we move forward, as well as a reply to the messages from Russ and Robert. Comments are welcome. 1. Define routing-related and non-routing related information and guidelines for acceptance of RP extensions. Since we already had a discussion on this topic on the rtg-dir, I would suggest that we ask the rtg-dir to come up with the draft on this topic and then discuss it here. 2. Document concerns/considerations on overloading RPs with non-routing related information. dmm et al seem to be working on this part already. I suggest we formalize this as a design team and ask them to come back to this list with the document for further discussion. 3. Document "meanwhile recommendations" for MP-BGP While we are discussing alternative distribution mechanisms, we may want document the considerations that we believe are important to know to deal with the stuff in the pipe already. It seems it should be possible to come up with an architecture-level document operating in terms defined within the BGP spec, not getting into the code-level details, and yet providing a list of requirements/recommendations that MP-BGP implementations should support. 4. Start exploring the alternative space There is a considerable part of the community who believe that overloading MP-BGP is not the right thing in the long run. This was clear at the meeting, and is clear on this list too. While not all of us may agree with this, ignoring this would be plain wrong, I believe. I also believe that until we have some documented understanding of the functional requirements and design considerations for the alternative, the situation will not change and all our discussions will remain purely theoretical. Writing requirement and framework documents is not a pleasant exercise, but it seems that in this case we need something all of us can read and discuss. In fact, I think Eric's posting to the list could be a good start. What I think we should do is form a design team that would group people who believe that we DO need an alternative to MP-BGP for non-routing info distribution and know what functions it should perform. This team would then be asked to come up with these two documents, that would be discussed on this list and in Minneapolis (we would either bring it to the open RTG area meeting, or have a BOF for this topic explicitly.) Comments to the messages inline below. Russ White wrote : > My general take: It might be nice to have a new protocol to carry stuff > around between routers in. Especially if that stuff doesn't relate to > routing. My questions, though, are: > > -- How long will it wait to develop, deploy, and debug, the stuff protocol? we don't know > -- Will the providers stop asking for new features that require carrying > non routing information between routers until the stuff protocol is fully > deployed? of course not > I think the answers to these two questions make it apparent that > might be useful to create such a stuff protocol, but we need to > think realisitically about: > > -- What do we mean by "non routing stuff?" we need an agree upon definition of routing-related stuff. everything else would be non-routing. > -- What are we going to do with "non routing stuff" in the meantime? I see the following possible options for a given app: a. an app-specific protocol is designed--might very well be the case for some apps b. we keep putting it on MP-BGP as we've been doing till now c. we put it on MP-BGP with a different TCP port number, assigned specifically for non-routing apps--this should encourage separation at least at the transport level > -- What do we do when some mission critical app rolls out on the stuff > protocol, and people start calling for us not to change it any more, since > it will introduce stuff instability, and thus we need a "stuff 2" protocol > to break out the "new stuff" from the "old stuff?" I wouldn't think so. If folk don't feel comfortable putting some critical app on the "stuff" transport, a separate protocol for that app seems like the right choice. > -- Should, if we do a stuff protocol, go back and rip the "nonrouting > stuff" out of BGP, if we can actually determine what that is, and put it in > the stuff protocol? I personally don't think so, but I could see how some people would want this to happen. Robert Raszuk said: > IMHO the best thing that can be done today by RTG directorate/ADs/IETF > is to mandate the clear separation of so called "non-routing" > information being distributed into their own AFI/SAFIs. That for one > will long term provide easy migration into a new transport (when such is > available & deployed) as well kind of "force" better software > engineering and code architecture. To make sure I understand this correctly, do you mean that the recommendation should be to introduce a new AFI/SAFI for each new app, as opposed to overload NLRI and attributes for existing AFI/SAFIs? > It could be said that it is recommended by each implementation to have > such a new AFI/SAFIs separated into their own RIBs, their own > maintenance & operation routines given AFI/SAFI specific and be > demultiplexed by general BGP inbound process based on the AFI/SAFI > values very early. I guess I can see two parts here: a) a better description of the protocol model (including RIBs) that can be added to the updated MP-BGP spec, and b) implementation recommendations generally, this is the field that we don't want to step in, but if there's a strong agreement that this is the right thing to do, the topic is important enough to make an exception > Looking realistically otherwise what we will see soon would an explosion > of extended/flexible communities or new attribiutes use under current > AFI/SAFIs which may in fact have very negative impact on current > Internet stability. Thanks. Alex Zinin _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 04:44:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02131 for ; Fri, 1 Aug 2003 03:56:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUlz-0005tV-6D for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 03:56:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h717uN2S022657 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 03:56:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUld-0005pr-EX; Fri, 01 Aug 2003 03:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iUlT-0005pZ-AC for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 03:55:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02119 for ; Fri, 1 Aug 2003 03:55:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iUlQ-0003J4-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 03:55:48 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19iUlQ-0003J1-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 03:55:48 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h717tGpp001115; Fri, 1 Aug 2003 00:55:17 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJW30060; Fri, 1 Aug 2003 00:49:58 -0700 (PDT) Message-ID: <3F2A1CE0.8809F987@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Erik Gullerud CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <3F2936E6.E8F46012@cisco.com> <1059668206.39692.547.camel@callisto.noc.catch.no> <3F294216.65FD655B@cisco.com> <2b369a$v07j8@sj-iport-3.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 09:55:12 +0200 Content-Transfer-Encoding: 7bit Lars, Agree with your comment. So while putting aside the debate if evlution of BGP4 into BGP5 makes sens or not could we focus on actually listing problems in BGP4 by name which are giving you the impresion that "BGP has certain inherent properties that does NOT make them fully modular." No - I am not saying that BGP4 is perfect as is today - but I am trying to get some constrictive feedback for us vendors to make sure that the areas we need to improve in BGP4 are in line with what you folks are struggling the most with while running daily operation. We have first one: 1. Separate BGP sessions for each AFI/SAFI require "trashing" IGP with new addresses (IBGP) or multiple interfaces (EBGP) cases. Thx ! R. > Lars Erik Gullerud wrote: > > Of course you can use multiple sessions and build separate meshes, and > for a lot of cases, this is in fact already the common way to do it. But > that hardly scales ad infinitum, and in fact causes even more > administrative hassles than if each service was carried in it's own > completely separate protocol, as you now also need N addresses set up on > each host to support N services in individual sessions. > > My point was that while you say that "that is what making each AFI/SAFI > fully modular is all about", BGP has certain inherent properties that > does NOT make them fully modular. If you really want BGP to be the > generalized "stuff distribution protocol", then the protocol needs even > more changes to generalize it to this level. Whether making a "BGP5" > with these kinds of changes is the way to go or to create a brand new > "stuff distribution protocol" is something I don't really have an > opinion on - I just don't think BGP as we know it today is the answer. > > I'll just restate my earlier comment - it's about isolating each service > so any failure will impact as small a portion of the customers as > possible. And as the complexity increases, and the chances for failure > with it, this becomes even more important. > > /leg > > On Thu, 2003-07-31 at 18:21, Robert Raszuk wrote: > > Lars, > > > > There is nothing which would prohibit anyone today from using a > > dedicated BGP session for each AF mesh. So all probles you are > > describing are very valid, but can be already addressed today by few > > extra config lines. > > > > Further from TCP point of view adding another protocol or using multiple > > sessions for existing one is the same thing. > > > > R. > > > > > Lars Erik Gullerud wrote: > > > > > > On Thu, 2003-07-31 at 17:33, Robert Raszuk wrote: > > > > > > > Reg the sandwitch analogy ... > > > > > > > > Two (or N) smaller sandwitches could be easily done by cutting the 1 > > > > meter (sorry 3 feet) long one into pieces (read modules) before > > > > consumption. That is exactly what making each new AFI/SAFI fully modular > > > > is all about. Notice also that once cutted it is packed in individual > > > > bags for distribution (each AFI/SAFI uses a separate update msg). > > > > > > One problem as I see it right now though, is that if the contents of one > > > of those bags isn't satisfactory (i.e. an update message is invalid), > > > you throw the whole loaf of bread away (i.e. peer sends notification > > > message and tears down the BGP session). And as more and more different > > > sandwiches have to be made, the chances increase that a sloppy chef > > > mistakenly puts ham on one of them instead of salami, so this is a real > > > concern. > > > > > > But since we are starting to stretch this sandwich analogy, let's go > > > back to cleartext - I have had the "pleasure" of observing the effects > > > on a network where buggy router code from vendor X generated bad update > > > messages for one AFI (in this case, vpnv4) and BGP sessions started > > > dropping all over the place. Which then ended up affecting a > > > substantially bigger portion of the customer mass than if only the VPN > > > service had gone down. Without going into details, let's just say the > > > guys in suits were not too happy, and the guys in jeans were sweating > > > heavily that day. > > > > > > I'm not saying a separate protocol for every service is the preferred > > > way to go, but from an operators POV, a "soft" failure of one service > > > should ideally not affect all the other services being provided on the > > > same infrastructure, but rather contain the failure to that particular > > > service. Exactly how that is achieved however, is something we Ops guys > > > usually prefer to leave as an exercise to the people we pay obscene > > > amounts of money for those giant paperweights we stuff into our 19" > > > racks. > > > > > > /leg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 09:57:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20760 for ; Fri, 1 Aug 2003 09:57:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iaP0-0004SP-Dp; Fri, 01 Aug 2003 09:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iaO0-0004Ji-UN for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 09:56:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20373 for ; Fri, 1 Aug 2003 09:55:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iaAh-0002E3-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 09:42:15 -0400 Received: from web11409.mail.yahoo.com ([216.136.131.220]) by ietf-mx with smtp (Exim 4.12) id 19iaAg-0002E0-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 09:42:14 -0400 Message-ID: <20030801134212.63250.qmail@web11409.mail.yahoo.com> Received: from [65.194.140.2] by web11409.mail.yahoo.com via HTTP; Fri, 01 Aug 2003 06:42:12 PDT From: Sanjay Wadhwa Subject: RE: Open Routing Area meeting in Vienna To: routing-discussion@ietf.org Cc: raszuk@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 06:42:12 -0700 (PDT) > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Robert Raszuk > Sent: Friday, August 01, 2003 3:55 AM > To: Lars Erik Gullerud > Cc: routing-discussion@ietf.org > Subject: Re: Open Routing Area meeting in Vienna > ...snip > > We have first one: > > 1. Separate BGP sessions for each AFI/SAFI require "trashing" IGP with > new addresses (IBGP) or multiple interfaces (EBGP) cases. > > Thx ! > R. > This requirement holds true today. However, different bgp sessions to the same peer address for different services (AFI/SAFI) is also possible by defining seperate well known tcp port per service. -Sanjay __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 10:46:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20763 for ; Fri, 1 Aug 2003 09:57:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iaPH-0004V5-PI for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 09:57:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71DvJ9K017290 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 09:57:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iaP0-0004SP-Dp; Fri, 01 Aug 2003 09:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iaO0-0004Ji-UN for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 09:56:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20373 for ; Fri, 1 Aug 2003 09:55:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iaAh-0002E3-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 09:42:15 -0400 Received: from web11409.mail.yahoo.com ([216.136.131.220]) by ietf-mx with smtp (Exim 4.12) id 19iaAg-0002E0-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 09:42:14 -0400 Message-ID: <20030801134212.63250.qmail@web11409.mail.yahoo.com> Received: from [65.194.140.2] by web11409.mail.yahoo.com via HTTP; Fri, 01 Aug 2003 06:42:12 PDT From: Sanjay Wadhwa Subject: RE: Open Routing Area meeting in Vienna To: routing-discussion@ietf.org Cc: raszuk@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 06:42:12 -0700 (PDT) > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Robert Raszuk > Sent: Friday, August 01, 2003 3:55 AM > To: Lars Erik Gullerud > Cc: routing-discussion@ietf.org > Subject: Re: Open Routing Area meeting in Vienna > ...snip > > We have first one: > > 1. Separate BGP sessions for each AFI/SAFI require "trashing" IGP with > new addresses (IBGP) or multiple interfaces (EBGP) cases. > > Thx ! > R. > This requirement holds true today. However, different bgp sessions to the same peer address for different services (AFI/SAFI) is also possible by defining seperate well known tcp port per service. -Sanjay __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 11:50:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27161 for ; Fri, 1 Aug 2003 11:50:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19icAL-0008NV-PO; Fri, 01 Aug 2003 11:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19icAB-0008Mu-32 for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 11:49:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27139; Fri, 1 Aug 2003 11:49:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19icA9-0003U5-00; Fri, 01 Aug 2003 11:49:49 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19icA8-0003U1-00; Fri, 01 Aug 2003 11:49:48 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h71FndRp013714; Fri, 1 Aug 2003 11:49:42 -0400 Message-Id: <200308011549.h71FndRp013714@mailhost.avici.com> To: raszuk@cisco.com cc: Routing Discussion , L3VPN Reply-To: curtis@fictitious.org Subject: Re: Sequence control of distributed information In-reply-to: Your message of "Thu, 31 Jul 2003 19:11:03 +0200." <3F294DA7.C44114F9@cisco.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 11:49:37 -0400 In message <3F294DA7.C44114F9@cisco.com>, Robert Raszuk writes: > > Let me try to probe operators about one element which may become much > harder to achive when moving some data out of BGP umbrella. Under a > numerous conversations I have heard requests asking for allowing > operator to tightly control the order of information being distributed > by BGP for example: vpnv4 routes first then ipv4 routes or ipv4 routes > first followed by mutlicast routes etc ... > > When all AFs are under the same BGP umbrella that request can be very > easy to deliver with a simple knob. When we separate future - non > routing data - I could easily see the case that +100K ipv4 routes is > competing with +100K telefon numbers to be send between routers. There > would be no easy way to allow priority control other then low level CPU > resources allocations to each process. Even that it would be usually > difficult to achive full task serialization on a more granular level > that fully blocking given's process resources. That will in turn result > in explosion of separate processes almost per task and managment of > those will for sure provide very stable platforms :). > > Bottom line - the question is - do we all agree that the only required > mode of operation is fairness in distribution of all kinds of > information between routers ? > > Cheers, > R. Some implementations are smart enough to prioritize packing IGP routes into BGP updates (when redistributed to EBGP) and provide other heuristics for updating "more important" information first. Installing IGP routes in the hardware first is probably universal among successful routers. It would be a simple enough matter to pack BGP updates full of IPv4 routes before other information or to provide internal scheduling whether that other information was within BGP or in another protocol. Fairness in distribution of all kinds of information does not currently exist. It is not a goal. Control over the allocation of resources by protocol and/or data type might be a goal in the future, but being fair might not be the outcome. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 12:36:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27163 for ; Fri, 1 Aug 2003 11:50:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19icAY-0008Oi-Su for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 11:50:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71FoEvH032276 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 11:50:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19icAL-0008NV-PO; Fri, 01 Aug 2003 11:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19icAB-0008Mu-32 for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 11:49:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27139; Fri, 1 Aug 2003 11:49:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19icA9-0003U5-00; Fri, 01 Aug 2003 11:49:49 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19icA8-0003U1-00; Fri, 01 Aug 2003 11:49:48 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h71FndRp013714; Fri, 1 Aug 2003 11:49:42 -0400 Message-Id: <200308011549.h71FndRp013714@mailhost.avici.com> To: raszuk@cisco.com cc: Routing Discussion , L3VPN Reply-To: curtis@fictitious.org Subject: Re: Sequence control of distributed information In-reply-to: Your message of "Thu, 31 Jul 2003 19:11:03 +0200." <3F294DA7.C44114F9@cisco.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 11:49:37 -0400 In message <3F294DA7.C44114F9@cisco.com>, Robert Raszuk writes: > > Let me try to probe operators about one element which may become much > harder to achive when moving some data out of BGP umbrella. Under a > numerous conversations I have heard requests asking for allowing > operator to tightly control the order of information being distributed > by BGP for example: vpnv4 routes first then ipv4 routes or ipv4 routes > first followed by mutlicast routes etc ... > > When all AFs are under the same BGP umbrella that request can be very > easy to deliver with a simple knob. When we separate future - non > routing data - I could easily see the case that +100K ipv4 routes is > competing with +100K telefon numbers to be send between routers. There > would be no easy way to allow priority control other then low level CPU > resources allocations to each process. Even that it would be usually > difficult to achive full task serialization on a more granular level > that fully blocking given's process resources. That will in turn result > in explosion of separate processes almost per task and managment of > those will for sure provide very stable platforms :). > > Bottom line - the question is - do we all agree that the only required > mode of operation is fairness in distribution of all kinds of > information between routers ? > > Cheers, > R. Some implementations are smart enough to prioritize packing IGP routes into BGP updates (when redistributed to EBGP) and provide other heuristics for updating "more important" information first. Installing IGP routes in the hardware first is probably universal among successful routers. It would be a simple enough matter to pack BGP updates full of IPv4 routes before other information or to provide internal scheduling whether that other information was within BGP or in another protocol. Fairness in distribution of all kinds of information does not currently exist. It is not a goal. Control over the allocation of resources by protocol and/or data type might be a goal in the future, but being fair might not be the outcome. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 13:01:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00138 for ; Fri, 1 Aug 2003 13:01:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idH4-0002Pl-NJ; Fri, 01 Aug 2003 13:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idGm-0002Ob-P1 for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 13:00:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00110 for ; Fri, 1 Aug 2003 13:00:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19idGk-0004Av-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:00:43 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19idGk-0004Al-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:00:42 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 01 Aug 2003 10:00:11 -0700 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h71H07Xw010777; Fri, 1 Aug 2003 13:00:07 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn1-570.cisco.com [10.82.226.58]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA19723; Fri, 1 Aug 2003 13:00:07 -0400 (EDT) From: Russ White Reply-To: Russ White To: Danny McPherson cc: routing-discussion@ietf.org Subject: Re: The Natural Entropy of the Internet? In-Reply-To: <08B07F65-C3E4-11D7-BD2D-000393D54EA6@tcb.net> Message-ID: References: <08B07F65-C3E4-11D7-BD2D-000393D54EA6@tcb.net> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 13:00:12 -0400 (Eastern Daylight Time) > > Having this new stuff separate from the production stuff is good > > and the more separate the better. > > And this is where the problem arises. "the more separate the better" > perhaps holds true when simply considering complexity increase of a > system, but what about *other* pragmatic factors such as competitiveness, > economies or commercial market forces? And another point that's rather interesting in this context, that I've brought up before: Once this new "protocol" stablizes, and becomes part of the "production network," then you will not want new features in it, right? Or do we develop two protocols, one for "new stuff," once the "new stuff" is stable, and "in production," then we move it from the "expermiental" protocol to the "stable" protocol? Or do we invent a new distribution mechanism for each new "thing" we want to roll out? Or is there some middle ground, that we can say when you get over x number of applications, you create a new protocol, or.... (?) There has to be a long term plan, not a single "oh, let's fix BGP, and move on to some other problems," since we're really just talking about raising the same issues with "son of BGP" in a couple of years. I've not seen this question answered yet--how do you address this? Either we state that for architectural purity, each new application should come with it's own protocol, or we accept that we are going to have one "overloaded" protocol, which carries things which are experimental and things which are not experimental. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 13:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00187 for ; Fri, 1 Aug 2003 13:02:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idI1-0002VM-EK; Fri, 01 Aug 2003 13:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idHz-0002V5-Ru for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 13:01:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00172 for ; Fri, 1 Aug 2003 13:01:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19idHy-0004BF-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:01:58 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19idHx-0004BA-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:01:57 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 01 Aug 2003 10:04:50 -0700 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h71H1Oxc022402; Fri, 1 Aug 2003 13:01:24 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn1-570.cisco.com [10.82.226.58]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA19834; Fri, 1 Aug 2003 13:01:09 -0400 (EDT) From: Russ White Reply-To: Russ White To: Mark Prior cc: Danny McPherson , routing-discussion@ietf.org Subject: Re: The Natural Entropy of the Internet? In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 13:01:14 -0400 (Eastern Daylight Time) And further, more seperated is _not_ always better. Based on the laws of statistics, there is a balance point between the two. 10 T1's may _feel_ more reliable than a single OC3, but they really aren't. :-) Russ On Fri, 1 Aug 2003, Mark Prior wrote: > On 1/8/03 3:20 PM, "Danny McPherson" wrote: > > > > > On Thursday, July 31, 2003, at 07:57 PM, Mark Prior wrote: > > > >> Having this new stuff separate from the production stuff is good > >> and the more separate the better. > > > > And this is where the problem arises. "the more separate the > > better" perhaps holds true when simply considering complexity > > increase of a system, but what about *other* pragmatic factors > > such as competitiveness, economies or commercial market > > forces? > > > I agree there is a practical limit where extending the division makes no > sense as these things need to operate on the same underlying infrastructure > but having a mechanism that keeps them from affecting each other within the > routing hardware would be a good thing. Having some new feature take out my > production BGP process would be a bad thing. Worst still if it required a > reboot into another version of the operating system to get a version of that > process that didn't continually crash. > > Mark. > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 13:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00191 for ; Fri, 1 Aug 2003 13:02:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idI1-0002WH-T1 for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 13:02:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71H21bC009678 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 13:02:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idI1-0002VM-EK; Fri, 01 Aug 2003 13:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idHz-0002V5-Ru for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 13:01:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00172 for ; Fri, 1 Aug 2003 13:01:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19idHy-0004BF-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:01:58 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19idHx-0004BA-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:01:57 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 01 Aug 2003 10:04:50 -0700 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h71H1Oxc022402; Fri, 1 Aug 2003 13:01:24 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn1-570.cisco.com [10.82.226.58]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA19834; Fri, 1 Aug 2003 13:01:09 -0400 (EDT) From: Russ White Reply-To: Russ White To: Mark Prior cc: Danny McPherson , routing-discussion@ietf.org Subject: Re: The Natural Entropy of the Internet? In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 13:01:14 -0400 (Eastern Daylight Time) And further, more seperated is _not_ always better. Based on the laws of statistics, there is a balance point between the two. 10 T1's may _feel_ more reliable than a single OC3, but they really aren't. :-) Russ On Fri, 1 Aug 2003, Mark Prior wrote: > On 1/8/03 3:20 PM, "Danny McPherson" wrote: > > > > > On Thursday, July 31, 2003, at 07:57 PM, Mark Prior wrote: > > > >> Having this new stuff separate from the production stuff is good > >> and the more separate the better. > > > > And this is where the problem arises. "the more separate the > > better" perhaps holds true when simply considering complexity > > increase of a system, but what about *other* pragmatic factors > > such as competitiveness, economies or commercial market > > forces? > > > I agree there is a practical limit where extending the division makes no > sense as these things need to operate on the same underlying infrastructure > but having a mechanism that keeps them from affecting each other within the > routing hardware would be a good thing. Having some new feature take out my > production BGP process would be a bad thing. Worst still if it required a > reboot into another version of the operating system to get a version of that > process that didn't continually crash. > > Mark. > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 13:04:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00287 for ; Fri, 1 Aug 2003 13:04:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idJx-0002fo-E1; Fri, 01 Aug 2003 13:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idJB-0002ez-M6 for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 13:03:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00241 for ; Fri, 1 Aug 2003 13:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19idJ9-0004CA-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:03:11 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19idJ9-0004Bo-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:03:11 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h71H2bXw011224; Fri, 1 Aug 2003 13:02:38 -0400 (EDT) Message-Id: <200308011702.h71H2bXw011224@rtp-core-1.cisco.com> To: Lars Erik Gullerud cc: raszuk@cisco.com, routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of 01 Aug 2003 09:00:07 +0200. <1059721207.42058.12.camel@callisto.noc.catch.no> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 13:02:36 -0400 Lars> causes even more administrative hassles than if each service was Lars> carried in it's own completely separate protocol, as you now also need Lars> N addresses set up on each host to support N services in individual Lars> sessions. If we were to decide that we should have multiple BGP instances on a node, then using a different port number for each would seem to be more sensible than using a different address for each. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 13:04:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00294 for ; Fri, 1 Aug 2003 13:04:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idJy-0002hO-LU for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 13:04:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71H42AG010345 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 13:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idJx-0002fo-E1; Fri, 01 Aug 2003 13:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idJB-0002ez-M6 for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 13:03:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00241 for ; Fri, 1 Aug 2003 13:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19idJ9-0004CA-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:03:11 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19idJ9-0004Bo-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:03:11 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h71H2bXw011224; Fri, 1 Aug 2003 13:02:38 -0400 (EDT) Message-Id: <200308011702.h71H2bXw011224@rtp-core-1.cisco.com> To: Lars Erik Gullerud cc: raszuk@cisco.com, routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of 01 Aug 2003 09:00:07 +0200. <1059721207.42058.12.camel@callisto.noc.catch.no> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 13:02:36 -0400 Lars> causes even more administrative hassles than if each service was Lars> carried in it's own completely separate protocol, as you now also need Lars> N addresses set up on each host to support N services in individual Lars> sessions. If we were to decide that we should have multiple BGP instances on a node, then using a different port number for each would seem to be more sensible than using a different address for each. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 13:09:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00403 for ; Fri, 1 Aug 2003 13:09:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idOm-00036r-OW; Fri, 01 Aug 2003 13:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idOK-00036N-00 for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 13:08:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00383 for ; Fri, 1 Aug 2003 13:08:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19idOI-0004EN-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:08:30 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19idOH-0004EI-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:08:29 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 01 Aug 2003 10:07:59 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h71H7txc023043; Fri, 1 Aug 2003 13:07:56 -0400 (EDT) Message-Id: <200308011707.h71H7txc023043@rtp-core-2.cisco.com> To: Lars Erik Gullerud cc: raszuk@cisco.com, Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of 31 Jul 2003 18:16:46 +0200. <1059668206.39692.547.camel@callisto.noc.catch.no> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 13:07:55 -0400 Lars> One problem as I see it right now though, is that if the contents of Lars> one of those bags isn't satisfactory (i.e. an update message is Lars> invalid), you throw the whole loaf of bread away (i.e. peer sends Lars> notification message and tears down the BGP session). This point is well taken. But don't you think that whatever happens here, this should be fixed in BGP? Even if BGP just carried the IPv4 and IPv6 address families, you might not want an error in one to take down the whole session. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 13:09:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00410 for ; Fri, 1 Aug 2003 13:09:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idOn-000386-KC for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 13:09:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71H91gF012007 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 13:09:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idOm-00036r-OW; Fri, 01 Aug 2003 13:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idOK-00036N-00 for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 13:08:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00383 for ; Fri, 1 Aug 2003 13:08:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19idOI-0004EN-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:08:30 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19idOH-0004EI-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:08:29 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 01 Aug 2003 10:07:59 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h71H7txc023043; Fri, 1 Aug 2003 13:07:56 -0400 (EDT) Message-Id: <200308011707.h71H7txc023043@rtp-core-2.cisco.com> To: Lars Erik Gullerud cc: raszuk@cisco.com, Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of 31 Jul 2003 18:16:46 +0200. <1059668206.39692.547.camel@callisto.noc.catch.no> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 13:07:55 -0400 Lars> One problem as I see it right now though, is that if the contents of Lars> one of those bags isn't satisfactory (i.e. an update message is Lars> invalid), you throw the whole loaf of bread away (i.e. peer sends Lars> notification message and tears down the BGP session). This point is well taken. But don't you think that whatever happens here, this should be fixed in BGP? Even if BGP just carried the IPv4 and IPv6 address families, you might not want an error in one to take down the whole session. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 13:32:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01210 for ; Fri, 1 Aug 2003 13:32:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idl3-0003qc-6C; Fri, 01 Aug 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idkA-0003pt-Lg for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 13:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01156 for ; Fri, 1 Aug 2003 13:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19idk8-0004On-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:31:04 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19idk7-0004OV-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:31:03 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h71HV0Rp026692; Fri, 1 Aug 2003 13:31:00 -0400 Message-Id: <200308011731.h71HV0Rp026692@mailhost.avici.com> To: Scott W Brim cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Tue, 29 Jul 2003 18:39:49 EDT." <20030729183949.H2408@sbrim-w2k01> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 13:30:57 -0400 In message <20030729183949.H2408@sbrim-w2k01>, Scott W Brim writes: > How about we rename BGP, declare that we're done with the general > information distribution protocol, and work on a new routing protocol? We tried that with IDRP and got nowhere. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 13:51:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00139 for ; Fri, 1 Aug 2003 13:01:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idHI-0002Qp-9A for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 13:01:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71H1G0W009341 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 13:01:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idH4-0002Pl-NJ; Fri, 01 Aug 2003 13:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idGm-0002Ob-P1 for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 13:00:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00110 for ; Fri, 1 Aug 2003 13:00:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19idGk-0004Av-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:00:43 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19idGk-0004Al-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:00:42 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 01 Aug 2003 10:00:11 -0700 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h71H07Xw010777; Fri, 1 Aug 2003 13:00:07 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn1-570.cisco.com [10.82.226.58]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA19723; Fri, 1 Aug 2003 13:00:07 -0400 (EDT) From: Russ White Reply-To: Russ White To: Danny McPherson cc: routing-discussion@ietf.org Subject: Re: The Natural Entropy of the Internet? In-Reply-To: <08B07F65-C3E4-11D7-BD2D-000393D54EA6@tcb.net> Message-ID: References: <08B07F65-C3E4-11D7-BD2D-000393D54EA6@tcb.net> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 13:00:12 -0400 (Eastern Daylight Time) > > Having this new stuff separate from the production stuff is good > > and the more separate the better. > > And this is where the problem arises. "the more separate the better" > perhaps holds true when simply considering complexity increase of a > system, but what about *other* pragmatic factors such as competitiveness, > economies or commercial market forces? And another point that's rather interesting in this context, that I've brought up before: Once this new "protocol" stablizes, and becomes part of the "production network," then you will not want new features in it, right? Or do we develop two protocols, one for "new stuff," once the "new stuff" is stable, and "in production," then we move it from the "expermiental" protocol to the "stable" protocol? Or do we invent a new distribution mechanism for each new "thing" we want to roll out? Or is there some middle ground, that we can say when you get over x number of applications, you create a new protocol, or.... (?) There has to be a long term plan, not a single "oh, let's fix BGP, and move on to some other problems," since we're really just talking about raising the same issues with "son of BGP" in a couple of years. I've not seen this question answered yet--how do you address this? Either we state that for architectural purity, each new application should come with it's own protocol, or we accept that we are going to have one "overloaded" protocol, which carries things which are experimental and things which are not experimental. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 14:21:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01209 for ; Fri, 1 Aug 2003 13:32:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idlC-0003rx-3f for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 13:32:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71HWAu9014861 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 13:32:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idl3-0003qc-6C; Fri, 01 Aug 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19idkA-0003pt-Lg for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 13:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01156 for ; Fri, 1 Aug 2003 13:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19idk8-0004On-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:31:04 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19idk7-0004OV-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 13:31:03 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h71HV0Rp026692; Fri, 1 Aug 2003 13:31:00 -0400 Message-Id: <200308011731.h71HV0Rp026692@mailhost.avici.com> To: Scott W Brim cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Tue, 29 Jul 2003 18:39:49 EDT." <20030729183949.H2408@sbrim-w2k01> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 13:30:57 -0400 In message <20030729183949.H2408@sbrim-w2k01>, Scott W Brim writes: > How about we rename BGP, declare that we're done with the general > information distribution protocol, and work on a new routing protocol? We tried that with IDRP and got nowhere. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 14:34:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03462 for ; Fri, 1 Aug 2003 14:34:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iej3-0006V2-Ka; Fri, 01 Aug 2003 14:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieic-0006Uk-W4 for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 14:33:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03443 for ; Fri, 1 Aug 2003 14:33:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ieia-0004yR-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 14:33:32 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19ieiZ-0004yO-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 14:33:31 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h71IXHRp001918; Fri, 1 Aug 2003 14:33:19 -0400 Message-Id: <200308011833.h71IXHRp001918@mailhost.avici.com> To: Geoff Huston cc: erosen@cisco.com, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Thu, 31 Jul 2003 07:02:14 +1000." <5.1.0.14.2.20030731064951.01ebd3c0@kahuna.telstra.net> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 14:33:14 -0400 In message <5.1.0.14.2.20030731064951.01ebd3c0@kahuna.telstra.net>, Geoff Husto n writes: > At 04:40 PM 30/07/2003 -0400, Eric Rosen wrote: > > >Kurt> We all know that BGP doesn't scale > > > >Yes, that must be what prevented the Internet from ever getting very > >large. ;-) > > I suspect in this comment that Eric is skipping across some amazing efforts > by a small pool of folk to reign in some of the more extreme forms of > deployed routing abuse (no, I do not count my own small efforts in this pool > of individuals). Keeping the network vaguely stable at it's current size > is taking increasingly large amounts of manual effort, and no, this > cannot scale indefinitely. Is that an inter-provider coordination problem or a protocol problem? As I understand it BGP does support aggregation which reigns in the problem that is putting stress on scaling. Operators are only able to provide the simplest single site or single provider aggregation though the protocol can do better. A second (possibly greater) problem is inability to provide assurances of generous address renumbering grace periods (extending to near infinite if needed) has resulted in far more provider independent addresses being allocated than the impact of an infinite renumbering grace period would have ever produced. Those are inter-provider operational problems. As I also recall, there were efforts in the RPS WG to use the routing registry to coordinate aggregation across providers plus arguments for generous address renumbering grace periods from a subset of operators going back as far as 6-8 years ago. Therefore the BGP protocol scales. The operators are a bunch of screw ups, and the protocol can't fix that. :-) > There _are_ problems in BGP deployments, and overloading the running > instance of the protocol to carry more information related to various overlay > signalling applications does not in itself assist in improving the situation. > For me its a counter-intuitive action that increases the level of operational > reliance on a single element of the network. But as Randy and Kurt have > said this already there's no point in my repeating it. I wholeheartedly agree. Regardless of the cause, overloading BGP is likely to make the situation worse. That also doesn't have to happen, but the vendors are screw ups too and are unlikely to get the internal scheduling coded very well or not break anything making the changes. :-) > Geoff Either way (overloading BGP or a new protocol) is in theory viable, but people on this list have cited overloading BGP as too great a risk for a protocol that is critical to operation of the Internet. The idea of distributing multicast over BGP died almost a decade ago, yet VPN use of BGP survived and thrives. The difference may be that the 2546 use of BGP has been strictly single provider. Likewise, PW may prove to be strictly single provider in practice. IPV6 and telephony are not. While IPv6 may be able to start out with isolated islands of IPv6, it may be less likely that this will work for telephony and there may also be far more resistance to this. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 14:34:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03464 for ; Fri, 1 Aug 2003 14:34:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iejC-0006Vs-LK for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 14:34:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71IYA3n025035 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 14:34:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iej3-0006V2-Ka; Fri, 01 Aug 2003 14:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieic-0006Uk-W4 for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 14:33:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03443 for ; Fri, 1 Aug 2003 14:33:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ieia-0004yR-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 14:33:32 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19ieiZ-0004yO-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 14:33:31 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h71IXHRp001918; Fri, 1 Aug 2003 14:33:19 -0400 Message-Id: <200308011833.h71IXHRp001918@mailhost.avici.com> To: Geoff Huston cc: erosen@cisco.com, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Thu, 31 Jul 2003 07:02:14 +1000." <5.1.0.14.2.20030731064951.01ebd3c0@kahuna.telstra.net> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 14:33:14 -0400 In message <5.1.0.14.2.20030731064951.01ebd3c0@kahuna.telstra.net>, Geoff Husto n writes: > At 04:40 PM 30/07/2003 -0400, Eric Rosen wrote: > > >Kurt> We all know that BGP doesn't scale > > > >Yes, that must be what prevented the Internet from ever getting very > >large. ;-) > > I suspect in this comment that Eric is skipping across some amazing efforts > by a small pool of folk to reign in some of the more extreme forms of > deployed routing abuse (no, I do not count my own small efforts in this pool > of individuals). Keeping the network vaguely stable at it's current size > is taking increasingly large amounts of manual effort, and no, this > cannot scale indefinitely. Is that an inter-provider coordination problem or a protocol problem? As I understand it BGP does support aggregation which reigns in the problem that is putting stress on scaling. Operators are only able to provide the simplest single site or single provider aggregation though the protocol can do better. A second (possibly greater) problem is inability to provide assurances of generous address renumbering grace periods (extending to near infinite if needed) has resulted in far more provider independent addresses being allocated than the impact of an infinite renumbering grace period would have ever produced. Those are inter-provider operational problems. As I also recall, there were efforts in the RPS WG to use the routing registry to coordinate aggregation across providers plus arguments for generous address renumbering grace periods from a subset of operators going back as far as 6-8 years ago. Therefore the BGP protocol scales. The operators are a bunch of screw ups, and the protocol can't fix that. :-) > There _are_ problems in BGP deployments, and overloading the running > instance of the protocol to carry more information related to various overlay > signalling applications does not in itself assist in improving the situation. > For me its a counter-intuitive action that increases the level of operational > reliance on a single element of the network. But as Randy and Kurt have > said this already there's no point in my repeating it. I wholeheartedly agree. Regardless of the cause, overloading BGP is likely to make the situation worse. That also doesn't have to happen, but the vendors are screw ups too and are unlikely to get the internal scheduling coded very well or not break anything making the changes. :-) > Geoff Either way (overloading BGP or a new protocol) is in theory viable, but people on this list have cited overloading BGP as too great a risk for a protocol that is critical to operation of the Internet. The idea of distributing multicast over BGP died almost a decade ago, yet VPN use of BGP survived and thrives. The difference may be that the 2546 use of BGP has been strictly single provider. Likewise, PW may prove to be strictly single provider in practice. IPV6 and telephony are not. While IPv6 may be able to start out with isolated islands of IPv6, it may be less likely that this will work for telephony and there may also be far more resistance to this. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 14:41:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03755 for ; Fri, 1 Aug 2003 14:41:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iepq-00074t-8Z; Fri, 01 Aug 2003 14:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieoz-00073k-Qv for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 14:40:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03723 for ; Fri, 1 Aug 2003 14:40:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ieox-00052l-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 14:40:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ieow-00052a-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 14:40:06 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Aug 2003 11:39:38 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h71IdYLH008746; Fri, 1 Aug 2003 11:39:34 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA17113; Fri, 1 Aug 2003 14:39:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <200308011731.h71HV0Rp026692@mailhost.avici.com> References: <200308011731.h71HV0Rp026692@mailhost.avici.com> To: curtis@fictitious.org From: "John G. Scudder" Subject: Re: Open Routing Area meeting in Vienna Cc: routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 14:39:30 -0400 At 1:30 PM -0400 8/1/03, Curtis Villamizar wrote: >In message <20030729183949.H2408@sbrim-w2k01>, Scott W Brim writes: >> How about we rename BGP, declare that we're done with the general >> information distribution protocol, and work on a new routing protocol? > >We tried that with IDRP and got nowhere. Cute, but not really. IDRP is substantially different from BGP. But maybe you meant that we've tried taking BGP, "fixing" it on a whiteboard, and declaring victory. In which case I agree. --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 15:02:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04478 for ; Fri, 1 Aug 2003 15:02:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ifAM-0007uA-Iw for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 15:02:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71J2EEP030359 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 15:02:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ifA9-0007sl-Nx; Fri, 01 Aug 2003 15:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19if9P-0007sK-4Q for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 15:01:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04453 for ; Fri, 1 Aug 2003 15:01:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19if9K-0005C2-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 15:01:10 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19if9J-0005Bz-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 15:01:09 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h71J1gQk005507; Fri, 1 Aug 2003 15:01:43 -0400 Message-Id: <200308011901.h71J1gQk005507@mailhost.avici.com> To: Craig Labovitz cc: Jeff Parker , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Thu, 31 Jul 2003 11:24:45 EDT." <20030731112445.A23490@state.arbor.net> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 15:01:39 -0400 In message <20030731112445.A23490@state.arbor.net>, Craig Labovitz writes: > > > So, inter-domain BGP convergence is linear with respect to the length > of the longest possible ASPath. It is the complexity of the realized > topology, and not intrinsic properties of the protocol implementation, > that plays the largest role in convergence times. > > - Craig It is also NlogN to the number of prefixes becuase you have to insert them into data structures that scale on single insert, delete, and search operations logN to the number of entries. With a single operation taking logN time, N routes yield NlogN scaling. Since another application of BGP would create a new number space it would not matter if that number space was populated via a different protocol or if the delivery of this information was via BGP. A potential advantage of putting the new application outside of BGP is that on some architectures you can crash the protocol implementation running the other protocol and not impact BGP. In the future it might even reside on another processsor on large routers. Ignoring this, the risk is about as great adding to BGP or creating a new delivery protocol. Short of a crash, getting invalid information into the stream which is less than gracefully but not catostrophicly rejected by the receiver (ie: cause a cease) won't affect BGP if the delivery is not BGP, but is likely to affect BGP if the delivery is BGP. The perception seems to be that time to market is faster adding to BGP, but risk is slightly higher adding to BGP. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 15:02:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04477 for ; Fri, 1 Aug 2003 15:02:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ifA9-0007sl-Nx; Fri, 01 Aug 2003 15:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19if9P-0007sK-4Q for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 15:01:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04453 for ; Fri, 1 Aug 2003 15:01:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19if9K-0005C2-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 15:01:10 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19if9J-0005Bz-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 15:01:09 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h71J1gQk005507; Fri, 1 Aug 2003 15:01:43 -0400 Message-Id: <200308011901.h71J1gQk005507@mailhost.avici.com> To: Craig Labovitz cc: Jeff Parker , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Thu, 31 Jul 2003 11:24:45 EDT." <20030731112445.A23490@state.arbor.net> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 15:01:39 -0400 In message <20030731112445.A23490@state.arbor.net>, Craig Labovitz writes: > > > So, inter-domain BGP convergence is linear with respect to the length > of the longest possible ASPath. It is the complexity of the realized > topology, and not intrinsic properties of the protocol implementation, > that plays the largest role in convergence times. > > - Craig It is also NlogN to the number of prefixes becuase you have to insert them into data structures that scale on single insert, delete, and search operations logN to the number of entries. With a single operation taking logN time, N routes yield NlogN scaling. Since another application of BGP would create a new number space it would not matter if that number space was populated via a different protocol or if the delivery of this information was via BGP. A potential advantage of putting the new application outside of BGP is that on some architectures you can crash the protocol implementation running the other protocol and not impact BGP. In the future it might even reside on another processsor on large routers. Ignoring this, the risk is about as great adding to BGP or creating a new delivery protocol. Short of a crash, getting invalid information into the stream which is less than gracefully but not catostrophicly rejected by the receiver (ie: cause a cease) won't affect BGP if the delivery is not BGP, but is likely to affect BGP if the delivery is BGP. The perception seems to be that time to market is faster adding to BGP, but risk is slightly higher adding to BGP. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 15:31:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03754 for ; Fri, 1 Aug 2003 14:41:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iepq-00075z-Vc for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 14:41:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71If2jd027236 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 14:41:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iepq-00074t-8Z; Fri, 01 Aug 2003 14:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ieoz-00073k-Qv for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 14:40:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03723 for ; Fri, 1 Aug 2003 14:40:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ieox-00052l-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 14:40:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ieow-00052a-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 14:40:06 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Aug 2003 11:39:38 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h71IdYLH008746; Fri, 1 Aug 2003 11:39:34 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA17113; Fri, 1 Aug 2003 14:39:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <200308011731.h71HV0Rp026692@mailhost.avici.com> References: <200308011731.h71HV0Rp026692@mailhost.avici.com> To: curtis@fictitious.org From: "John G. Scudder" Subject: Re: Open Routing Area meeting in Vienna Cc: routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 14:39:30 -0400 At 1:30 PM -0400 8/1/03, Curtis Villamizar wrote: >In message <20030729183949.H2408@sbrim-w2k01>, Scott W Brim writes: >> How about we rename BGP, declare that we're done with the general >> information distribution protocol, and work on a new routing protocol? > >We tried that with IDRP and got nowhere. Cute, but not really. IDRP is substantially different from BGP. But maybe you meant that we've tried taking BGP, "fixing" it on a whiteboard, and declaring victory. In which case I agree. --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 16:33:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11163 for ; Fri, 1 Aug 2003 16:33:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igaD-0004qw-VE; Fri, 01 Aug 2003 16:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iga2-0004nj-3o for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 16:32:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11139 for ; Fri, 1 Aug 2003 16:32:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iga0-0006db-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 16:32:48 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19igZz-0006dS-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 16:32:47 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h71KWPnj017558; Fri, 1 Aug 2003 13:32:25 -0700 From: David Meyer To: Alex Zinin Cc: Routing Discussion Subject: Re: RP overloading: Next Steps Message-ID: <20030801133225.A17550@1-4-5.net> References: <182700830751.20030801012053@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <182700830751.20030801012053@psg.com>; from zinin@psg.com on Fri, Aug 01, 2003 at 01:20:53AM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 13:32:25 -0700 >> 2. Document concerns/considerations on overloading RPs with non-routing >> related information. >> >> dmm et al seem to be working on this part already. >> I suggest we formalize this as a design team and ask them >> to come back to this list with the document for further >> discussion. Ok by me. Those who have expressed interest in working on such a document are myself and Danny McPherson (danny@tcb.net). A few other people have offered to review whatever we come up with. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 16:36:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11288 for ; Fri, 1 Aug 2003 16:36:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igd8-00056r-75; Fri, 01 Aug 2003 16:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igcZ-00056I-DX for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 16:35:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11251 for ; Fri, 1 Aug 2003 16:35:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19igcX-0006eu-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 16:35:25 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19igcW-0006er-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 16:35:24 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h71KZBQk017140; Fri, 1 Aug 2003 16:35:13 -0400 Message-Id: <200308012035.h71KZBQk017140@mailhost.avici.com> To: "John G. Scudder" cc: Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Thu, 31 Jul 2003 14:29:24 EDT." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 16:35:08 -0400 In message , "John G. Scudder" writes: > > BGP's convergence time is said to be O(N!) in the number of > autonomous systems in the Internet. Eek! However, leaving aside the > fact that that's a theoretic upper bound and not the expected case, > that is a bound for Internet-wide convergence for a particular > destination; there is no term for number of data objects ("routes") > in the system. So that can't be relevant to your comment. That's just a worst case for the complete withdraw of a route where longer AS path alternatives are slower to withdraw than the primary. If route withdraws are treated immediately (or at least quickly) and changes propogated more slowly, then route withdraw is order(1). A route addition is order(1), the addition of a better route is order(1) and a route change where the better route is removed is order(1). > That leaves the on-box component. A decent BGP implementation should > have a per AF cost of approximately O(RPlogP) where R is the number > of routes ("paths") per prefix, and P is the number of prefixes > (destinations) stored in the local db for that AF. So, right, that's > not linear. But it's per AF. The cost of any BGP-like protocol > supporting a set of related data will equally be O(RPlogP). So > either you sum these terms into BGP, or you divide them into > different protocols... and still have to sum them. So once again, I > don't see the basis for your "two smaller sandwiches" comment. A little more accurate than what I said with NlogN but if you consider R to be a constant, then the same thing. The point that you are making that this is per AF is the same point that I was making. > This might be about software engineering, or protocol aesthetics, but > I don't think it's about theoretical convergence properties. > > --John Right. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 16:36:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11303 for ; Fri, 1 Aug 2003 16:36:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igdA-0005Ab-NG for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 16:36:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71Ka4TH019857 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 16:36:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igd8-00056r-75; Fri, 01 Aug 2003 16:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igcZ-00056I-DX for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 16:35:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11251 for ; Fri, 1 Aug 2003 16:35:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19igcX-0006eu-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 16:35:25 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19igcW-0006er-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 16:35:24 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h71KZBQk017140; Fri, 1 Aug 2003 16:35:13 -0400 Message-Id: <200308012035.h71KZBQk017140@mailhost.avici.com> To: "John G. Scudder" cc: Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Thu, 31 Jul 2003 14:29:24 EDT." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 16:35:08 -0400 In message , "John G. Scudder" writes: > > BGP's convergence time is said to be O(N!) in the number of > autonomous systems in the Internet. Eek! However, leaving aside the > fact that that's a theoretic upper bound and not the expected case, > that is a bound for Internet-wide convergence for a particular > destination; there is no term for number of data objects ("routes") > in the system. So that can't be relevant to your comment. That's just a worst case for the complete withdraw of a route where longer AS path alternatives are slower to withdraw than the primary. If route withdraws are treated immediately (or at least quickly) and changes propogated more slowly, then route withdraw is order(1). A route addition is order(1), the addition of a better route is order(1) and a route change where the better route is removed is order(1). > That leaves the on-box component. A decent BGP implementation should > have a per AF cost of approximately O(RPlogP) where R is the number > of routes ("paths") per prefix, and P is the number of prefixes > (destinations) stored in the local db for that AF. So, right, that's > not linear. But it's per AF. The cost of any BGP-like protocol > supporting a set of related data will equally be O(RPlogP). So > either you sum these terms into BGP, or you divide them into > different protocols... and still have to sum them. So once again, I > don't see the basis for your "two smaller sandwiches" comment. A little more accurate than what I said with NlogN but if you consider R to be a constant, then the same thing. The point that you are making that this is per AF is the same point that I was making. > This might be about software engineering, or protocol aesthetics, but > I don't think it's about theoretical convergence properties. > > --John Right. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 17:02:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12371 for ; Fri, 1 Aug 2003 17:02:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ih2H-0006gA-L0; Fri, 01 Aug 2003 17:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ih21-0006fP-Qy for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 17:01:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12356 for ; Fri, 1 Aug 2003 17:01:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ih1z-0006tz-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 17:01:43 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 19ih1y-0006tl-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 17:01:42 -0400 Received: from gih505.telstra.net (dhcp50.potaroo.net [203.10.60.50]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h71L0dDB089792; Sat, 2 Aug 2003 07:00:48 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030802064417.00b3ef18@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: curtis@fictitious.org From: Geoff Huston Subject: Re: Open Routing Area meeting in Vienna Cc: erosen@cisco.com, routing-discussion@ietf.org In-Reply-To: <200308011833.h71IXHRp001918@mailhost.avici.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 02 Aug 2003 06:52:32 +1000 At 02:33 PM 1/08/2003 -0400, Curtis Villamizar wrote: > > > > I suspect in this comment that Eric is skipping across some amazing > efforts > > by a small pool of folk to reign in some of the more extreme forms of > > deployed routing abuse (no, I do not count my own small efforts in this > pool > > of individuals). Keeping the network vaguely stable at it's current size > > is taking increasingly large amounts of manual effort, and no, this > > cannot scale indefinitely. > >Is that an inter-provider coordination problem or a protocol problem? Both - its remarkably easy to do the Wrong Thing on a global scale. The fact that its too easy is a use issue. The fact that the consequences are immediately promulgated globally can be interpreted as a protocol issue. (see the ptomaine work on attempting to limit propagation of routing noise). Geoff _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 17:02:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12378 for ; Fri, 1 Aug 2003 17:02:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ih2S-0006ha-Kf for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 17:02:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71L2CfS025736 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 17:02:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ih2H-0006gA-L0; Fri, 01 Aug 2003 17:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ih21-0006fP-Qy for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 17:01:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12356 for ; Fri, 1 Aug 2003 17:01:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ih1z-0006tz-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 17:01:43 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 19ih1y-0006tl-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 17:01:42 -0400 Received: from gih505.telstra.net (dhcp50.potaroo.net [203.10.60.50]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h71L0dDB089792; Sat, 2 Aug 2003 07:00:48 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030802064417.00b3ef18@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: curtis@fictitious.org From: Geoff Huston Subject: Re: Open Routing Area meeting in Vienna Cc: erosen@cisco.com, routing-discussion@ietf.org In-Reply-To: <200308011833.h71IXHRp001918@mailhost.avici.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 02 Aug 2003 06:52:32 +1000 At 02:33 PM 1/08/2003 -0400, Curtis Villamizar wrote: > > > > I suspect in this comment that Eric is skipping across some amazing > efforts > > by a small pool of folk to reign in some of the more extreme forms of > > deployed routing abuse (no, I do not count my own small efforts in this > pool > > of individuals). Keeping the network vaguely stable at it's current size > > is taking increasingly large amounts of manual effort, and no, this > > cannot scale indefinitely. > >Is that an inter-provider coordination problem or a protocol problem? Both - its remarkably easy to do the Wrong Thing on a global scale. The fact that its too easy is a use issue. The fact that the consequences are immediately promulgated globally can be interpreted as a protocol issue. (see the ptomaine work on attempting to limit propagation of routing noise). Geoff _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 17:21:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11165 for ; Fri, 1 Aug 2003 16:33:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igaK-0004sI-Cq for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 16:33:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71KX8dC018725 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 16:33:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19igaD-0004qw-VE; Fri, 01 Aug 2003 16:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iga2-0004nj-3o for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 16:32:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11139 for ; Fri, 1 Aug 2003 16:32:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iga0-0006db-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 16:32:48 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19igZz-0006dS-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 16:32:47 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h71KWPnj017558; Fri, 1 Aug 2003 13:32:25 -0700 From: David Meyer To: Alex Zinin Cc: Routing Discussion Subject: Re: RP overloading: Next Steps Message-ID: <20030801133225.A17550@1-4-5.net> References: <182700830751.20030801012053@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <182700830751.20030801012053@psg.com>; from zinin@psg.com on Fri, Aug 01, 2003 at 01:20:53AM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 13:32:25 -0700 >> 2. Document concerns/considerations on overloading RPs with non-routing >> related information. >> >> dmm et al seem to be working on this part already. >> I suggest we formalize this as a design team and ask them >> to come back to this list with the document for further >> discussion. Ok by me. Those who have expressed interest in working on such a document are myself and Danny McPherson (danny@tcb.net). A few other people have offered to review whatever we come up with. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 19:15:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16841 for ; Fri, 1 Aug 2003 19:15:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ij6z-0004y4-FQ; Fri, 01 Aug 2003 19:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ij61-0004or-IF for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 19:14:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16804 for ; Fri, 1 Aug 2003 19:13:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ij60-0007gQ-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 19:14:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19ij5z-0007gN-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 19:13:59 -0400 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.20) id 19ij5z-000KbV-T3; Fri, 01 Aug 2003 23:13:59 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19ij5z-000LYc-Hz; Fri, 01 Aug 2003 16:13:59 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: Curtis Villamizar Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200308012035.h71KZBQk017140@mailhost.avici.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA16805 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 16:13:43 -0700 Content-Transfer-Encoding: quoted-printable > That's just a worst case for the complete withdraw of a route where > longer AS path alternatives are slower to withdraw than the primary. > If route withdraws are treated immediately (or at least quickly) and > changes propogated more slowly, then route withdraw is order(1). A > route addition is order(1), the addition of a better route is order(1) > and a route change where the better route is removed is order(1). actual measured data in the real internet shows a single announce a couple of hops away can (often) result in over 40 announces and a few withdraws interspersed. a single withdraw can be more exciting. will be presenting next month at apnic. randy --- In theory there is no difference between theory and practice, but in practice, there is. -- Patrik F=E4ltstr=F6m =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 19:15:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16843 for ; Fri, 1 Aug 2003 19:15:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ij77-0004zW-8G for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 19:15:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71NF9SV019150 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 19:15:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ij6z-0004y4-FQ; Fri, 01 Aug 2003 19:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ij61-0004or-IF for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 19:14:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16804 for ; Fri, 1 Aug 2003 19:13:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ij60-0007gQ-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 19:14:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19ij5z-0007gN-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 19:13:59 -0400 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.20) id 19ij5z-000KbV-T3; Fri, 01 Aug 2003 23:13:59 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19ij5z-000LYc-Hz; Fri, 01 Aug 2003 16:13:59 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: Curtis Villamizar Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200308012035.h71KZBQk017140@mailhost.avici.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA16805 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 16:13:43 -0700 Content-Transfer-Encoding: quoted-printable > That's just a worst case for the complete withdraw of a route where > longer AS path alternatives are slower to withdraw than the primary. > If route withdraws are treated immediately (or at least quickly) and > changes propogated more slowly, then route withdraw is order(1). A > route addition is order(1), the addition of a better route is order(1) > and a route change where the better route is removed is order(1). actual measured data in the real internet shows a single announce a couple of hops away can (often) result in over 40 announces and a few withdraws interspersed. a single withdraw can be more exciting. will be presenting next month at apnic. randy --- In theory there is no difference between theory and practice, but in practice, there is. -- Patrik F=E4ltstr=F6m =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 21:12:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19233 for ; Fri, 1 Aug 2003 21:12:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ikvG-0003nz-5p; Fri, 01 Aug 2003 21:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ikuh-0003n1-2b for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 21:10:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19186 for ; Fri, 1 Aug 2003 21:10:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ikue-0000ZJ-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 21:10:24 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19ikud-0000ZA-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 21:10:23 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h721AEQk009533; Fri, 1 Aug 2003 21:10:15 -0400 Message-Id: <200308020110.h721AEQk009533@mailhost.avici.com> To: erosen@cisco.com cc: Lars Erik Gullerud , raszuk@cisco.com, Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Fri, 01 Aug 2003 13:07:55 EDT." <200308011707.h71H7txc023043@rtp-core-2.cisco.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 21:12:30 -0400 In message <200308011707.h71H7txc023043@rtp-core-2.cisco.com>, Eric Rosen write s: > > Lars> One problem as I see it right now though, is that if the contents of > Lars> one of those bags isn't satisfactory (i.e. an update message is > Lars> invalid), you throw the whole loaf of bread away (i.e. peer sends > Lars> notification message and tears down the BGP session). > > This point is well taken. > > But don't you think that whatever happens here, this should be fixed in BGP? > Even if BGP just carried the IPv4 and IPv6 address families, you might not > want an error in one to take down the whole session. Right now a cease is not AF specific and neither is a crash of the BGP task. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 22:06:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19232 for ; Fri, 1 Aug 2003 21:12:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ikva-0003qk-1S for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 21:11:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h721BMxE014770 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 21:11:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ikvG-0003nz-5p; Fri, 01 Aug 2003 21:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ikuh-0003n1-2b for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 21:10:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19186 for ; Fri, 1 Aug 2003 21:10:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ikue-0000ZJ-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 21:10:24 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19ikud-0000ZA-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 21:10:23 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h721AEQk009533; Fri, 1 Aug 2003 21:10:15 -0400 Message-Id: <200308020110.h721AEQk009533@mailhost.avici.com> To: erosen@cisco.com cc: Lars Erik Gullerud , raszuk@cisco.com, Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Fri, 01 Aug 2003 13:07:55 EDT." <200308011707.h71H7txc023043@rtp-core-2.cisco.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 21:12:30 -0400 In message <200308011707.h71H7txc023043@rtp-core-2.cisco.com>, Eric Rosen write s: > > Lars> One problem as I see it right now though, is that if the contents of > Lars> one of those bags isn't satisfactory (i.e. an update message is > Lars> invalid), you throw the whole loaf of bread away (i.e. peer sends > Lars> notification message and tears down the BGP session). > > This point is well taken. > > But don't you think that whatever happens here, this should be fixed in BGP? > Even if BGP just carried the IPv4 and IPv6 address families, you might not > want an error in one to take down the whole session. Right now a cease is not AF specific and neither is a crash of the BGP task. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 1 22:32:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20409 for ; Fri, 1 Aug 2003 22:32:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19imBj-00079k-Un for routing-discussion-archive@odin.ietf.org; Fri, 01 Aug 2003 22:32:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h722W7Gi027500 for routing-discussion-archive@odin.ietf.org; Fri, 1 Aug 2003 22:32:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19imBd-00078j-2r; Fri, 01 Aug 2003 22:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19imAk-000781-FM for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 22:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20391 for ; Fri, 1 Aug 2003 22:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19imAh-0000tP-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 22:31:03 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19imAg-0000tM-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 22:31:02 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h722VjQk014993; Fri, 1 Aug 2003 22:31:46 -0400 Message-Id: <200308020231.h722VjQk014993@mailhost.avici.com> To: Randy Bush cc: Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Fri, 01 Aug 2003 16:13:43 PDT." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 22:34:01 -0400 In message , Randy Bush writes: > > That's just a worst case for the complete withdraw of a route where > > longer AS path alternatives are slower to withdraw than the primary. > > If route withdraws are treated immediately (or at least quickly) and > > changes propogated more slowly, then route withdraw is order(1). A > > route addition is order(1), the addition of a better route is order(1) > > and a route change where the better route is removed is order(1). > > actual measured data in the real internet shows a single announce a > couple of hops away can (often) result in over 40 announces and a > few withdraws interspersed. a single withdraw can be more > exciting. > > will be presenting next month at apnic. > > randy For the announce you'll receive one announce for each feasible path. If the best tend to come first or early, the rest are essentially remembered but cause no work. Since ignoring this input is of almost no consequence, only inserting in AdjIn-RIB, this is still order(1). The problem with withdraws is that in the case of a split past the point of failure, one branch of the split can announce alternates that point to the other side of the split even though they share a common failure. For example: c ---f---> / \ . a---b e . \ / . d ---g---> When a-b fails, d may decide the best path is by way of ... c-b-a. This may go through e-c-b-a. It can't announce back to e, but can announce the change to g. Same thing happens at c. The only way to prevent this is for c and d to announce the withdraw immediately, and then if they still have a feasible route after some number of seconds announce the changed route. The objection is that you don't want to black hole traffic so announce the change. A slightly smarter way would be to do this (propogate the withdraw and delay propogating the change) if the replacement route has a common AS path sequence with the route that is replacing it. This avoids the explosion and at least partially eliminates the objection. ***If*** route withdraws are treated immediately (or at least quickly) and changes propogated more slowly, then route withdraw is order(1). Most of Craig's work uncovered bugs in widely used implementations. This is one of them. Craig pointed out this explosion on withdraw quite some time ago. If withdraws propogate very fast and changes are delayed, all of the withdraws propogate before anyone announces a change. None of this is news. The same solutions that were discussed years ago when Craig brought this up still apply today. If providers want this fixed maybe they are not asking loud enough or they forgot why they didn't want it fixed the last time this issue came up. The last time this came up avoiding a potential black hole was more important than the extra routing information so provider input was to keep things as is. Curtis btw- congratulations to the researchers for discovering it again. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 1 23:21:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20408 for ; Fri, 1 Aug 2003 22:32:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19imBd-00078j-2r; Fri, 01 Aug 2003 22:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19imAk-000781-FM for routing-discussion@optimus.ietf.org; Fri, 01 Aug 2003 22:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20391 for ; Fri, 1 Aug 2003 22:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19imAh-0000tP-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 22:31:03 -0400 Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19imAg-0000tM-00 for routing-discussion@ietf.org; Fri, 01 Aug 2003 22:31:02 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h722VjQk014993; Fri, 1 Aug 2003 22:31:46 -0400 Message-Id: <200308020231.h722VjQk014993@mailhost.avici.com> To: Randy Bush cc: Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Fri, 01 Aug 2003 16:13:43 PDT." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 22:34:01 -0400 In message , Randy Bush writes: > > That's just a worst case for the complete withdraw of a route where > > longer AS path alternatives are slower to withdraw than the primary. > > If route withdraws are treated immediately (or at least quickly) and > > changes propogated more slowly, then route withdraw is order(1). A > > route addition is order(1), the addition of a better route is order(1) > > and a route change where the better route is removed is order(1). > > actual measured data in the real internet shows a single announce a > couple of hops away can (often) result in over 40 announces and a > few withdraws interspersed. a single withdraw can be more > exciting. > > will be presenting next month at apnic. > > randy For the announce you'll receive one announce for each feasible path. If the best tend to come first or early, the rest are essentially remembered but cause no work. Since ignoring this input is of almost no consequence, only inserting in AdjIn-RIB, this is still order(1). The problem with withdraws is that in the case of a split past the point of failure, one branch of the split can announce alternates that point to the other side of the split even though they share a common failure. For example: c ---f---> / \ . a---b e . \ / . d ---g---> When a-b fails, d may decide the best path is by way of ... c-b-a. This may go through e-c-b-a. It can't announce back to e, but can announce the change to g. Same thing happens at c. The only way to prevent this is for c and d to announce the withdraw immediately, and then if they still have a feasible route after some number of seconds announce the changed route. The objection is that you don't want to black hole traffic so announce the change. A slightly smarter way would be to do this (propogate the withdraw and delay propogating the change) if the replacement route has a common AS path sequence with the route that is replacing it. This avoids the explosion and at least partially eliminates the objection. ***If*** route withdraws are treated immediately (or at least quickly) and changes propogated more slowly, then route withdraw is order(1). Most of Craig's work uncovered bugs in widely used implementations. This is one of them. Craig pointed out this explosion on withdraw quite some time ago. If withdraws propogate very fast and changes are delayed, all of the withdraws propogate before anyone announces a change. None of this is news. The same solutions that were discussed years ago when Craig brought this up still apply today. If providers want this fixed maybe they are not asking loud enough or they forgot why they didn't want it fixed the last time this issue came up. The last time this came up avoiding a potential black hole was more important than the extra routing information so provider input was to keep things as is. Curtis btw- congratulations to the researchers for discovering it again. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Sat Aug 2 22:36:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27018 for ; Sat, 2 Aug 2003 22:36:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19j8if-0005Hm-Ul for routing-discussion-archive@odin.ietf.org; Sat, 02 Aug 2003 22:35:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h732Zbi5020317 for routing-discussion-archive@odin.ietf.org; Sat, 2 Aug 2003 22:35:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19j8i5-0005Gq-Sw; Sat, 02 Aug 2003 22:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19j8hF-0005GU-D7 for routing-discussion@optimus.ietf.org; Sat, 02 Aug 2003 22:34:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27006 for ; Sat, 2 Aug 2003 22:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19j8hB-000606-00 for routing-discussion@ietf.org; Sat, 02 Aug 2003 22:34:05 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19j8hB-0005zr-00 for routing-discussion@ietf.org; Sat, 02 Aug 2003 22:34:05 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h732XZGC033098; Sat, 2 Aug 2003 22:33:35 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h732XVdm033091; Sat, 2 Aug 2003 22:33:31 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h732XQl11944; Sat, 2 Aug 2003 22:33:26 -0400 (EDT) From: Jeffrey Haas To: Alex Zinin Cc: Routing Discussion Subject: Re: RP overloading: main question wrt code impact and resource sharing Message-ID: <20030802223326.B11842@nexthop.com> References: <64672146084.20030731172248@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <64672146084.20030731172248@psg.com>; from zinin@psg.com on Thu, Jul 31, 2003 at 05:22:48PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 2 Aug 2003 22:33:26 -0400 After playing large amounts of catchup on these threads, this message provides the best place for me to make the points I'd want to make. :-) On Thu, Jul 31, 2003 at 05:22:48PM -0700, Alex Zinin wrote: > What essentially we are talking about is the most comfortable location > of the demux point among the apps. We have two major scenarios: > > The BGP-based model: in this case, there's a single demux point for > routing and non-routing apps, and it is at the AFI/SAFI > parsing/encoding stage. All apps are explicitly exposed to BGP. > > The non-BGP model: in this case, BGP is not exposed to non-routing > apps and the demux point for them, as well as for BGP as a whole, is > at the TCP level. As I posted in the routing direcorate, this is all largely about two things: Is this appropriate to carry in BGP? If so, what are the consequences? The first question is two-pronged: When we say BGP, do we mean the protocol or the implementations of that protocol as currently used in the Internet? (Note that I realize by saying "the protocol" we imply the latter by the fact that port 179 is used, etc. etc. I am far more concerned with the PDU format and route selection behavior.) After chatting with some people, none of the drafts that I've looked at grossly distort transporting information in BGP in such a way that it it bent completely out of shape. I think that some of the things that are being done are unsightly and a better way should have been created to do it (per-NLRI information binding for example in MP-BGP extensions), but it is still servicable from an encoding standpoint. I hope we can put that issue behind us - I don't think it is what we are really concerned about. Our real issues are operational and implementation based ones. I believe that one of the largest ones has been implied by talking about protocol-level multiplexing. In my opinion, we're suffering from an "all eggs in one basket" problem. We're just arguing about what to do about it, if anything. (I believe many operators have been yelling "stop adding eggs!" for some time now.) One suggested mechanism to help address part of these issues is multiple processes/peering sessions. This addresses one large concern I have in the single transport session version - which is what we have now: A mistake by one hunk of code will take down everything. It's not robust. The usual response is "don't make mistakes". Ahem. :-) The problem with separating things into multiple processes or peering sessions is the fact that we will be sharing internal resources. Common radix tries, AS Path and community databases, RIB code, etc. To attempt to separate too much of this information into separate instances (sandboxing) is to remove many of the efficiencies in time and space we attempt to target when doing our implementations. I don't think this is realistic in most cases. Moving things into separate peering sessions also has the benefit that we don't delay convergence of a given protocol because of queue ordering issues for that instance. However as (I think) Curtis noted, we don't do enough to ensure fair queueing in our current implementations. Why would this change? IMO, moving things into separate sessions at least encourages developers to put more "fairness" into their implementations for each instance. If everything is in a single session, it is all too easy for a simple coding mistake in the protocol code to monopolize PDU traffic for just a single AFI/SAFI, delaying convergence of all the others. This moves the problem out of the protocol code for fairness and more into the process scheduler. The usual answer to resource monopolization is "don't do that". Ahem. :-) However, there is an inherent issue with moving things to separate peering sessions: fate sharing. If your extension relies on information from the base Internet IPv4 routing table, you want the things to be in as close synchronization as possible. This usually means you want it in the same peering session. One way or the other, the implementation *MUST* do what it can to not delay sending its updates too long. BGP is stateful; if you know something has changed and you take forever to tell someone about it, the network as a whole suffers. ...... This all comes down to survivability. We know we can work around all of these issues within our current code if the code is carefully designed, architected to provide the "right" amount of "fairness" and is robust. We know from experience that the code is generally evolved rather than designed after the initial design, generally unfair and not as robust as we would like. IMO, the best answer that provides for protocol-level robustness is multiple peering sessions. I could even live with these sessions being layered on SCTP. We should thus explore the mechanisms by which we could bind the fate of the things that care about such things. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Aug 2 23:21:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27019 for ; Sat, 2 Aug 2003 22:36:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19j8i5-0005Gq-Sw; Sat, 02 Aug 2003 22:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19j8hF-0005GU-D7 for routing-discussion@optimus.ietf.org; Sat, 02 Aug 2003 22:34:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27006 for ; Sat, 2 Aug 2003 22:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19j8hB-000606-00 for routing-discussion@ietf.org; Sat, 02 Aug 2003 22:34:05 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19j8hB-0005zr-00 for routing-discussion@ietf.org; Sat, 02 Aug 2003 22:34:05 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h732XZGC033098; Sat, 2 Aug 2003 22:33:35 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h732XVdm033091; Sat, 2 Aug 2003 22:33:31 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h732XQl11944; Sat, 2 Aug 2003 22:33:26 -0400 (EDT) From: Jeffrey Haas To: Alex Zinin Cc: Routing Discussion Subject: Re: RP overloading: main question wrt code impact and resource sharing Message-ID: <20030802223326.B11842@nexthop.com> References: <64672146084.20030731172248@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <64672146084.20030731172248@psg.com>; from zinin@psg.com on Thu, Jul 31, 2003 at 05:22:48PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 2 Aug 2003 22:33:26 -0400 After playing large amounts of catchup on these threads, this message provides the best place for me to make the points I'd want to make. :-) On Thu, Jul 31, 2003 at 05:22:48PM -0700, Alex Zinin wrote: > What essentially we are talking about is the most comfortable location > of the demux point among the apps. We have two major scenarios: > > The BGP-based model: in this case, there's a single demux point for > routing and non-routing apps, and it is at the AFI/SAFI > parsing/encoding stage. All apps are explicitly exposed to BGP. > > The non-BGP model: in this case, BGP is not exposed to non-routing > apps and the demux point for them, as well as for BGP as a whole, is > at the TCP level. As I posted in the routing direcorate, this is all largely about two things: Is this appropriate to carry in BGP? If so, what are the consequences? The first question is two-pronged: When we say BGP, do we mean the protocol or the implementations of that protocol as currently used in the Internet? (Note that I realize by saying "the protocol" we imply the latter by the fact that port 179 is used, etc. etc. I am far more concerned with the PDU format and route selection behavior.) After chatting with some people, none of the drafts that I've looked at grossly distort transporting information in BGP in such a way that it it bent completely out of shape. I think that some of the things that are being done are unsightly and a better way should have been created to do it (per-NLRI information binding for example in MP-BGP extensions), but it is still servicable from an encoding standpoint. I hope we can put that issue behind us - I don't think it is what we are really concerned about. Our real issues are operational and implementation based ones. I believe that one of the largest ones has been implied by talking about protocol-level multiplexing. In my opinion, we're suffering from an "all eggs in one basket" problem. We're just arguing about what to do about it, if anything. (I believe many operators have been yelling "stop adding eggs!" for some time now.) One suggested mechanism to help address part of these issues is multiple processes/peering sessions. This addresses one large concern I have in the single transport session version - which is what we have now: A mistake by one hunk of code will take down everything. It's not robust. The usual response is "don't make mistakes". Ahem. :-) The problem with separating things into multiple processes or peering sessions is the fact that we will be sharing internal resources. Common radix tries, AS Path and community databases, RIB code, etc. To attempt to separate too much of this information into separate instances (sandboxing) is to remove many of the efficiencies in time and space we attempt to target when doing our implementations. I don't think this is realistic in most cases. Moving things into separate peering sessions also has the benefit that we don't delay convergence of a given protocol because of queue ordering issues for that instance. However as (I think) Curtis noted, we don't do enough to ensure fair queueing in our current implementations. Why would this change? IMO, moving things into separate sessions at least encourages developers to put more "fairness" into their implementations for each instance. If everything is in a single session, it is all too easy for a simple coding mistake in the protocol code to monopolize PDU traffic for just a single AFI/SAFI, delaying convergence of all the others. This moves the problem out of the protocol code for fairness and more into the process scheduler. The usual answer to resource monopolization is "don't do that". Ahem. :-) However, there is an inherent issue with moving things to separate peering sessions: fate sharing. If your extension relies on information from the base Internet IPv4 routing table, you want the things to be in as close synchronization as possible. This usually means you want it in the same peering session. One way or the other, the implementation *MUST* do what it can to not delay sending its updates too long. BGP is stateful; if you know something has changed and you take forever to tell someone about it, the network as a whole suffers. ...... This all comes down to survivability. We know we can work around all of these issues within our current code if the code is carefully designed, architected to provide the "right" amount of "fairness" and is robust. We know from experience that the code is generally evolved rather than designed after the initial design, generally unfair and not as robust as we would like. IMO, the best answer that provides for protocol-level robustness is multiple peering sessions. I could even live with these sessions being layered on SCTP. We should thus explore the mechanisms by which we could bind the fate of the things that care about such things. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Aug 5 17:29:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29384 for ; Tue, 5 Aug 2003 17:29:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k9Mv-0001FB-Pz for routing-discussion-archive@odin.ietf.org; Tue, 05 Aug 2003 17:29:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75LTLjU004780 for routing-discussion-archive@odin.ietf.org; Tue, 5 Aug 2003 17:29:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k9Mb-0001EL-JP; Tue, 05 Aug 2003 17:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k9M2-0001D8-PM for routing-discussion@optimus.ietf.org; Tue, 05 Aug 2003 17:28:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29351 for ; Tue, 5 Aug 2003 17:28:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k9M0-00062n-00 for routing-discussion@ietf.org; Tue, 05 Aug 2003 17:28:24 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19k9Lz-00062k-00 for routing-discussion@ietf.org; Tue, 05 Aug 2003 17:28:23 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19k9Ly-00071m-Ja for routing-discussion@ietf.org; Tue, 05 Aug 2003 21:28:22 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <197112511873.20030805142816@psg.com> To: routing-discussion@ietf.org Subject: IETF-57 RTG area meeting minutes MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA29352 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 5 Aug 2003 14:28:16 -0700 Content-Transfer-Encoding: quoted-printable Thanks to Ross and Dimitri, minutes from the meeting below. Folks who were at the meeting--please review and let me know if something is so inaccurate it should be fixed. -- Alex Announcements (Bill Fenner) - RIP working group is finished and will be ended - There is a routing area website: www.rtg.ietf.org=20 - THere is a routing area mailing list: routing-discussion@ietf.o= rg=20 Working Group Reports IDR status (Sue Hares) - are in a holding patter until base spec is complete (are on -21= ) - see agenda for IDR working group IS-IS - no report Manet (Alex) - four protocol specification are going to experimental status=20 AODV was published as RFC 3561 others in progress (one recently reviewed) =20 Implementation is in progress Multicast Last Mile BOF - no report OSPF Status=20 - two RFCs (NSSA 3101; 3509) - five documents in working group last call or beyond - OSPF V2 TE is through to the RFC editors - BCP prioritization fo OSFP packets - refresh reduction in stable topologies - two mibs and v3 and authentication for V3 need more work - two new documents are just starting at this IETF MSDP - document done - MIB almost done PIM - three major drafts in progress - they have been pretty stable for a while - trying to arrange appropriate reviewers RPSec=20 - didn't meet SSM=20 - didn't meet at this IETF UDLR - no meeting (but status report) - 30 June, submitted revised version - Major changes from v00.txt (now v01.txt) . write PPPoE experiment . wrire PIM-SM and MSDP experiment . add NAT - IPv6 over UDLR . no exp i-d . 18 june, start discussion on mailing list . if there is common interest make a draft charter an propose t= o AD's VRRP - Radia Perlman is now co-chair of the group - security has been removed from VRRP after considerable discussi= on - v2 and v3 drafts have been updated. V2 is ready for WG last can= n as draft standard. VRRPv3 MIB has just been submitted to the worki= ng group, and needs review.=20 UDLR - no report IP Forwarding MIB (Brian) a while ago updated MIB support for IPv6 requested. Most of these are in last call in the IPv6 working group. A request: Why not fix other stuff, such as making it easier to support in today's forwarding engines? This work is starting now that the IPv6 is stable. Question to people designing forwarding engines: Is the current IP Forwarding MIB that is currently defined for IPv4 useful at all? If not, should we fix it now. Send opinions to Bill Fenner of the routing area mailing list. Panel: Routing Protocol Overload Panelists:=20 Dave Meyer =20 Pedro Marques Ron Bonica Gargi Nalawade =20 Introduction by Alex:=20 Why are we here: Community is polarized over use of routing protocols for uses which go somewhat beyond the narrow definition of routing (particularly wrt BGP). Alex would like to see the community talk. Alex characterized the two viewpoints as: Camp 1: - MP-BGP framework is a useful tool to distribute info among INET= routers - Fair treatment of different AFI/SAFI=92s is an implementation p= roblem - We know how to do this, leave this to us Camp 2: - This is dangerous. Risks the Internet. Any instability or code = complexity=20 caused by one use of BGP could destabilize the main purpose, wh= ich is=20 Internet inter-domain routing.=20 Alex would like us to walk out of this room with some understanding of where we are going. He would like us to find a common ground. Please respect other points of view. Please don't bring personality issues to the discussion. Don't just state your opinion, but instead explain the reason for the opinion. Panelists present their opinion: Dave Meyer: - Musings on NLRI loading, stability, and signaling in the Intern= et - It is hard to get hard evidence on what we ought to do. Maybe w= e need a study on the topic.=20 - BGP and maybe IGPs can form an effective transport for new features.=20 - BGP is also used in the Internet - BGP in the Internet can have stability issues in some cases. - It seems reasonable to ask what effect loading BGP with other i= nformation will have on routing stability. - Dave can't quantify anything about the stability. Dave has talk= ed to a lot=20 of people. Plusses: Operational simplification; Code Re-Use; BGP code will= be=20 carefully optimized. - Operational complexity: Worry about breaking one thing when doi= ng=20 something else. Single point of failure. Internal queue managem= ent=20 needed.=20 - Much of this is conjecture.=20 - What if we wanted to start from scratch: Would we want a genera= lized feature transport Mechanism? If so, is BGP this mechanism? As a= n example MSDP ended up looking a lot like BGP.=20 - Proposal: create problem statement. Draft Requirements, framewo= rk and architecture. Perhaps we should present a problem statement at = the next IETF.=20 Ron Bonica - Defining the scope of BGP - Background on the problem: Routers support many applications wh= ich require the synchronization of databases on multiple routers.=20 - BGP could support all of these applications.=20 - Ron echoed concerns that he has heard: Will BGP get buggy as we= make it=20 more complex? Is there a possibility of mis-configuration: As f= unctionality=20 increases, will information be leaked incorrectly between servi= ce providers,=20 and possibly be mis-interpreted?=20 - Mitigations for these concerns are available: BGP software is a= lready fairly modular. Data transfer is separate from other functions. This i= mplies that as we add more to BGP, we add new modules. Controls exist to prote= ct against=20 mis-configuration. - Big Bug issue: What if something really bad happens? - BGP incomprehensibility: What if it gets too big for a human to= understand? - Perhaps we should document BGP as a number of separate modules.= =20 - Options - restrict BGP to main use, and clone it for other reason= s - abstract data transfer from other parts - let BGP grow - None of these solutions are necessarily right.=20 - if clone, end up fixing same bugs in multiple code base= s and updating=20 code multiple times - We are on shaky ground in taking on this issue. Most of this di= scussion is about=20 software engineering. The IETF doesn't normally do software eng= ineering.=20 - Proposal: That we listen to vendors and operators. Study the is= sue.=20 Pedro Marques: - (Mostly agree with Dave. This is an issue to study) - Look at this from the point of view of System Availability in=20 Multiservice Networks - What is router availability? - What does it depend upon? - Is there is an impact on deploying a new service in the router?= Yes. - Don't just look at one component of this. Look at overall syste= m and network availability. The resource sharing issue surfaces whene= ver you introduce a new service on the router. However, resource sharin= g is also an issue when you have only IP Internet service (eg, sharing be= tween BGP and an IGP; sharing between multiple BGP neighbors, so that one= neighbor doesn't seriously impact another).=20 - System availability is a system design issue. There are signifi= cant software engineering aspects of this. System availability is generally i= mproved by=20 maximizing code re-use. This leads to fewer defects.=20 - The most problematic issue is internal infrastucture changes (i= nternal to the router). This is independent of the protocol issue, and indepen= dent of anything that we do in the IETF.=20 - If a given problem requires point to multipoint distribution of= information,=20 then re-use of BGP is more cost-effective than inventing a new = solution.=20 - Summary: Resource sharing is always an issue. This is not limit= ed to multi- service issues. There are serious issues here, but these are pr= imarily software engineering issues and therefore outside of the scope of the IE= TF.=20 Gargi Nalawade - Consider "Routing Protocol Overhead".=20 - What is BGP: A routing protocol, or a database distribution pro= tocol?=20 - If it is a routing protocol, should it be doing database distri= bution? - If it is a database distribution protocol, should it be doing r= outing? - BGP definitely does routing. If it does both, what % of its tas= k should be doing routing?=20 - Question is not whether BGP can do this, of course it can. But = the=20 question is whether BGP should do this.=20 - Routing related information which is closely tied to BGP must b= e carried in BGP.=20 - What's the solution: Identify the problem. What is routing rela= ted? Then we can talk about solutions.=20 - This is not just a BGP issue. IGPs carry opaque LSAs and/or=20 extensible TLV. Why have a BGP-specific solution. - She agreed with Pedro that cloning is bad for the health.=20 Open Discussion: - Yakov: Gargi's comment that she doesn't want BGP to carry Shake= speare is not relevant to the discussion. The decision should be based on= a cost/benefit=20 analysis, not on what she wants.=20 - Mark Handley: We might want to distinguish Protocol implementat= ion=20 overloading, versus protocol instance overloading, versus proto= col design=20 overloading. Instance is most important. We are talking about f= ate sharing;=20 If you have two services sharing the same protocol, then they s= hare the same fate. If two services need to be coupled then fine, but otherwi= se don't put=20 them in the same protocol instance. Congestion control sharing = is also=20 potentially an issue. Example from different world (SIP): SIP w= as designed to=20 operate over . Then SIP got instant messaging adde= d to it, then=20 it was realized that instant messaging included video, this was= too much,=20 then they fixed it by removing some features and handling them = otherwise.=20 - Chandra (from cisco): The concerns that people have expressed a= re not clearly articulated. Are we talking about overloading the protocol, ver= sus the=20 implementation, versus a protocol instance? These are not the s= ame, and=20 he doesn't know which one is the concern. Is this an issue of c= onfiguration=20 modules, or software implementation? If this is a configuration= issue, then=20 you can fix this as a configuration issue and not as a protocol= design issue.=20 - Dave Meyer wants to understand whether putting more into BGP ef= fects global Internet stability.=20 - Rahib: What if any impact will this have on the scalability of = the routing=20 protocol?=20 - Rob (Austein): Has spent time with DNS. When you keep adding fe= atures to a protocol, pay attention to who gets benefits and who suffe= rs the pain.=20 - Kurt (Lindqvist) We are getting lazy: We are trying to make it = easy by using the same protocol over and over. The threshold for adding thing= s to the=20 protocol is too low. Where does this end?=20 - Kireeti: Don't ask if you are overloading the protocol or syste= m. Ask about multiservice platforms: Is this a good idea? The resource conte= ntion comes from having multiple services on the same physical platform. Do= we want a=20 box doing IP, and a different box doing L2VPNs, and a differen= t box doing L3 VPNs, etc.. The issue is whether we put these in one box or = in multiple=20 boxes. If the box falls over, then you have taken down whatever= is on the=20 box. Putting multiple services on the same box will have an imp= act, and=20 therefore require careful implementation. Whether you put them = in the same=20 protocol is at the most a second order issue. It is normal for = reachability=20 information and routing information to be in a routing protocol= : An IP VPN prefix is reachability information. A layer 2 prefix is reachab= ility information.=20 - Ross Callon: Some have talked about software engineering, other= s have=20 expressed concerns about internet stability and a few said "I d= on't care about=20 software engineering, I care about Internet stability". We need= to understand that software engineering is a major impact on Internet stabili= ty, and thus the=20 people who are talking about software engineering are talking a= bout internet=20 stability, and are trying to address what is the most critical = part of Internet=20 stability. Using the same protocol does not preclude a careful = partitioning of=20 resources within a device, nor does it preclude using separate = TCP connections.=20 Using a different protocol does not guarantee using different r= esources: If=20 multiple services are in the same physical device, at some leve= l there will be=20 some sharing of resources. Therefore the primary issue is not t= he protocol. The=20 primary issue is the services on the box, and how much informat= ion needs to be=20 exchanged between the boxes. Adding new services to the box req= uires new=20 information. This will have some impact. Ross has heard comment= s from=20 multiple service providers that they don't want ten different t= ypes of boxes in=20 their network, so they want multi-service devies. The issue is= then how best to=20 provide this. =20 - Someone from UUnet/MCI: BGP and IS-IS are sort of bread and but= ter for us.=20 They want these protocols to be solid. At one point when IPPPN = got added to=20 code base, it caused a major outage to their network, even thou= gh they didn't=20 use it. This is because it impacted the software on their machi= nes in a negative=20 way. Once you put a new feature into the box, particularly into= the same=20 protocol, will this cause a problem - possibly even if they don= 't use the feature?=20 They run the same code in the core as in the edge, even though = they don't=20 need the same features in the core. They can turn off a protoco= l, if things are in a separate protocol. Reply: You can turn off the address family. - Hamid (I think that this was Hamid Ould-Brahim): Before a routi= ng protocol=20 becomes a protocol, there is a set of problems that the working= group looks at.=20 If a different working group faces the same problems, then they= tend to select=20 the same solutions. He doesn't see a problem here. In many case= s when=20 distributing other sorts of information, you end up facing the = same problems.=20 Thus you may use the same solutions, such as using route reflec= tors. Thus you=20 can gain from experience. This is a natural way of solving pro= blems. - Lixia Zhang: Good software engineering can reduce the number of= bugs.=20 However, the number of bugs will grow faster than linearly. Mor= e modular=20 code will help. We are not just here to build protocols. - Pekka Savola: Do we want multiple services or not: In their net= work, then=20 definitely don't want them. Pedro: No vendor will build a produ= ct for a=20 single company, or even for a limited market segment. Enterpris= e features, X.25 tunneling features will get added. There is the potential = for impact. How do we design things in the most reasonable way to minimize = the=20 amount of new code which is needed to provide a certain set of = functions.=20 If you have one problem then if you re-invent the wheel.=20 - marlove(?): He is only three years out of college, and remember= s his=20 software engineer course: But I didn't get his point.=20 - Gargi: Whether or not it is a new protocol there may be some co= de re-usability.=20 - Luyuan Fang: I agree that there are two problems: Code and mis-= configuration.=20 Our configuration of BGP for Internet routing, and our configu= ration of VPN=20 services are separate. Thus having the same protocol does not r= equire having a=20 single configuration tool. Are we talking about multiple servic= es on one box, or a single service per box? They are putting multiple services on= one box. They=20 are going to consolidate even more. A University network might = not need as=20 many services. As a large service provider, they can't afford t= o put ten different=20 boxes into their network to support ten different services. Luy= uan feels we=20 should eave it up to the vendor to determine the best way to ma= ke this reliable=20 and robust. We can't stop progress, we need to standardize how = to offer the=20 multiple services on one box. It doesn't matter to them whether= it is one=20 protocol or multiple protocols. - Alex: in the life of a protocol, there will be times when you n= eed to think=20 carefully about whether or not you want to extend the protocol = further, or start new protocols. - Curt: We have enough to do operationally just to get packets fo= rwarded. I=20 am not so worried about adding more lines of code to the router= s. I am more=20 worried about having that code executed. I want to know what I = am running.=20 When we got the problem with BGP: We had the VPN code in the BG= P.=20 We got the problem because the code was delivered in the softwa= re. It was a vendor coding thing, but this is going to happen. Different B= GP=20 configuration has already been done with the consideration that= BGP is=20 only doing IP routing. Other services might have a different ch= aracteristics in terms of how rapidly data is updated / exchanged, hold down = timers, for example.=20 - Andrew(?): We need to separate concerns about bugs versus featu= res. Bugs=20 do happen. Don't let one particular bug that occurred in one im= plementation=20 obscure the entire conversation. The code has to evolve.=20 - someone from DT (Rahul Volk?): Talking about design or architec= tural principles sometimes get into fuzzy areas. Since Roman time, we= have=20 had divide and conquer as a principle. Using the protocol which= is already there to improve TTM doesn't seem right. There is a tradeoff be= tween=20 code reuse and speed of deployment, versus adapting the solutio= n for problems that are not foreseen.=20 - Pedro: Someone made a comment before regarding who pays the cos= t of adding functions. No customer has ever said "do it perfectly= , and we=20 will wait five years for it". If customers were to say this, we= will respond to it. Cost and who are willing to pay matters.=20 - Alex: If we look ten years ahead, do we want a very large numbe= r of=20 attractive features implemented in BGP, or do we want something= else. - Pedro: Ten years from now, there will be a protocol called BGP,= which will have almost no resemblance to what is there today. Unicast= routing will evolve over time. Technology goes in cycles. Today the sti= mulus is for VPNs. Next year it may be something else, and BGP will e= volve to handle this.=20 - Gargi: We will always have short term requests. This should not= preclude us from looking for a long term solution. Putting things into B= GP might be the correct long term solution, but we should investigate wh= ether this is the right thing to do.=20 - Ron: If we were doing BGP over again, we might want to design t= wo protocols, a generic data transfer protocol, and a routing prot= ocol which computes routes, and which uses the data exchange protocol to c= arry its=20 routing information.=20 - ?? (didn't get who): in the short term we have a set of vehicle= s and a=20 set of problems.=20 - Rahul Aggarwar: Three issues: (i) Protocol overload; (ii) imple= mentation=20 complexity / software engineering; (iii) Deployment issues. How= strongly coupled are the new features with the old features in BGP? Prob= ably not very. If we put new information into BGP and carry it around, i= s this a problem. =20 - Bill Fenner: There has been a lot of work on the stability of r= outes in BGP and the stability of inter-domain routing. If you put more thin= gs over the=20 same protocol, are you violating the original assumptions.=20 - Gargi: Just because you use a new SAFI, there is still some imp= act on the=20 overall BGP. Existing SAFI's may be effected.=20 - Rahul reply: He is making a distinction between code changes an= d protocol procedures.=20 - Dino: MSDP: Why was this not in BGP: Multiple service providers= said that they wanted it in BGP in order to make it easier to deploy= . Dino had a=20 concern that it might evolve after deployment, and that this mi= ght have future impacts on BGP which we can't anticipate. Also, if it fails, th= en it is easier to remove if it fails. If you want things stable, you can't change= it. Pedro=20 questioned whether this was an appropriate analogy.=20 - Yakov: If I follow your logic, then we should take multicast an= d IPv6 out of BGP, and have four protocols (unicast IPv4, multicast IPv4, = unicast IPv6, and multicast IPv6): - Dino: It is a cost-benefit tradeoff.=20 - Yakov: We agree that it is a cost-benefit tradeoff. BGP was des= igned to=20 carry 1,000 routes. BGP was not designed to carry CIDR, nor IPv= 6. BGP=20 carries much more than this today. It has evolved over time to = meet=20 new requirements. We have other precedents of putting multiple = things into=20 one protocol: Two such precedents are IP and TCP. In order to d= ecide what=20 should go into BGP and what should not go into BGP requires cos= t-benefit=20 analysis. If you want to add something which folds in well, you= do so. If=20 you want something that requires very different procedures, the= n you use a new protocol.=20 - Vach: Cost benefit analysis is a way to consider alternatives (= eg, use a=20 linked list or use a tree - this is a cost-benefit analysis). U= sing a flooding=20 protocol for information which doesn't need flooding is a good = example of a bad tradeoff.=20 - Chandra: We know that BGP can be extended to have multiple sess= ions=20 (eg, per-SAFI). BGP can therefore become a session demultiplexe= r. I am getting the feeling after listening to this that some people fe= el they can drive protocol implementation architecture by driving one or mu= ltiple=20 protocols. Panelist summaries: - Ron: software is about software extensibility and stability. Th= ese are=20 software engineering issues, and the IETF doesn't do software e= ngineering. Others have pointed out that we want modularity but we can't f= orce any particular software design by deciding what goes into what = protocol. This implies that we have a really hard problem.=20 - Dave: Wants to talk more about protocol design and less about s= oftware design. There is a tradeoff between features and bugs. We can't= get away from that. What is the effect on the Internet architecture. - Pedro: What are the concerns that people have? He would like to= get the concerns enumerated so that the concerns can be understood. - Gargi: Has heard concerns from operators that they want the cor= e Internet functionality to be solid, and not impacted by any additions. W= hether=20 something belongs in BGP needs to be handled on a case by case = basis.=20 Even though some things may look okay in BGP today, we also hav= e to=20 pay attention to whether this will belong in BGP in the future.= =20 Questions from Alex: - How many ISPs ? ~ 10 - Who thinks BGP overloading is not an issue ? ~ nobody - Who thinks BGP should not change at all ? ~ very few - Who believes we should pursue the direction of a new protocol potentially based on MP-BGP framework and used for distribution of generic non-routing related info among the routers? ~ lot of support _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Aug 5 18:14:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29386 for ; Tue, 5 Aug 2003 17:29:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k9Mb-0001EL-JP; Tue, 05 Aug 2003 17:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k9M2-0001D8-PM for routing-discussion@optimus.ietf.org; Tue, 05 Aug 2003 17:28:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29351 for ; Tue, 5 Aug 2003 17:28:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k9M0-00062n-00 for routing-discussion@ietf.org; Tue, 05 Aug 2003 17:28:24 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19k9Lz-00062k-00 for routing-discussion@ietf.org; Tue, 05 Aug 2003 17:28:23 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19k9Ly-00071m-Ja for routing-discussion@ietf.org; Tue, 05 Aug 2003 21:28:22 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <197112511873.20030805142816@psg.com> To: routing-discussion@ietf.org Subject: IETF-57 RTG area meeting minutes MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA29352 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 5 Aug 2003 14:28:16 -0700 Content-Transfer-Encoding: quoted-printable Thanks to Ross and Dimitri, minutes from the meeting below. Folks who were at the meeting--please review and let me know if something is so inaccurate it should be fixed. -- Alex Announcements (Bill Fenner) - RIP working group is finished and will be ended - There is a routing area website: www.rtg.ietf.org=20 - THere is a routing area mailing list: routing-discussion@ietf.o= rg=20 Working Group Reports IDR status (Sue Hares) - are in a holding patter until base spec is complete (are on -21= ) - see agenda for IDR working group IS-IS - no report Manet (Alex) - four protocol specification are going to experimental status=20 AODV was published as RFC 3561 others in progress (one recently reviewed) =20 Implementation is in progress Multicast Last Mile BOF - no report OSPF Status=20 - two RFCs (NSSA 3101; 3509) - five documents in working group last call or beyond - OSPF V2 TE is through to the RFC editors - BCP prioritization fo OSFP packets - refresh reduction in stable topologies - two mibs and v3 and authentication for V3 need more work - two new documents are just starting at this IETF MSDP - document done - MIB almost done PIM - three major drafts in progress - they have been pretty stable for a while - trying to arrange appropriate reviewers RPSec=20 - didn't meet SSM=20 - didn't meet at this IETF UDLR - no meeting (but status report) - 30 June, submitted revised version - Major changes from v00.txt (now v01.txt) . write PPPoE experiment . wrire PIM-SM and MSDP experiment . add NAT - IPv6 over UDLR . no exp i-d . 18 june, start discussion on mailing list . if there is common interest make a draft charter an propose t= o AD's VRRP - Radia Perlman is now co-chair of the group - security has been removed from VRRP after considerable discussi= on - v2 and v3 drafts have been updated. V2 is ready for WG last can= n as draft standard. VRRPv3 MIB has just been submitted to the worki= ng group, and needs review.=20 UDLR - no report IP Forwarding MIB (Brian) a while ago updated MIB support for IPv6 requested. Most of these are in last call in the IPv6 working group. A request: Why not fix other stuff, such as making it easier to support in today's forwarding engines? This work is starting now that the IPv6 is stable. Question to people designing forwarding engines: Is the current IP Forwarding MIB that is currently defined for IPv4 useful at all? If not, should we fix it now. Send opinions to Bill Fenner of the routing area mailing list. Panel: Routing Protocol Overload Panelists:=20 Dave Meyer =20 Pedro Marques Ron Bonica Gargi Nalawade =20 Introduction by Alex:=20 Why are we here: Community is polarized over use of routing protocols for uses which go somewhat beyond the narrow definition of routing (particularly wrt BGP). Alex would like to see the community talk. Alex characterized the two viewpoints as: Camp 1: - MP-BGP framework is a useful tool to distribute info among INET= routers - Fair treatment of different AFI/SAFI=92s is an implementation p= roblem - We know how to do this, leave this to us Camp 2: - This is dangerous. Risks the Internet. Any instability or code = complexity=20 caused by one use of BGP could destabilize the main purpose, wh= ich is=20 Internet inter-domain routing.=20 Alex would like us to walk out of this room with some understanding of where we are going. He would like us to find a common ground. Please respect other points of view. Please don't bring personality issues to the discussion. Don't just state your opinion, but instead explain the reason for the opinion. Panelists present their opinion: Dave Meyer: - Musings on NLRI loading, stability, and signaling in the Intern= et - It is hard to get hard evidence on what we ought to do. Maybe w= e need a study on the topic.=20 - BGP and maybe IGPs can form an effective transport for new features.=20 - BGP is also used in the Internet - BGP in the Internet can have stability issues in some cases. - It seems reasonable to ask what effect loading BGP with other i= nformation will have on routing stability. - Dave can't quantify anything about the stability. Dave has talk= ed to a lot=20 of people. Plusses: Operational simplification; Code Re-Use; BGP code will= be=20 carefully optimized. - Operational complexity: Worry about breaking one thing when doi= ng=20 something else. Single point of failure. Internal queue managem= ent=20 needed.=20 - Much of this is conjecture.=20 - What if we wanted to start from scratch: Would we want a genera= lized feature transport Mechanism? If so, is BGP this mechanism? As a= n example MSDP ended up looking a lot like BGP.=20 - Proposal: create problem statement. Draft Requirements, framewo= rk and architecture. Perhaps we should present a problem statement at = the next IETF.=20 Ron Bonica - Defining the scope of BGP - Background on the problem: Routers support many applications wh= ich require the synchronization of databases on multiple routers.=20 - BGP could support all of these applications.=20 - Ron echoed concerns that he has heard: Will BGP get buggy as we= make it=20 more complex? Is there a possibility of mis-configuration: As f= unctionality=20 increases, will information be leaked incorrectly between servi= ce providers,=20 and possibly be mis-interpreted?=20 - Mitigations for these concerns are available: BGP software is a= lready fairly modular. Data transfer is separate from other functions. This i= mplies that as we add more to BGP, we add new modules. Controls exist to prote= ct against=20 mis-configuration. - Big Bug issue: What if something really bad happens? - BGP incomprehensibility: What if it gets too big for a human to= understand? - Perhaps we should document BGP as a number of separate modules.= =20 - Options - restrict BGP to main use, and clone it for other reason= s - abstract data transfer from other parts - let BGP grow - None of these solutions are necessarily right.=20 - if clone, end up fixing same bugs in multiple code base= s and updating=20 code multiple times - We are on shaky ground in taking on this issue. Most of this di= scussion is about=20 software engineering. The IETF doesn't normally do software eng= ineering.=20 - Proposal: That we listen to vendors and operators. Study the is= sue.=20 Pedro Marques: - (Mostly agree with Dave. This is an issue to study) - Look at this from the point of view of System Availability in=20 Multiservice Networks - What is router availability? - What does it depend upon? - Is there is an impact on deploying a new service in the router?= Yes. - Don't just look at one component of this. Look at overall syste= m and network availability. The resource sharing issue surfaces whene= ver you introduce a new service on the router. However, resource sharin= g is also an issue when you have only IP Internet service (eg, sharing be= tween BGP and an IGP; sharing between multiple BGP neighbors, so that one= neighbor doesn't seriously impact another).=20 - System availability is a system design issue. There are signifi= cant software engineering aspects of this. System availability is generally i= mproved by=20 maximizing code re-use. This leads to fewer defects.=20 - The most problematic issue is internal infrastucture changes (i= nternal to the router). This is independent of the protocol issue, and indepen= dent of anything that we do in the IETF.=20 - If a given problem requires point to multipoint distribution of= information,=20 then re-use of BGP is more cost-effective than inventing a new = solution.=20 - Summary: Resource sharing is always an issue. This is not limit= ed to multi- service issues. There are serious issues here, but these are pr= imarily software engineering issues and therefore outside of the scope of the IE= TF.=20 Gargi Nalawade - Consider "Routing Protocol Overhead".=20 - What is BGP: A routing protocol, or a database distribution pro= tocol?=20 - If it is a routing protocol, should it be doing database distri= bution? - If it is a database distribution protocol, should it be doing r= outing? - BGP definitely does routing. If it does both, what % of its tas= k should be doing routing?=20 - Question is not whether BGP can do this, of course it can. But = the=20 question is whether BGP should do this.=20 - Routing related information which is closely tied to BGP must b= e carried in BGP.=20 - What's the solution: Identify the problem. What is routing rela= ted? Then we can talk about solutions.=20 - This is not just a BGP issue. IGPs carry opaque LSAs and/or=20 extensible TLV. Why have a BGP-specific solution. - She agreed with Pedro that cloning is bad for the health.=20 Open Discussion: - Yakov: Gargi's comment that she doesn't want BGP to carry Shake= speare is not relevant to the discussion. The decision should be based on= a cost/benefit=20 analysis, not on what she wants.=20 - Mark Handley: We might want to distinguish Protocol implementat= ion=20 overloading, versus protocol instance overloading, versus proto= col design=20 overloading. Instance is most important. We are talking about f= ate sharing;=20 If you have two services sharing the same protocol, then they s= hare the same fate. If two services need to be coupled then fine, but otherwi= se don't put=20 them in the same protocol instance. Congestion control sharing = is also=20 potentially an issue. Example from different world (SIP): SIP w= as designed to=20 operate over . Then SIP got instant messaging adde= d to it, then=20 it was realized that instant messaging included video, this was= too much,=20 then they fixed it by removing some features and handling them = otherwise.=20 - Chandra (from cisco): The concerns that people have expressed a= re not clearly articulated. Are we talking about overloading the protocol, ver= sus the=20 implementation, versus a protocol instance? These are not the s= ame, and=20 he doesn't know which one is the concern. Is this an issue of c= onfiguration=20 modules, or software implementation? If this is a configuration= issue, then=20 you can fix this as a configuration issue and not as a protocol= design issue.=20 - Dave Meyer wants to understand whether putting more into BGP ef= fects global Internet stability.=20 - Rahib: What if any impact will this have on the scalability of = the routing=20 protocol?=20 - Rob (Austein): Has spent time with DNS. When you keep adding fe= atures to a protocol, pay attention to who gets benefits and who suffe= rs the pain.=20 - Kurt (Lindqvist) We are getting lazy: We are trying to make it = easy by using the same protocol over and over. The threshold for adding thing= s to the=20 protocol is too low. Where does this end?=20 - Kireeti: Don't ask if you are overloading the protocol or syste= m. Ask about multiservice platforms: Is this a good idea? The resource conte= ntion comes from having multiple services on the same physical platform. Do= we want a=20 box doing IP, and a different box doing L2VPNs, and a differen= t box doing L3 VPNs, etc.. The issue is whether we put these in one box or = in multiple=20 boxes. If the box falls over, then you have taken down whatever= is on the=20 box. Putting multiple services on the same box will have an imp= act, and=20 therefore require careful implementation. Whether you put them = in the same=20 protocol is at the most a second order issue. It is normal for = reachability=20 information and routing information to be in a routing protocol= : An IP VPN prefix is reachability information. A layer 2 prefix is reachab= ility information.=20 - Ross Callon: Some have talked about software engineering, other= s have=20 expressed concerns about internet stability and a few said "I d= on't care about=20 software engineering, I care about Internet stability". We need= to understand that software engineering is a major impact on Internet stabili= ty, and thus the=20 people who are talking about software engineering are talking a= bout internet=20 stability, and are trying to address what is the most critical = part of Internet=20 stability. Using the same protocol does not preclude a careful = partitioning of=20 resources within a device, nor does it preclude using separate = TCP connections.=20 Using a different protocol does not guarantee using different r= esources: If=20 multiple services are in the same physical device, at some leve= l there will be=20 some sharing of resources. Therefore the primary issue is not t= he protocol. The=20 primary issue is the services on the box, and how much informat= ion needs to be=20 exchanged between the boxes. Adding new services to the box req= uires new=20 information. This will have some impact. Ross has heard comment= s from=20 multiple service providers that they don't want ten different t= ypes of boxes in=20 their network, so they want multi-service devies. The issue is= then how best to=20 provide this. =20 - Someone from UUnet/MCI: BGP and IS-IS are sort of bread and but= ter for us.=20 They want these protocols to be solid. At one point when IPPPN = got added to=20 code base, it caused a major outage to their network, even thou= gh they didn't=20 use it. This is because it impacted the software on their machi= nes in a negative=20 way. Once you put a new feature into the box, particularly into= the same=20 protocol, will this cause a problem - possibly even if they don= 't use the feature?=20 They run the same code in the core as in the edge, even though = they don't=20 need the same features in the core. They can turn off a protoco= l, if things are in a separate protocol. Reply: You can turn off the address family. - Hamid (I think that this was Hamid Ould-Brahim): Before a routi= ng protocol=20 becomes a protocol, there is a set of problems that the working= group looks at.=20 If a different working group faces the same problems, then they= tend to select=20 the same solutions. He doesn't see a problem here. In many case= s when=20 distributing other sorts of information, you end up facing the = same problems.=20 Thus you may use the same solutions, such as using route reflec= tors. Thus you=20 can gain from experience. This is a natural way of solving pro= blems. - Lixia Zhang: Good software engineering can reduce the number of= bugs.=20 However, the number of bugs will grow faster than linearly. Mor= e modular=20 code will help. We are not just here to build protocols. - Pekka Savola: Do we want multiple services or not: In their net= work, then=20 definitely don't want them. Pedro: No vendor will build a produ= ct for a=20 single company, or even for a limited market segment. Enterpris= e features, X.25 tunneling features will get added. There is the potential = for impact. How do we design things in the most reasonable way to minimize = the=20 amount of new code which is needed to provide a certain set of = functions.=20 If you have one problem then if you re-invent the wheel.=20 - marlove(?): He is only three years out of college, and remember= s his=20 software engineer course: But I didn't get his point.=20 - Gargi: Whether or not it is a new protocol there may be some co= de re-usability.=20 - Luyuan Fang: I agree that there are two problems: Code and mis-= configuration.=20 Our configuration of BGP for Internet routing, and our configu= ration of VPN=20 services are separate. Thus having the same protocol does not r= equire having a=20 single configuration tool. Are we talking about multiple servic= es on one box, or a single service per box? They are putting multiple services on= one box. They=20 are going to consolidate even more. A University network might = not need as=20 many services. As a large service provider, they can't afford t= o put ten different=20 boxes into their network to support ten different services. Luy= uan feels we=20 should eave it up to the vendor to determine the best way to ma= ke this reliable=20 and robust. We can't stop progress, we need to standardize how = to offer the=20 multiple services on one box. It doesn't matter to them whether= it is one=20 protocol or multiple protocols. - Alex: in the life of a protocol, there will be times when you n= eed to think=20 carefully about whether or not you want to extend the protocol = further, or start new protocols. - Curt: We have enough to do operationally just to get packets fo= rwarded. I=20 am not so worried about adding more lines of code to the router= s. I am more=20 worried about having that code executed. I want to know what I = am running.=20 When we got the problem with BGP: We had the VPN code in the BG= P.=20 We got the problem because the code was delivered in the softwa= re. It was a vendor coding thing, but this is going to happen. Different B= GP=20 configuration has already been done with the consideration that= BGP is=20 only doing IP routing. Other services might have a different ch= aracteristics in terms of how rapidly data is updated / exchanged, hold down = timers, for example.=20 - Andrew(?): We need to separate concerns about bugs versus featu= res. Bugs=20 do happen. Don't let one particular bug that occurred in one im= plementation=20 obscure the entire conversation. The code has to evolve.=20 - someone from DT (Rahul Volk?): Talking about design or architec= tural principles sometimes get into fuzzy areas. Since Roman time, we= have=20 had divide and conquer as a principle. Using the protocol which= is already there to improve TTM doesn't seem right. There is a tradeoff be= tween=20 code reuse and speed of deployment, versus adapting the solutio= n for problems that are not foreseen.=20 - Pedro: Someone made a comment before regarding who pays the cos= t of adding functions. No customer has ever said "do it perfectly= , and we=20 will wait five years for it". If customers were to say this, we= will respond to it. Cost and who are willing to pay matters.=20 - Alex: If we look ten years ahead, do we want a very large numbe= r of=20 attractive features implemented in BGP, or do we want something= else. - Pedro: Ten years from now, there will be a protocol called BGP,= which will have almost no resemblance to what is there today. Unicast= routing will evolve over time. Technology goes in cycles. Today the sti= mulus is for VPNs. Next year it may be something else, and BGP will e= volve to handle this.=20 - Gargi: We will always have short term requests. This should not= preclude us from looking for a long term solution. Putting things into B= GP might be the correct long term solution, but we should investigate wh= ether this is the right thing to do.=20 - Ron: If we were doing BGP over again, we might want to design t= wo protocols, a generic data transfer protocol, and a routing prot= ocol which computes routes, and which uses the data exchange protocol to c= arry its=20 routing information.=20 - ?? (didn't get who): in the short term we have a set of vehicle= s and a=20 set of problems.=20 - Rahul Aggarwar: Three issues: (i) Protocol overload; (ii) imple= mentation=20 complexity / software engineering; (iii) Deployment issues. How= strongly coupled are the new features with the old features in BGP? Prob= ably not very. If we put new information into BGP and carry it around, i= s this a problem. =20 - Bill Fenner: There has been a lot of work on the stability of r= outes in BGP and the stability of inter-domain routing. If you put more thin= gs over the=20 same protocol, are you violating the original assumptions.=20 - Gargi: Just because you use a new SAFI, there is still some imp= act on the=20 overall BGP. Existing SAFI's may be effected.=20 - Rahul reply: He is making a distinction between code changes an= d protocol procedures.=20 - Dino: MSDP: Why was this not in BGP: Multiple service providers= said that they wanted it in BGP in order to make it easier to deploy= . Dino had a=20 concern that it might evolve after deployment, and that this mi= ght have future impacts on BGP which we can't anticipate. Also, if it fails, th= en it is easier to remove if it fails. If you want things stable, you can't change= it. Pedro=20 questioned whether this was an appropriate analogy.=20 - Yakov: If I follow your logic, then we should take multicast an= d IPv6 out of BGP, and have four protocols (unicast IPv4, multicast IPv4, = unicast IPv6, and multicast IPv6): - Dino: It is a cost-benefit tradeoff.=20 - Yakov: We agree that it is a cost-benefit tradeoff. BGP was des= igned to=20 carry 1,000 routes. BGP was not designed to carry CIDR, nor IPv= 6. BGP=20 carries much more than this today. It has evolved over time to = meet=20 new requirements. We have other precedents of putting multiple = things into=20 one protocol: Two such precedents are IP and TCP. In order to d= ecide what=20 should go into BGP and what should not go into BGP requires cos= t-benefit=20 analysis. If you want to add something which folds in well, you= do so. If=20 you want something that requires very different procedures, the= n you use a new protocol.=20 - Vach: Cost benefit analysis is a way to consider alternatives (= eg, use a=20 linked list or use a tree - this is a cost-benefit analysis). U= sing a flooding=20 protocol for information which doesn't need flooding is a good = example of a bad tradeoff.=20 - Chandra: We know that BGP can be extended to have multiple sess= ions=20 (eg, per-SAFI). BGP can therefore become a session demultiplexe= r. I am getting the feeling after listening to this that some people fe= el they can drive protocol implementation architecture by driving one or mu= ltiple=20 protocols. Panelist summaries: - Ron: software is about software extensibility and stability. Th= ese are=20 software engineering issues, and the IETF doesn't do software e= ngineering. Others have pointed out that we want modularity but we can't f= orce any particular software design by deciding what goes into what = protocol. This implies that we have a really hard problem.=20 - Dave: Wants to talk more about protocol design and less about s= oftware design. There is a tradeoff between features and bugs. We can't= get away from that. What is the effect on the Internet architecture. - Pedro: What are the concerns that people have? He would like to= get the concerns enumerated so that the concerns can be understood. - Gargi: Has heard concerns from operators that they want the cor= e Internet functionality to be solid, and not impacted by any additions. W= hether=20 something belongs in BGP needs to be handled on a case by case = basis.=20 Even though some things may look okay in BGP today, we also hav= e to=20 pay attention to whether this will belong in BGP in the future.= =20 Questions from Alex: - How many ISPs ? ~ 10 - Who thinks BGP overloading is not an issue ? ~ nobody - Who thinks BGP should not change at all ? ~ very few - Who believes we should pursue the direction of a new protocol potentially based on MP-BGP framework and used for distribution of generic non-routing related info among the routers? ~ lot of support _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 01:51:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09892 for ; Wed, 6 Aug 2003 01:51:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHCP-0006NH-M1; Wed, 06 Aug 2003 01:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHCL-0006N2-NC for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 01:50:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09853 for ; Wed, 6 Aug 2003 01:50:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kHCI-0000Wv-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 01:50:54 -0400 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19kHCH-0000Wq-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 01:50:53 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HJ600D01O7SCD@mailout1.samsung.com> for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:50:16 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HJ600GTIO7S46@mailout1.samsung.com> for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:50:16 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HJ6009DEO7LBQ@mmp1.samsung.com> for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:50:16 +0900 (KST) From: Manav Bhatia Subject: Re: IETF-57 RTG area meeting minutes To: Alex Zinin , routing-discussion@ietf.org Reply-to: Manav Bhatia Message-id: <07aa01c35bdd$bdf16600$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <197112511873.20030805142816@psg.com> Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 11:13:56 +0530 Content-Transfer-Encoding: 7BIT > - marlove(?): He is only three years out of college, and remembers > his software engineer course: But I didn't get his point. My point was that reusability in software engineering doesn't mean that if I have an existing module A and I want to develop a new (and a potentially different) module B then we "reuse" A and pile *all* the functions of B on top of A. What "reusability" *generally* means is that we "reuse" most of the code/design/test data/knowledge from module A to implement the new module B. Reusability is not a concept that is limited to the coding phase of the software life-cycle. It starts from the requirements analysis and extends till the retirement of the product/feature. E.g. Defining and implementing good classes/objects in an OOPs design, so that these can be "reused" for other modules would be a good example of what software engineering really advocates. This was in response to what Pedro kept repeating in his presentation on why we should put all the new features on top of BGP and to the impressive number of google "hits" he had shown on "reusability" in Software Engineering !! :-) Please note that I am *not* against using BGP for "other" things. All I wanted was to point out, that his argument wasn't really correct .. atleast not academically! ~Manav _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 01:51:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09904 for ; Wed, 6 Aug 2003 01:51:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHCg-0006OB-OB for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 01:51:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h765pIO3024553 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 01:51:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHCP-0006NH-M1; Wed, 06 Aug 2003 01:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHCL-0006N2-NC for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 01:50:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09853 for ; Wed, 6 Aug 2003 01:50:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kHCI-0000Wv-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 01:50:54 -0400 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19kHCH-0000Wq-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 01:50:53 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HJ600D01O7SCD@mailout1.samsung.com> for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:50:16 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HJ600GTIO7S46@mailout1.samsung.com> for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:50:16 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HJ6009DEO7LBQ@mmp1.samsung.com> for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:50:16 +0900 (KST) From: Manav Bhatia Subject: Re: IETF-57 RTG area meeting minutes To: Alex Zinin , routing-discussion@ietf.org Reply-to: Manav Bhatia Message-id: <07aa01c35bdd$bdf16600$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <197112511873.20030805142816@psg.com> Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 11:13:56 +0530 Content-Transfer-Encoding: 7BIT > - marlove(?): He is only three years out of college, and remembers > his software engineer course: But I didn't get his point. My point was that reusability in software engineering doesn't mean that if I have an existing module A and I want to develop a new (and a potentially different) module B then we "reuse" A and pile *all* the functions of B on top of A. What "reusability" *generally* means is that we "reuse" most of the code/design/test data/knowledge from module A to implement the new module B. Reusability is not a concept that is limited to the coding phase of the software life-cycle. It starts from the requirements analysis and extends till the retirement of the product/feature. E.g. Defining and implementing good classes/objects in an OOPs design, so that these can be "reused" for other modules would be a good example of what software engineering really advocates. This was in response to what Pedro kept repeating in his presentation on why we should put all the new features on top of BGP and to the impressive number of google "hits" he had shown on "reusability" in Software Engineering !! :-) Please note that I am *not* against using BGP for "other" things. All I wanted was to point out, that his argument wasn't really correct .. atleast not academically! ~Manav _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 10:02:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16677 for ; Wed, 6 Aug 2003 10:02:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOra-0006T7-Bp; Wed, 06 Aug 2003 10:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOqo-0006R9-W0 for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 10:01:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16651 for ; Wed, 6 Aug 2003 10:01:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kOqm-00031y-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:01:12 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kOqm-00031X-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:01:12 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76E0eu58144; Wed, 6 Aug 2003 07:00:40 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061400.h76E0eu58144@merlot.juniper.net> To: Danny McPherson cc: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: Your message of "Wed, 30 Jul 2003 12:16:15 MDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <87058.1060178440.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 07:00:40 -0700 Danny, [clipped...] > On the topic of RP overloading... > > There are [some] very real problems folks are attempting to address and > given MP-BGP & BGP-CAP, BGP has been the easy answer. Heck, with IGP > Capabilities being defined we'll be able to do more things even faster > (although I'm kidding, be wary :-) The discussion should certainly include extensions to ISIS, like carrying both IPv4 and IPv6 unicast routing, IPv4 unicast routes used by IPv4 multicast, IPv6 unicast routes used by IPv6 multicast, using ISIS Extensions for BGP Peer Discovery, using ISIS flooding procedures to carry TE information. With this in mind I'd like to hear from the folks who argue against adding more stuff in BGP whether they also object against adding more stuff into ISIS. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 10:42:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19029 for ; Wed, 6 Aug 2003 10:42:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPUK-000089-Ko for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 10:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Eg4c8000494 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 10:42:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPUI-00007h-09; Wed, 06 Aug 2003 10:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPTZ-00006N-5n for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 10:41:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18993 for ; Wed, 6 Aug 2003 10:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPTW-0003JM-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:41:14 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kPTV-0003Iq-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:41:13 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76EeYu60088; Wed, 6 Aug 2003 07:40:34 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061440.h76EeYu60088@merlot.juniper.net> To: Alex Zinin cc: Eric Rosen , Danny McPherson , routing-discussion@ietf.org Subject: Re: Extending BGP In-Reply-To: Your message of "Tue, 29 Jul 2003 13:07:53 PDT." <185484051248.20030729130753@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97212.1060180834.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 07:40:34 -0700 Alex, > Eric, > > > I wasn't in Vienna, but let me put in my two cents on why it sometimes makes > > sense to use BGP for distributing non-routing information. Basically, I > > think you need to look at the specific requirements for distributing that > > information. (Yes, I know this isn't as much fun as making broad > > generalizations ;-)) > > > Consider a set of routers S such that: > > > - Members of S know apriori that they are members of S, but they do not know > > apriori which other routers are members of S. > > - S is divided into subsets (not necessarily disjoint) such that all members > > of a subset share a certain attribute. Thus for attribute A, we can speak > > of the A-subset of S. > > - Each member of S is configured with a set of "export attributes", and a > > set of "import attributes". > > - If a router in S is configured with export attribute E, it is a member of > > the E-subset. > > > - If a router in S is configured with import attribute I, it needs to learn > > the membership of the I-subset. > > - The set of import and/or export attributes with which a router is > > configured may change at any time; changes in the membership of the > > various A-subsets should be learned within minutes. > > - The changes do not occur with great frequency. > > - The total number of attributes under consideration may be very large. > > - Members of S cannot be assumed to be in the same Autonomous System, nor > > can they necessarily be assumed to be under the control of the same > > administration. > > > > Now we need a protocol which detects changes in the A-subsets and > > distributes these changes. What requirements can be put on such a protocol: > > - It has to provide a way for a router to announce that it has acquired a > > new export attribute. (Call this an "update" operation.) > > - It has to provide a way for a router to announce that it has lost an > > export attribute. (Call this a "withdraw" operation.) > > - For scalability, we prefer that routers which are not in S are not > > impacted by any of this; in particular, they should not need to maintain > > any state which is specific to S or any of its subsets. > > > Since the members of S do not know each other apriori, one might expect that > > there will be a server involved, where the members of S talk to the server, > > and the server redistributes the information as necessary. Of course, we > > usually want to have each router talking to two servers, with the servers > > also updating each other. And to make sure the whole system scales up, we'd > > like to be able to have servers with different sets of "clients" talking to > > each other. Since we may be passing large amounts of information over > > arbitrary network paths, we need to have a reliable, flow controlled > > transport, and it would be nice if the transport handled congestion control > > as well. A point-to-point transport between clients and servers seems the > > best fit, given that we don't want to burden any of S's non-members with > > S-specific state. > > > To further improve scalability, we'd like to be able to have each client > > tell its server(s) its set of import attributes, so that a given router only > > receives the information in which it is interested. (Call this "outbound > > attribute filtering".) If we have servers talking to servers, it would be > > nice to have the outbound attribute filtering passed around the servers in > > some loop-free manner, but we can leave that for further study. > > Thanks! Really great summary of the required functionality! > This is at least what I would have in mind. > > > If you put all these requirements together, and look for an existing > > protocol to satisfy them, you are inevitably led to BGP. The salient issue > > is not whether the attributes that need to be distributed are part of > > "routing", but whether the requirements for the distribution of these > > attributes are very similar to the requirements for the distribution of > > inter-domain routing information. We are led to BGP because of a similarity > > in the distribution requirements, not necessarily because of a similarity in > > the information distributed. > > > Many alternatives have been suggested in the past, but most of them just > > make BGP look even better ;-) > > And that's why, if we follow the direction of instantiating a separate > protocol, it would most probably inherit a lot from MP-BGP. I.e., the > idea is that it would have a very similar framework, though work over > a different TCP port number, and would live its own life with > independent (from BGP) features, extensions, optimizations, etc. > > [from your thread with Jon:] > > Jon>> for a start you create other reasons why BGP speakers might get > Jon>> overloaded, might get attacked, might get misconfigured, and might > Jon>> never converge > > > > Any time you use a protocol to distribute information, you create these > > possibilities, it's nothing to do with what protocol you're using. > > I think the argument here is about risk assessment and management. > > Though it is possible to do a fine job of clearly separating different > applications of the same protocol within the system, using a separate > protocol makes it much more likely to happen. Following your logic one should have a separate protocol per application, each with "its own life with independent (from BGP) features, extensions optimizations, etc." Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 10:44:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19110 for ; Wed, 6 Aug 2003 10:44:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPWD-0000T5-U3 for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 10:44:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Ei15c001779 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 10:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPWD-0000Pu-4l; Wed, 06 Aug 2003 10:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPVo-0000PW-PQ for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 10:43:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19085 for ; Wed, 6 Aug 2003 10:43:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPVm-0003KM-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:43:34 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kPVl-0003Jv-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:43:33 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76Egtu60188; Wed, 6 Aug 2003 07:42:55 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061442.h76Egtu60188@merlot.juniper.net> To: Alex Zinin cc: Eric Rosen , Danny McPherson , routing-discussion@ietf.org Subject: Re: Extending BGP In-Reply-To: Your message of "Tue, 29 Jul 2003 13:07:53 PDT." <185484051248.20030729130753@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97753.1060180975.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 07:42:55 -0700 Alex, [clipped...] > [from your thread with Jon:] > > Jon>> for a start you create other reasons why BGP speakers might get > Jon>> overloaded, might get attacked, might get misconfigured, and might > Jon>> never converge > > > > Any time you use a protocol to distribute information, you create these > > possibilities, it's nothing to do with what protocol you're using. > > I think the argument here is about risk assessment and management. > > Though it is possible to do a fine job of clearly separating different > applications of the same protocol within the system, using a separate > protocol makes it much more likely to happen. Since you agree that it is quite possible "to do a fine job of clearly separating different applications of the same protocol within the system", let me suggest that the folks who are capable of doing such "fine job" should continue doing this, while the folks who need a separate protocol to make this happen should pursue the avenue of the separate protocol per application. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 10:51:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16679 for ; Wed, 6 Aug 2003 10:02:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOrp-0006UX-53 for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 10:02:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76E2HhZ024933 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 10:02:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOra-0006T7-Bp; Wed, 06 Aug 2003 10:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOqo-0006R9-W0 for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 10:01:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16651 for ; Wed, 6 Aug 2003 10:01:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kOqm-00031y-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:01:12 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kOqm-00031X-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:01:12 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76E0eu58144; Wed, 6 Aug 2003 07:00:40 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061400.h76E0eu58144@merlot.juniper.net> To: Danny McPherson cc: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: Your message of "Wed, 30 Jul 2003 12:16:15 MDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <87058.1060178440.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 07:00:40 -0700 Danny, [clipped...] > On the topic of RP overloading... > > There are [some] very real problems folks are attempting to address and > given MP-BGP & BGP-CAP, BGP has been the easy answer. Heck, with IGP > Capabilities being defined we'll be able to do more things even faster > (although I'm kidding, be wary :-) The discussion should certainly include extensions to ISIS, like carrying both IPv4 and IPv6 unicast routing, IPv4 unicast routes used by IPv4 multicast, IPv6 unicast routes used by IPv6 multicast, using ISIS Extensions for BGP Peer Discovery, using ISIS flooding procedures to carry TE information. With this in mind I'd like to hear from the folks who argue against adding more stuff in BGP whether they also object against adding more stuff into ISIS. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 11:07:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19897 for ; Wed, 6 Aug 2003 11:07:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPsT-0000t1-Vj; Wed, 06 Aug 2003 11:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPrW-0000s9-Fo for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 11:06:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19561 for ; Wed, 6 Aug 2003 11:05:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPrT-0003QS-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:05:59 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19kPrS-0003QG-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:05:58 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h76F5S2W004836; Wed, 6 Aug 2003 11:05:28 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h76F5KLu004823; Wed, 6 Aug 2003 11:05:20 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h76F5F028614; Wed, 6 Aug 2003 11:05:15 -0400 (EDT) From: Jeffrey Haas To: Yakov Rekhter Cc: Danny McPherson , routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: <20030806110514.C7860@nexthop.com> References: <200308061400.h76E0eu58144@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200308061400.h76E0eu58144@merlot.juniper.net>; from yakov@juniper.net on Wed, Aug 06, 2003 at 07:00:40AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 11:05:14 -0400 On Wed, Aug 06, 2003 at 07:00:40AM -0700, Yakov Rekhter wrote: > With this in mind I'd like to hear from the folks who argue against > adding more stuff in BGP whether they also object against adding > more stuff into ISIS. As I think I've mentioned before, I think we each have reactions much like the DNS folk who continually find stuff being shoved into their working infrastructure. (not specifically to Yakov) Is there any way we can just frame this conversation as "how do we keep from breaking things when we're working on extended them"? -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 11:07:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19898 for ; Wed, 6 Aug 2003 11:07:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPsq-00012m-W3 for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 11:07:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76F7OVc003977 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 11:07:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPsT-0000t1-Vj; Wed, 06 Aug 2003 11:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPrW-0000s9-Fo for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 11:06:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19561 for ; Wed, 6 Aug 2003 11:05:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPrT-0003QS-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:05:59 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19kPrS-0003QG-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:05:58 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h76F5S2W004836; Wed, 6 Aug 2003 11:05:28 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h76F5KLu004823; Wed, 6 Aug 2003 11:05:20 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h76F5F028614; Wed, 6 Aug 2003 11:05:15 -0400 (EDT) From: Jeffrey Haas To: Yakov Rekhter Cc: Danny McPherson , routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: <20030806110514.C7860@nexthop.com> References: <200308061400.h76E0eu58144@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200308061400.h76E0eu58144@merlot.juniper.net>; from yakov@juniper.net on Wed, Aug 06, 2003 at 07:00:40AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 11:05:14 -0400 On Wed, Aug 06, 2003 at 07:00:40AM -0700, Yakov Rekhter wrote: > With this in mind I'd like to hear from the folks who argue against > adding more stuff in BGP whether they also object against adding > more stuff into ISIS. As I think I've mentioned before, I think we each have reactions much like the DNS folk who continually find stuff being shoved into their working infrastructure. (not specifically to Yakov) Is there any way we can just frame this conversation as "how do we keep from breaking things when we're working on extended them"? -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 11:15:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20852 for ; Wed, 6 Aug 2003 11:15:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQ0J-0001YX-G0 for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 11:15:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76FF7e9005954 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 11:15:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQ0D-0001XC-EX; Wed, 06 Aug 2003 11:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPzO-0001Sr-4u for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 11:14:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20692 for ; Wed, 6 Aug 2003 11:14:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPzN-0003kr-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:14:09 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kPzM-0003iX-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:14:08 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76FDUu61724; Wed, 6 Aug 2003 08:13:30 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061513.h76FDUu61724@merlot.juniper.net> To: Alex Zinin cc: Robert Raszuk , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Tue, 29 Jul 2003 17:35:46 PDT." <27500124180.20030729173546@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6085.1060182810.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 08:13:30 -0700 Alex, [clipped...] > The point is that I agree that the MP-BGP framework is a good match > for the required functionality, however the number of concerns we have > heard suggest that it may not be THE right choice in the long run. We also heard for quite some time that for the Internet inter-domain routing BGP "may not be THE right choice in the long run". With this in mind I would suggest for folks interested in "THE right choice in the long run" to stop arguing against adding more stuff to BGP, and instead join the folks working on "THE right choice in the long run" for the Internet inter-domain routing. Yakov. P.S. For those interested in the current status of the work on "THE right choice in the long run" for the Internet inter-domain routing I am happy to report that this work, aka as a LTSFGTC (Long Term Solution For Generations To Come), is in progress and is expected to be published in RFC100000. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 11:31:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19111 for ; Wed, 6 Aug 2003 10:44:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPWD-0000Pu-4l; Wed, 06 Aug 2003 10:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPVo-0000PW-PQ for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 10:43:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19085 for ; Wed, 6 Aug 2003 10:43:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPVm-0003KM-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:43:34 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kPVl-0003Jv-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:43:33 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76Egtu60188; Wed, 6 Aug 2003 07:42:55 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061442.h76Egtu60188@merlot.juniper.net> To: Alex Zinin cc: Eric Rosen , Danny McPherson , routing-discussion@ietf.org Subject: Re: Extending BGP In-Reply-To: Your message of "Tue, 29 Jul 2003 13:07:53 PDT." <185484051248.20030729130753@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97753.1060180975.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 07:42:55 -0700 Alex, [clipped...] > [from your thread with Jon:] > > Jon>> for a start you create other reasons why BGP speakers might get > Jon>> overloaded, might get attacked, might get misconfigured, and might > Jon>> never converge > > > > Any time you use a protocol to distribute information, you create these > > possibilities, it's nothing to do with what protocol you're using. > > I think the argument here is about risk assessment and management. > > Though it is possible to do a fine job of clearly separating different > applications of the same protocol within the system, using a separate > protocol makes it much more likely to happen. Since you agree that it is quite possible "to do a fine job of clearly separating different applications of the same protocol within the system", let me suggest that the folks who are capable of doing such "fine job" should continue doing this, while the folks who need a separate protocol to make this happen should pursue the avenue of the separate protocol per application. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 11:31:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19030 for ; Wed, 6 Aug 2003 10:42:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPUI-00007h-09; Wed, 06 Aug 2003 10:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPTZ-00006N-5n for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 10:41:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18993 for ; Wed, 6 Aug 2003 10:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPTW-0003JM-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:41:14 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kPTV-0003Iq-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 10:41:13 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76EeYu60088; Wed, 6 Aug 2003 07:40:34 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061440.h76EeYu60088@merlot.juniper.net> To: Alex Zinin cc: Eric Rosen , Danny McPherson , routing-discussion@ietf.org Subject: Re: Extending BGP In-Reply-To: Your message of "Tue, 29 Jul 2003 13:07:53 PDT." <185484051248.20030729130753@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97212.1060180834.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 07:40:34 -0700 Alex, > Eric, > > > I wasn't in Vienna, but let me put in my two cents on why it sometimes makes > > sense to use BGP for distributing non-routing information. Basically, I > > think you need to look at the specific requirements for distributing that > > information. (Yes, I know this isn't as much fun as making broad > > generalizations ;-)) > > > Consider a set of routers S such that: > > > - Members of S know apriori that they are members of S, but they do not know > > apriori which other routers are members of S. > > - S is divided into subsets (not necessarily disjoint) such that all members > > of a subset share a certain attribute. Thus for attribute A, we can speak > > of the A-subset of S. > > - Each member of S is configured with a set of "export attributes", and a > > set of "import attributes". > > - If a router in S is configured with export attribute E, it is a member of > > the E-subset. > > > - If a router in S is configured with import attribute I, it needs to learn > > the membership of the I-subset. > > - The set of import and/or export attributes with which a router is > > configured may change at any time; changes in the membership of the > > various A-subsets should be learned within minutes. > > - The changes do not occur with great frequency. > > - The total number of attributes under consideration may be very large. > > - Members of S cannot be assumed to be in the same Autonomous System, nor > > can they necessarily be assumed to be under the control of the same > > administration. > > > > Now we need a protocol which detects changes in the A-subsets and > > distributes these changes. What requirements can be put on such a protocol: > > - It has to provide a way for a router to announce that it has acquired a > > new export attribute. (Call this an "update" operation.) > > - It has to provide a way for a router to announce that it has lost an > > export attribute. (Call this a "withdraw" operation.) > > - For scalability, we prefer that routers which are not in S are not > > impacted by any of this; in particular, they should not need to maintain > > any state which is specific to S or any of its subsets. > > > Since the members of S do not know each other apriori, one might expect that > > there will be a server involved, where the members of S talk to the server, > > and the server redistributes the information as necessary. Of course, we > > usually want to have each router talking to two servers, with the servers > > also updating each other. And to make sure the whole system scales up, we'd > > like to be able to have servers with different sets of "clients" talking to > > each other. Since we may be passing large amounts of information over > > arbitrary network paths, we need to have a reliable, flow controlled > > transport, and it would be nice if the transport handled congestion control > > as well. A point-to-point transport between clients and servers seems the > > best fit, given that we don't want to burden any of S's non-members with > > S-specific state. > > > To further improve scalability, we'd like to be able to have each client > > tell its server(s) its set of import attributes, so that a given router only > > receives the information in which it is interested. (Call this "outbound > > attribute filtering".) If we have servers talking to servers, it would be > > nice to have the outbound attribute filtering passed around the servers in > > some loop-free manner, but we can leave that for further study. > > Thanks! Really great summary of the required functionality! > This is at least what I would have in mind. > > > If you put all these requirements together, and look for an existing > > protocol to satisfy them, you are inevitably led to BGP. The salient issue > > is not whether the attributes that need to be distributed are part of > > "routing", but whether the requirements for the distribution of these > > attributes are very similar to the requirements for the distribution of > > inter-domain routing information. We are led to BGP because of a similarity > > in the distribution requirements, not necessarily because of a similarity in > > the information distributed. > > > Many alternatives have been suggested in the past, but most of them just > > make BGP look even better ;-) > > And that's why, if we follow the direction of instantiating a separate > protocol, it would most probably inherit a lot from MP-BGP. I.e., the > idea is that it would have a very similar framework, though work over > a different TCP port number, and would live its own life with > independent (from BGP) features, extensions, optimizations, etc. > > [from your thread with Jon:] > > Jon>> for a start you create other reasons why BGP speakers might get > Jon>> overloaded, might get attacked, might get misconfigured, and might > Jon>> never converge > > > > Any time you use a protocol to distribute information, you create these > > possibilities, it's nothing to do with what protocol you're using. > > I think the argument here is about risk assessment and management. > > Though it is possible to do a fine job of clearly separating different > applications of the same protocol within the system, using a separate > protocol makes it much more likely to happen. Following your logic one should have a separate protocol per application, each with "its own life with independent (from BGP) features, extensions optimizations, etc." Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 11:51:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22059 for ; Wed, 6 Aug 2003 11:51:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQZ4-0002wG-Ok; Wed, 06 Aug 2003 11:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQYK-0002vM-2P for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 11:50:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22024 for ; Wed, 6 Aug 2003 11:50:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQYI-000439-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:50:14 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kQYH-00042u-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:50:14 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76Fn9u63757; Wed, 6 Aug 2003 08:49:09 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061549.h76Fn9u63757@merlot.juniper.net> To: Randy Bush cc: Eric Rosen , Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Wed, 30 Jul 2003 10:07:21 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15148.1060184949.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 08:49:09 -0700 Randy, > > you stop pretending to speak for all service providers, and I won't > > pretend to speak for all vendors ;-) > > no problem, when you actually listen to all the operators actually > in the room let's also keep in mind the number of operators "actually present in the room" vs the number of service providers worldwide. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 11:51:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22064 for ; Wed, 6 Aug 2003 11:51:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQZH-0002xg-Py for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 11:51:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76FpFFo011361 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 11:51:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQZ4-0002wG-Ok; Wed, 06 Aug 2003 11:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQYK-0002vM-2P for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 11:50:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22024 for ; Wed, 6 Aug 2003 11:50:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQYI-000439-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:50:14 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kQYH-00042u-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:50:14 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76Fn9u63757; Wed, 6 Aug 2003 08:49:09 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061549.h76Fn9u63757@merlot.juniper.net> To: Randy Bush cc: Eric Rosen , Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Wed, 30 Jul 2003 10:07:21 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15148.1060184949.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 08:49:09 -0700 Randy, > > you stop pretending to speak for all service providers, and I won't > > pretend to speak for all vendors ;-) > > no problem, when you actually listen to all the operators actually > in the room let's also keep in mind the number of operators "actually present in the room" vs the number of service providers worldwide. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 12:01:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20851 for ; Wed, 6 Aug 2003 11:15:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQ0D-0001XC-EX; Wed, 06 Aug 2003 11:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPzO-0001Sr-4u for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 11:14:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20692 for ; Wed, 6 Aug 2003 11:14:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPzN-0003kr-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:14:09 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kPzM-0003iX-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 11:14:08 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76FDUu61724; Wed, 6 Aug 2003 08:13:30 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061513.h76FDUu61724@merlot.juniper.net> To: Alex Zinin cc: Robert Raszuk , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Tue, 29 Jul 2003 17:35:46 PDT." <27500124180.20030729173546@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6085.1060182810.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 08:13:30 -0700 Alex, [clipped...] > The point is that I agree that the MP-BGP framework is a good match > for the required functionality, however the number of concerns we have > heard suggest that it may not be THE right choice in the long run. We also heard for quite some time that for the Internet inter-domain routing BGP "may not be THE right choice in the long run". With this in mind I would suggest for folks interested in "THE right choice in the long run" to stop arguing against adding more stuff to BGP, and instead join the folks working on "THE right choice in the long run" for the Internet inter-domain routing. Yakov. P.S. For those interested in the current status of the work on "THE right choice in the long run" for the Internet inter-domain routing I am happy to report that this work, aka as a LTSFGTC (Long Term Solution For Generations To Come), is in progress and is expected to be published in RFC100000. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 12:16:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22836 for ; Wed, 6 Aug 2003 12:16:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQxE-0004Ni-UQ; Wed, 06 Aug 2003 12:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQwK-0004Mn-0D for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 12:15:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22795 for ; Wed, 6 Aug 2003 12:14:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQwI-0004FH-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:15:02 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kQwH-0004Ew-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:15:02 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76GEFu65373; Wed, 6 Aug 2003 09:14:15 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061614.h76GEFu65373@merlot.juniper.net> To: Dorian Kim cc: Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Wed, 30 Jul 2003 17:31:16 EDT." <20030730213116.GB12046@blackrose.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22117.1060186455.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 09:14:15 -0700 Dorian, [clipped..] > Along the same vein, I wonder how many other operators started out with > a strong stance against overloading of BGP, and after years of tilting > at that windmill and observing that vendors continues to pile on new > "feature" after "feature" into BGP, just gave up? > > I certainly have. As an operator stability and optimal performance of > BGP implementations are of upmost concern for me, and there was a time > that many others appeared to feel the same. Afterall, MSDP didn't end > up in BGP and became a separate protocol because of that concern. > > However, since then I've seen vendors continually ignore our concern > and input and overload other features into BGP. > > There are those who say that it's operators' need to deploy new services > that's been causing this, but from my perspective, when/where we do use > new gadgets in BGP to rollout new service deployments it's because vendors > have already put those gadgets into their BGP implementation despite my > feedback, and there's only so much time and energy we can spend bashing > our heads against the brick wall. Afterall, we have a network to run and > services to deploy. In a market-driven economy vendors usually pay attention to $$$, not to a person's bashing his/her head against the brick wall. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 12:16:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22844 for ; Wed, 6 Aug 2003 12:16:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQxM-0004Om-FN for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 12:16:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76GG8MO016892 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 12:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQxE-0004Ni-UQ; Wed, 06 Aug 2003 12:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQwK-0004Mn-0D for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 12:15:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22795 for ; Wed, 6 Aug 2003 12:14:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQwI-0004FH-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:15:02 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kQwH-0004Ew-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:15:02 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76GEFu65373; Wed, 6 Aug 2003 09:14:15 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061614.h76GEFu65373@merlot.juniper.net> To: Dorian Kim cc: Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Wed, 30 Jul 2003 17:31:16 EDT." <20030730213116.GB12046@blackrose.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22117.1060186455.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 09:14:15 -0700 Dorian, [clipped..] > Along the same vein, I wonder how many other operators started out with > a strong stance against overloading of BGP, and after years of tilting > at that windmill and observing that vendors continues to pile on new > "feature" after "feature" into BGP, just gave up? > > I certainly have. As an operator stability and optimal performance of > BGP implementations are of upmost concern for me, and there was a time > that many others appeared to feel the same. Afterall, MSDP didn't end > up in BGP and became a separate protocol because of that concern. > > However, since then I've seen vendors continually ignore our concern > and input and overload other features into BGP. > > There are those who say that it's operators' need to deploy new services > that's been causing this, but from my perspective, when/where we do use > new gadgets in BGP to rollout new service deployments it's because vendors > have already put those gadgets into their BGP implementation despite my > feedback, and there's only so much time and energy we can spend bashing > our heads against the brick wall. Afterall, we have a network to run and > services to deploy. In a market-driven economy vendors usually pay attention to $$$, not to a person's bashing his/her head against the brick wall. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 12:37:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23436 for ; Wed, 6 Aug 2003 12:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRHZ-00053B-Hu; Wed, 06 Aug 2003 12:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRH9-00051m-0r for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 12:36:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23380 for ; Wed, 6 Aug 2003 12:36:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRH7-0004N4-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:36:33 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kRH6-0004Mq-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:36:32 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76GZBu67466; Wed, 6 Aug 2003 09:35:11 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061635.h76GZBu67466@merlot.juniper.net> To: Henry Kilmer cc: Randy Bush , Eric Rosen , Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Wed, 30 Jul 2003 13:08:00 EDT." <16167.64368.170120.892909@durmstrang.padfoot.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27340.1060187711.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 09:35:11 -0700 Hank, > Randy Bush writes: > >one of the advantages of working for an operator is that you get to > >talk to lots of vendors, not just the ones that are politically > >well connected in the ietf. and i can tell you that the idea of > >extending bgp ad infinitum horrifies most of them. > > > >can we now finish representing hidden others than ourselves, > >expecially given that the ietf is supposedly a forum of individual > >experts? > > Amen. Although I don't think the operator to vendor ratio within the > IETF forums are what they should be to produce the best results. To paraphrase, I don't think that the ratio of the operators present at the Open Routine Area meeting in Vienna (or for that matter the operators who express their opinion on this mailing list) to operators in the global marketplace are what they should be to produce a reasonable sample of the operators' perspective on the issue. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 12:37:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23440 for ; Wed, 6 Aug 2003 12:37:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRHf-00056P-0w for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 12:37:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Gb6ad019582 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 12:37:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRHZ-00053B-Hu; Wed, 06 Aug 2003 12:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRH9-00051m-0r for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 12:36:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23380 for ; Wed, 6 Aug 2003 12:36:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRH7-0004N4-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:36:33 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kRH6-0004Mq-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:36:32 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76GZBu67466; Wed, 6 Aug 2003 09:35:11 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061635.h76GZBu67466@merlot.juniper.net> To: Henry Kilmer cc: Randy Bush , Eric Rosen , Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Wed, 30 Jul 2003 13:08:00 EDT." <16167.64368.170120.892909@durmstrang.padfoot.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27340.1060187711.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 09:35:11 -0700 Hank, > Randy Bush writes: > >one of the advantages of working for an operator is that you get to > >talk to lots of vendors, not just the ones that are politically > >well connected in the ietf. and i can tell you that the idea of > >extending bgp ad infinitum horrifies most of them. > > > >can we now finish representing hidden others than ourselves, > >expecially given that the ietf is supposedly a forum of individual > >experts? > > Amen. Although I don't think the operator to vendor ratio within the > IETF forums are what they should be to produce the best results. To paraphrase, I don't think that the ratio of the operators present at the Open Routine Area meeting in Vienna (or for that matter the operators who express their opinion on this mailing list) to operators in the global marketplace are what they should be to produce a reasonable sample of the operators' perspective on the issue. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 12:46:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24000 for ; Wed, 6 Aug 2003 12:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRQH-0005iM-PY; Wed, 06 Aug 2003 12:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRPW-0005hu-Un for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 12:45:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23931 for ; Wed, 6 Aug 2003 12:45:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRPV-0004Uj-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:45:13 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kRPU-0004Ua-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:45:12 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76GiOu67973; Wed, 6 Aug 2003 09:44:24 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061644.h76GiOu67973@merlot.juniper.net> To: erosen@cisco.com cc: Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Thu, 31 Jul 2003 11:03:12 EDT." <200307311503.h6VF3Cxc011347@rtp-core-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29963.1060188264.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 09:44:24 -0700 Eric, > Jeff> TCP is a general purpose transport, and both BGP and > Jeff> HTTP use it. When someone suggests augmenting TCP to > Jeff> add, say, transactions, doesn't the IETF suggest that > Jeff> they get a new protocol? > > But this is an issue of whether TCP provides functionality which is > appropriate for transactions. I don't think anyone would say "you can't use > TCP because we already have too much TCP going on". > > Jeff> unless you want to argue that BGP is just a general purpose > Jeff> distribution mechanism. > > It is possible to think of BGP as a general purpose distribution mechanism > with applications layered on top of it, where the "address family" is used > to multiplex the applications. The multi-protocol extensions to BGP are a > pretty clear attempt to move in this direction. > > Jeff> The idea of splitting different functions into different tasks on the > Jeff> same processor is that new or alarming. > > No question. The issue is whether using a different protocol is either a > necessary or a sufficient condition of "splitting different functions into > different tasks". There is an existence proof (aka working code) that using a different protocol is *not* a necessary condition of "splitting different functions into different tasks". Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 12:48:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24091 for ; Wed, 6 Aug 2003 12:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRSD-0005t6-Qw; Wed, 06 Aug 2003 12:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRRX-0005qc-HO for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 12:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24046 for ; Wed, 6 Aug 2003 12:47:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRRV-0004W9-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:47:17 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kRRU-0004Vh-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:47:17 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76GkTu68221; Wed, 6 Aug 2003 09:46:29 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061646.h76GkTu68221@merlot.juniper.net> To: Jeff Parker cc: "'erosen@cisco.com'" , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Thu, 31 Jul 2003 11:31:37 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30512.1060188389.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 09:46:29 -0700 Jeff, > > No question. The issue is whether using a different > > protocol is either a necessary or a sufficient > > condition of "splitting different functions into > > different tasks". > > There are really two questions > > a) Should data for my application be carried in BGP? > > b) Should data for his application be carried in BGP? > > It is tempting to say that the answer to a) is yes > and the answer to b) is no. That is from *your* point of view. But if you'll take *his" point of view, then following the same logic the answer to a) is no, and the answer to b) is yes. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 13:11:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25045 for ; Wed, 6 Aug 2003 13:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRoT-00070N-Uk; Wed, 06 Aug 2003 13:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRoQ-000705-Oa for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 13:10:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25018 for ; Wed, 6 Aug 2003 13:10:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRoO-0004l7-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:10:56 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kRoO-0004kj-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:10:56 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76H8ku70109; Wed, 6 Aug 2003 10:08:47 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061708.h76H8ku70109@merlot.juniper.net> To: curtis@fictitious.org cc: erosen@cisco.com, Lars Erik Gullerud , raszuk@cisco.com, Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Fri, 01 Aug 2003 21:12:30 EDT." <200308020110.h721AEQk009533@mailhost.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36535.1060189726.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 10:08:46 -0700 > > In message <200308011707.h71H7txc023043@rtp-core-2.cisco.com>, Eric Rosen wri te > s: > > > > Lars> One problem as I see it right now though, is that if the contents of > > Lars> one of those bags isn't satisfactory (i.e. an update message is > > Lars> invalid), you throw the whole loaf of bread away (i.e. peer sends > > Lars> notification message and tears down the BGP session). > > > > This point is well taken. > > > > But don't you think that whatever happens here, this should be fixed in BGP? > > Even if BGP just carried the IPv4 and IPv6 address families, you might not > > want an error in one to take down the whole session. > > Right now a cease is not AF specific and neither is a crash of the BGP > task. So, as Eric suggested, one could fix this in BGP by making a cease AF specific. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 13:11:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25060 for ; Wed, 6 Aug 2003 13:11:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRoX-00071j-Vb for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 13:11:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76HB5re026980 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 13:11:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRoT-00070N-Uk; Wed, 06 Aug 2003 13:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRoQ-000705-Oa for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 13:10:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25018 for ; Wed, 6 Aug 2003 13:10:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRoO-0004l7-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:10:56 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kRoO-0004kj-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:10:56 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76H8ku70109; Wed, 6 Aug 2003 10:08:47 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061708.h76H8ku70109@merlot.juniper.net> To: curtis@fictitious.org cc: erosen@cisco.com, Lars Erik Gullerud , raszuk@cisco.com, Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Fri, 01 Aug 2003 21:12:30 EDT." <200308020110.h721AEQk009533@mailhost.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36535.1060189726.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 10:08:46 -0700 > > In message <200308011707.h71H7txc023043@rtp-core-2.cisco.com>, Eric Rosen wri te > s: > > > > Lars> One problem as I see it right now though, is that if the contents of > > Lars> one of those bags isn't satisfactory (i.e. an update message is > > Lars> invalid), you throw the whole loaf of bread away (i.e. peer sends > > Lars> notification message and tears down the BGP session). > > > > This point is well taken. > > > > But don't you think that whatever happens here, this should be fixed in BGP? > > Even if BGP just carried the IPv4 and IPv6 address families, you might not > > want an error in one to take down the whole session. > > Right now a cease is not AF specific and neither is a crash of the BGP > task. So, as Eric suggested, one could fix this in BGP by making a cease AF specific. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 13:18:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25310 for ; Wed, 6 Aug 2003 13:18:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRvE-0007VC-Ft; Wed, 06 Aug 2003 13:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRuy-0007V0-OJ for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 13:17:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25299 for ; Wed, 6 Aug 2003 13:17:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRuv-0004qP-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:17:41 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19kRuu-0004ps-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:17:40 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id CB97623C59; Wed, 6 Aug 2003 09:27:33 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h76HH9YB008909; Wed, 6 Aug 2003 10:17:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: Thread-Topic: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Thread-Index: AcNcLJFdzmjpwwy9TYS1Z1oiPqY/0wAEapdA From: "Tony Li" To: "Jeffrey Haas" , "Yakov Rekhter" Cc: "Danny McPherson" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 10:17:06 -0700 Content-Transfer-Encoding: quoted-printable Jeff, That's an excellent point and perhaps the question that should have been asked instead. The entire issue was initiated improperly by assuming the answer. We still don't know what problem we're trying to solve. The problem *I'm* interested in solving is how do we keep the control plane stable. Just shifting the work to another protocol does NOTHING for that. Tony | -----Original Message----- | From: Jeffrey Haas [mailto:jhaas@nexthop.com]=20 | Sent: Wednesday, August 06, 2003 8:05 AM | To: Yakov Rekhter | Cc: Danny McPherson; routing-discussion@ietf.org | Subject: Re: Who speaks for whom [was: Re: Open Routing=20 | Area meeting in Vienna] | =20 | =20 | On Wed, Aug 06, 2003 at 07:00:40AM -0700, Yakov Rekhter wrote: | > With this in mind I'd like to hear from the folks who=20 | argue against | > adding more stuff in BGP whether they also object against adding | > more stuff into ISIS. | =20 | As I think I've mentioned before, I think we each have reactions | much like the DNS folk who continually find stuff being shoved | into their working infrastructure. =20 | =20 | (not specifically to Yakov) | Is there any way we can just frame this conversation as "how do we | keep from breaking things when we're working on extended them"? | =20 | =20 | --=20 | Jeff Haas=20 | NextHop Technologies | =20 | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 13:18:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25324 for ; Wed, 6 Aug 2003 13:18:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRvH-0007W5-Gi for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 13:18:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76HI3I8028888 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 13:18:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRvE-0007VC-Ft; Wed, 06 Aug 2003 13:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRuy-0007V0-OJ for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 13:17:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25299 for ; Wed, 6 Aug 2003 13:17:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRuv-0004qP-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:17:41 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19kRuu-0004ps-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:17:40 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id CB97623C59; Wed, 6 Aug 2003 09:27:33 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h76HH9YB008909; Wed, 6 Aug 2003 10:17:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: Thread-Topic: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Thread-Index: AcNcLJFdzmjpwwy9TYS1Z1oiPqY/0wAEapdA From: "Tony Li" To: "Jeffrey Haas" , "Yakov Rekhter" Cc: "Danny McPherson" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 10:17:06 -0700 Content-Transfer-Encoding: quoted-printable Jeff, That's an excellent point and perhaps the question that should have been asked instead. The entire issue was initiated improperly by assuming the answer. We still don't know what problem we're trying to solve. The problem *I'm* interested in solving is how do we keep the control plane stable. Just shifting the work to another protocol does NOTHING for that. Tony | -----Original Message----- | From: Jeffrey Haas [mailto:jhaas@nexthop.com]=20 | Sent: Wednesday, August 06, 2003 8:05 AM | To: Yakov Rekhter | Cc: Danny McPherson; routing-discussion@ietf.org | Subject: Re: Who speaks for whom [was: Re: Open Routing=20 | Area meeting in Vienna] | =20 | =20 | On Wed, Aug 06, 2003 at 07:00:40AM -0700, Yakov Rekhter wrote: | > With this in mind I'd like to hear from the folks who=20 | argue against | > adding more stuff in BGP whether they also object against adding | > more stuff into ISIS. | =20 | As I think I've mentioned before, I think we each have reactions | much like the DNS folk who continually find stuff being shoved | into their working infrastructure. =20 | =20 | (not specifically to Yakov) | Is there any way we can just frame this conversation as "how do we | keep from breaking things when we're working on extended them"? | =20 | =20 | --=20 | Jeff Haas=20 | NextHop Technologies | =20 | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 13:29:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25675 for ; Wed, 6 Aug 2003 13:29:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS5s-0007yu-Tl; Wed, 06 Aug 2003 13:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS5b-0007ya-KW for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 13:28:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25610 for ; Wed, 6 Aug 2003 13:28:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kS5Z-0004vL-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:28:41 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19kS5Y-0004vI-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:28:40 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h76HSdA13427 for ; Wed, 6 Aug 2003 19:28:40 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h76HSdg09262 for ; Wed, 6 Aug 2003 19:28:39 +0200 (MEST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id TAA27805 for ; Wed, 6 Aug 2003 19:28:39 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Wed, 6 Aug 2003 19:28:00 +0200 Message-ID: <47D260E84215734F81779E8A50BE9B37656127@mchh2a4e.mchh.siemens.de> From: Schrodi Karl To: routing-discussion@ietf.org Subject: AW: Open Routing Area meeting in Vienna MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 19:27:59 +0200 Content-Transfer-Encoding: quoted-printable Gentlemen, a few weeks after Vienna I expected the waves to calm down - but = instead, the discussion seems to catch fire ... (whooow!) I think, that (as often) there are several possible positions - each = one has its pros and cons and none of them is perfectly right. We all = know, that =C2=B4THE right choice in the long run=C2=B4 doesn=C2=B4t = exist - and if it would, we would not know it in advance (thank good, = that nobody can foresee the future). So, I suggest to come back to a = common charter which probably should be something like =C2=B4to prevent = damage and facilitate improvements of the net=C2=B4 (which btw. I like = to read between the lines of all the contributions). Fact is, we have BGP today - and it is a good solution, because it = works (and permanently proves to do so). It serves its primary purpose = of being the inter-domain routing protocol and it serves some other = purposes it was found of being capable to do throughout the years. But = still, I think, there is some room for improvements in its original = purpose. Let me give five lines for an example: (Re)Routing convergence times may not be an issue for email = conversation or file transfer. But you probably will not like severe = disturbances in the life cast of a sports event or a net meeting = session ... . Routing stability and fast convergence may facilitate = introduction and broad acceptance of new, higher value services on the = net. I=C2=B4m not enough expert to say what =C2=B4is easy with BGP=C2=B4 or = what =C2=B4cannot be done with BGP=C2=B4, but I see three points: 1. BGP (as is) should be the starting point for any further = considerations. 2. Gradual improvements are always easier to achieve and smoother to = introduce than big steps or breaks. 3. Any kind of improvements will be much easier to achieve on an = =C2=B4unloaded=C2=B4, pure routing protocol. I would like to know, if somebody is already (or probably would be = willing to do so) working on such or similar improvement issues. (I guess my five lines are not sufficient to well define the problem, = but a problem statement could probably be a good starting point.) Karl -----Urspr=C3=BCngliche Nachricht----- Von: Yakov Rekhter [mailto:yakov@juniper.net] Gesendet: Mittwoch, 6. August 2003 17:14 An: Alex Zinin Cc: Robert Raszuk; routing-discussion@ietf.org Betreff: Re: Open Routing Area meeting in Vienna=20 Alex, [clipped...] =20 > The point is that I agree that the MP-BGP framework is a good match > for the required functionality, however the number of concerns we = have > heard suggest that it may not be THE right choice in the long run. We also heard for quite some time that for the Internet inter-domain routing BGP "may not be THE right choice in the long run". With this in mind I would suggest for folks interested in "THE right choice in the long run" to stop arguing against adding more stuff to BGP, and instead join the folks working on "THE right choice in=20 the long run" for the Internet inter-domain routing. Yakov. P.S. For those interested in the current status of the work on "THE right choice in the long run" for the Internet inter-domain routing I am happy to report that this work, aka as a LTSFGTC (Long Term Solution For Generations To Come), is in progress and is expected to be published in RFC100000. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 13:29:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25687 for ; Wed, 6 Aug 2003 13:29:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS5y-00081L-7m for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 13:29:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76HT60h030824 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 13:29:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS5s-0007yu-Tl; Wed, 06 Aug 2003 13:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS5b-0007ya-KW for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 13:28:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25610 for ; Wed, 6 Aug 2003 13:28:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kS5Z-0004vL-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:28:41 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19kS5Y-0004vI-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:28:40 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h76HSdA13427 for ; Wed, 6 Aug 2003 19:28:40 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h76HSdg09262 for ; Wed, 6 Aug 2003 19:28:39 +0200 (MEST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id TAA27805 for ; Wed, 6 Aug 2003 19:28:39 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Wed, 6 Aug 2003 19:28:00 +0200 Message-ID: <47D260E84215734F81779E8A50BE9B37656127@mchh2a4e.mchh.siemens.de> From: Schrodi Karl To: routing-discussion@ietf.org Subject: AW: Open Routing Area meeting in Vienna MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 19:27:59 +0200 Content-Transfer-Encoding: quoted-printable Gentlemen, a few weeks after Vienna I expected the waves to calm down - but = instead, the discussion seems to catch fire ... (whooow!) I think, that (as often) there are several possible positions - each = one has its pros and cons and none of them is perfectly right. We all = know, that =C2=B4THE right choice in the long run=C2=B4 doesn=C2=B4t = exist - and if it would, we would not know it in advance (thank good, = that nobody can foresee the future). So, I suggest to come back to a = common charter which probably should be something like =C2=B4to prevent = damage and facilitate improvements of the net=C2=B4 (which btw. I like = to read between the lines of all the contributions). Fact is, we have BGP today - and it is a good solution, because it = works (and permanently proves to do so). It serves its primary purpose = of being the inter-domain routing protocol and it serves some other = purposes it was found of being capable to do throughout the years. But = still, I think, there is some room for improvements in its original = purpose. Let me give five lines for an example: (Re)Routing convergence times may not be an issue for email = conversation or file transfer. But you probably will not like severe = disturbances in the life cast of a sports event or a net meeting = session ... . Routing stability and fast convergence may facilitate = introduction and broad acceptance of new, higher value services on the = net. I=C2=B4m not enough expert to say what =C2=B4is easy with BGP=C2=B4 or = what =C2=B4cannot be done with BGP=C2=B4, but I see three points: 1. BGP (as is) should be the starting point for any further = considerations. 2. Gradual improvements are always easier to achieve and smoother to = introduce than big steps or breaks. 3. Any kind of improvements will be much easier to achieve on an = =C2=B4unloaded=C2=B4, pure routing protocol. I would like to know, if somebody is already (or probably would be = willing to do so) working on such or similar improvement issues. (I guess my five lines are not sufficient to well define the problem, = but a problem statement could probably be a good starting point.) Karl -----Urspr=C3=BCngliche Nachricht----- Von: Yakov Rekhter [mailto:yakov@juniper.net] Gesendet: Mittwoch, 6. August 2003 17:14 An: Alex Zinin Cc: Robert Raszuk; routing-discussion@ietf.org Betreff: Re: Open Routing Area meeting in Vienna=20 Alex, [clipped...] =20 > The point is that I agree that the MP-BGP framework is a good match > for the required functionality, however the number of concerns we = have > heard suggest that it may not be THE right choice in the long run. We also heard for quite some time that for the Internet inter-domain routing BGP "may not be THE right choice in the long run". With this in mind I would suggest for folks interested in "THE right choice in the long run" to stop arguing against adding more stuff to BGP, and instead join the folks working on "THE right choice in=20 the long run" for the Internet inter-domain routing. Yakov. P.S. For those interested in the current status of the work on "THE right choice in the long run" for the Internet inter-domain routing I am happy to report that this work, aka as a LTSFGTC (Long Term Solution For Generations To Come), is in progress and is expected to be published in RFC100000. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 13:31:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24001 for ; Wed, 6 Aug 2003 12:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRQI-0005jE-RF for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 12:46:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Gk273021977 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 12:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRQH-0005iM-PY; Wed, 06 Aug 2003 12:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRPW-0005hu-Un for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 12:45:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23931 for ; Wed, 6 Aug 2003 12:45:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRPV-0004Uj-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:45:13 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kRPU-0004Ua-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:45:12 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76GiOu67973; Wed, 6 Aug 2003 09:44:24 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061644.h76GiOu67973@merlot.juniper.net> To: erosen@cisco.com cc: Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Thu, 31 Jul 2003 11:03:12 EDT." <200307311503.h6VF3Cxc011347@rtp-core-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29963.1060188264.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 09:44:24 -0700 Eric, > Jeff> TCP is a general purpose transport, and both BGP and > Jeff> HTTP use it. When someone suggests augmenting TCP to > Jeff> add, say, transactions, doesn't the IETF suggest that > Jeff> they get a new protocol? > > But this is an issue of whether TCP provides functionality which is > appropriate for transactions. I don't think anyone would say "you can't use > TCP because we already have too much TCP going on". > > Jeff> unless you want to argue that BGP is just a general purpose > Jeff> distribution mechanism. > > It is possible to think of BGP as a general purpose distribution mechanism > with applications layered on top of it, where the "address family" is used > to multiplex the applications. The multi-protocol extensions to BGP are a > pretty clear attempt to move in this direction. > > Jeff> The idea of splitting different functions into different tasks on the > Jeff> same processor is that new or alarming. > > No question. The issue is whether using a different protocol is either a > necessary or a sufficient condition of "splitting different functions into > different tasks". There is an existence proof (aka working code) that using a different protocol is *not* a necessary condition of "splitting different functions into different tasks". Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 13:33:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25862 for ; Wed, 6 Aug 2003 13:33:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS9l-0008C3-K8; Wed, 06 Aug 2003 13:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS9R-0008Bo-FB for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 13:32:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25848 for ; Wed, 6 Aug 2003 13:32:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kS9P-0004xi-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:32:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kS9O-0004xf-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:32:38 -0400 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.20) id 19kS9M-000INZ-Ji; Wed, 06 Aug 2003 17:32:37 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19kS9O-000MjX-In; Wed, 06 Aug 2003 10:32:38 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: Eric Rosen , Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200308061549.h76Fn9u63757@merlot.juniper.net> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 10:32:37 -0700 Content-Transfer-Encoding: 7bit >>> you stop pretending to speak for all service providers, and I won't >>> pretend to speak for all vendors ;-) >> no problem, when you actually listen to all the operators actually >> in the room > let's also keep in mind the number of operators "actually present > in the room" vs the number of service providers worldwide. we do, especially when the vendors who have not listened to the operators for some years try to represent those operators. randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 13:36:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24092 for ; Wed, 6 Aug 2003 12:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRSF-0005uQ-Tn for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 12:48:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Gm3Wh022682 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 12:48:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRSD-0005t6-Qw; Wed, 06 Aug 2003 12:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRRX-0005qc-HO for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 12:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24046 for ; Wed, 6 Aug 2003 12:47:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRRV-0004W9-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:47:17 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kRRU-0004Vh-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 12:47:17 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76GkTu68221; Wed, 6 Aug 2003 09:46:29 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308061646.h76GkTu68221@merlot.juniper.net> To: Jeff Parker cc: "'erosen@cisco.com'" , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Thu, 31 Jul 2003 11:31:37 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30512.1060188389.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 09:46:29 -0700 Jeff, > > No question. The issue is whether using a different > > protocol is either a necessary or a sufficient > > condition of "splitting different functions into > > different tasks". > > There are really two questions > > a) Should data for my application be carried in BGP? > > b) Should data for his application be carried in BGP? > > It is tempting to say that the answer to a) is yes > and the answer to b) is no. That is from *your* point of view. But if you'll take *his" point of view, then following the same logic the answer to a) is no, and the answer to b) is yes. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 13:53:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26884 for ; Wed, 6 Aug 2003 13:53:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kST9-00010z-Tu for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 13:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Hr3CM003895 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 13:53:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kST6-0000zS-Af; Wed, 06 Aug 2003 13:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSSW-0000xn-3A for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 13:52:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26820 for ; Wed, 6 Aug 2003 13:52:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSST-0005Bz-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:52:21 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19kSST-0005BW-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:52:21 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h76HpogX011037; Wed, 6 Aug 2003 13:51:50 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h76HphLu011007; Wed, 6 Aug 2003 13:51:43 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h76Hpc207641; Wed, 6 Aug 2003 13:51:38 -0400 (EDT) From: Jeffrey Haas To: Tony Li Cc: Yakov Rekhter , Danny McPherson , routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: <20030806135138.D7860@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Wed, Aug 06, 2003 at 10:17:06AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 13:51:38 -0400 On Wed, Aug 06, 2003 at 10:17:06AM -0700, Tony Li wrote: > The entire issue was initiated improperly by > assuming the answer. We still don't know what problem we're trying > to solve. I think part of the issue is many of us have a gut feel for the problem, but nothing specific to point to. You, as one of our elders in the protocol biz, of all people show know some of the mistakes that have been made and how it has impacted things. Consider this an exercise in imparting lore of the clued to those with less clue. > The problem *I'm* interested in solving is how do we keep the control > plane stable. Just shifting the work to another protocol does NOTHING > for that. In general principle, I agree. However, I'm going to pick on one specific point as a counter-example. BGP (yes, you knew this was coming) has a state machine that once something enters the HOSED stated (which should probably be in the FSM :-) that it tears down the peering session, no matter what caused it. Simply separating out transport of the various AFI/SAFI's into separate BGP sessions is sufficient to keep errors that do not crash or corrupt an implementation (say, malformed packets) from tearing down the entire session. No, this isn't a whole new protocol. It really does nothing other than sandbag damage. If you corrupt internal data structures and those structures are shared with other AFI/SAFI's (such as your AS Path database), then you may corrupt the other sessions. So, it doesn't protect against all classes of errors like completely separate instances of everything, but it protects against some issues. Operationally, this means some changes to how we establish peering and handle call collision. It also means that I should expect to find Sue at my cubicle with a large club because it involves changing the FSM. Anyway, I offer that this particular mechanism allows for some sandbagging of the potential problem space. It also makes it easier for those who want to do actual full-out sandboxing by having out and out separate processes a bit easier since you don't have to multiplex your processes across a common transport. There may be other "solutions", but first we need to agree that it's a problem. I think it might be. > Tony -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 14:21:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25863 for ; Wed, 6 Aug 2003 13:33:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS9r-0008IA-Hz for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 13:33:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76HX7L4031831 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 13:33:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS9l-0008C3-K8; Wed, 06 Aug 2003 13:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS9R-0008Bo-FB for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 13:32:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25848 for ; Wed, 6 Aug 2003 13:32:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kS9P-0004xi-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:32:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kS9O-0004xf-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:32:38 -0400 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.20) id 19kS9M-000INZ-Ji; Wed, 06 Aug 2003 17:32:37 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19kS9O-000MjX-In; Wed, 06 Aug 2003 10:32:38 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: Eric Rosen , Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200308061549.h76Fn9u63757@merlot.juniper.net> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 10:32:37 -0700 Content-Transfer-Encoding: 7bit >>> you stop pretending to speak for all service providers, and I won't >>> pretend to speak for all vendors ;-) >> no problem, when you actually listen to all the operators actually >> in the room > let's also keep in mind the number of operators "actually present > in the room" vs the number of service providers worldwide. we do, especially when the vendors who have not listened to the operators for some years try to represent those operators. randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 14:22:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28173 for ; Wed, 6 Aug 2003 14:22:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSvB-0002Wq-1T; Wed, 06 Aug 2003 14:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSuJ-0002Vl-79 for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 14:21:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28079 for ; Wed, 6 Aug 2003 14:21:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSuG-0005Rw-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:21:04 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19kSuF-0005Rh-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:21:03 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id ECF1223C77; Wed, 6 Aug 2003 10:30:56 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h76IKWYB011084; Wed, 6 Aug 2003 11:20:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: Thread-Topic: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Thread-Index: AcNcQ4TdMdG5GlK+RIKSwgxzOg54mAAA64Fw From: "Tony Li" To: "Jeffrey Haas" Cc: "Yakov Rekhter" , "Danny McPherson" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 11:20:32 -0700 Content-Transfer-Encoding: quoted-printable | BGP (yes, you knew this was coming) has a state machine that once | something enters the HOSED stated (which should probably=20 | be in the FSM :-) | that it tears down the peering session, no matter what caused it. | =20 | There may be other "solutions", but first we need to agree=20 | that it's | a problem. I think it might be. Jeff, If this is the problem that we're trying to solve, can I then request that we take it back to the IDR mailing list? I was under the impression that some people think that there's a different problem that needs solving. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 14:22:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28181 for ; Wed, 6 Aug 2003 14:22:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSvI-0002aJ-HH for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 14:22:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76IM8Fq009914 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 14:22:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSvB-0002Wq-1T; Wed, 06 Aug 2003 14:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSuJ-0002Vl-79 for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 14:21:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28079 for ; Wed, 6 Aug 2003 14:21:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSuG-0005Rw-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:21:04 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19kSuF-0005Rh-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:21:03 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id ECF1223C77; Wed, 6 Aug 2003 10:30:56 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h76IKWYB011084; Wed, 6 Aug 2003 11:20:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: Thread-Topic: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Thread-Index: AcNcQ4TdMdG5GlK+RIKSwgxzOg54mAAA64Fw From: "Tony Li" To: "Jeffrey Haas" Cc: "Yakov Rekhter" , "Danny McPherson" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 11:20:32 -0700 Content-Transfer-Encoding: quoted-printable | BGP (yes, you knew this was coming) has a state machine that once | something enters the HOSED stated (which should probably=20 | be in the FSM :-) | that it tears down the peering session, no matter what caused it. | =20 | There may be other "solutions", but first we need to agree=20 | that it's | a problem. I think it might be. Jeff, If this is the problem that we're trying to solve, can I then request that we take it back to the IDR mailing list? I was under the impression that some people think that there's a different problem that needs solving. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 14:37:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28818 for ; Wed, 6 Aug 2003 14:37:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kT9h-0003H2-L0; Wed, 06 Aug 2003 14:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kT8s-0003GM-GN for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 14:36:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28791 for ; Wed, 6 Aug 2003 14:36:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kT8p-0005bv-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:36:07 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19kT8o-0005bO-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:36:06 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h76IZa0E013584; Wed, 6 Aug 2003 14:35:36 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h76IZWLu013577; Wed, 6 Aug 2003 14:35:32 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h76IZRc09876; Wed, 6 Aug 2003 14:35:27 -0400 (EDT) From: Jeffrey Haas To: Tony Li Cc: Yakov Rekhter , Danny McPherson , routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: <20030806143527.E7860@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Wed, Aug 06, 2003 at 11:20:32AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 14:35:27 -0400 Tony, On Wed, Aug 06, 2003 at 11:20:32AM -0700, Tony Li wrote: > If this is the problem that we're trying to solve, can I then request > that we take it back to the IDR mailing list? That might be the right action. However, I think Alex (wearing his AD hat) is trying to get us to tackle the general issue. BGP just happens to be the thing where the problem is most obvious. > I was under the impression that some people think that there's a > different problem that needs solving. Given the hours I've been working recently, I may simply be delusional. However, I think that this is at least a *part* of it. > Tony -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 6 14:37:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28819 for ; Wed, 6 Aug 2003 14:37:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kT9o-0003J6-Hw for routing-discussion-archive@odin.ietf.org; Wed, 06 Aug 2003 14:37:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Ib85O012677 for routing-discussion-archive@odin.ietf.org; Wed, 6 Aug 2003 14:37:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kT9h-0003H2-L0; Wed, 06 Aug 2003 14:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kT8s-0003GM-GN for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 14:36:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28791 for ; Wed, 6 Aug 2003 14:36:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kT8p-0005bv-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:36:07 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19kT8o-0005bO-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:36:06 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h76IZa0E013584; Wed, 6 Aug 2003 14:35:36 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h76IZWLu013577; Wed, 6 Aug 2003 14:35:32 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h76IZRc09876; Wed, 6 Aug 2003 14:35:27 -0400 (EDT) From: Jeffrey Haas To: Tony Li Cc: Yakov Rekhter , Danny McPherson , routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: <20030806143527.E7860@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Wed, Aug 06, 2003 at 11:20:32AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 14:35:27 -0400 Tony, On Wed, Aug 06, 2003 at 11:20:32AM -0700, Tony Li wrote: > If this is the problem that we're trying to solve, can I then request > that we take it back to the IDR mailing list? That might be the right action. However, I think Alex (wearing his AD hat) is trying to get us to tackle the general issue. BGP just happens to be the thing where the problem is most obvious. > I was under the impression that some people think that there's a > different problem that needs solving. Given the hours I've been working recently, I may simply be delusional. However, I think that this is at least a *part* of it. > Tony -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 6 14:46:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26885 for ; Wed, 6 Aug 2003 13:53:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kST6-0000zS-Af; Wed, 06 Aug 2003 13:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSSW-0000xn-3A for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 13:52:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26820 for ; Wed, 6 Aug 2003 13:52:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSST-0005Bz-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:52:21 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19kSST-0005BW-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 13:52:21 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h76HpogX011037; Wed, 6 Aug 2003 13:51:50 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h76HphLu011007; Wed, 6 Aug 2003 13:51:43 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h76Hpc207641; Wed, 6 Aug 2003 13:51:38 -0400 (EDT) From: Jeffrey Haas To: Tony Li Cc: Yakov Rekhter , Danny McPherson , routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: <20030806135138.D7860@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Wed, Aug 06, 2003 at 10:17:06AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 6 Aug 2003 13:51:38 -0400 On Wed, Aug 06, 2003 at 10:17:06AM -0700, Tony Li wrote: > The entire issue was initiated improperly by > assuming the answer. We still don't know what problem we're trying > to solve. I think part of the issue is many of us have a gut feel for the problem, but nothing specific to point to. You, as one of our elders in the protocol biz, of all people show know some of the mistakes that have been made and how it has impacted things. Consider this an exercise in imparting lore of the clued to those with less clue. > The problem *I'm* interested in solving is how do we keep the control > plane stable. Just shifting the work to another protocol does NOTHING > for that. In general principle, I agree. However, I'm going to pick on one specific point as a counter-example. BGP (yes, you knew this was coming) has a state machine that once something enters the HOSED stated (which should probably be in the FSM :-) that it tears down the peering session, no matter what caused it. Simply separating out transport of the various AFI/SAFI's into separate BGP sessions is sufficient to keep errors that do not crash or corrupt an implementation (say, malformed packets) from tearing down the entire session. No, this isn't a whole new protocol. It really does nothing other than sandbag damage. If you corrupt internal data structures and those structures are shared with other AFI/SAFI's (such as your AS Path database), then you may corrupt the other sessions. So, it doesn't protect against all classes of errors like completely separate instances of everything, but it protects against some issues. Operationally, this means some changes to how we establish peering and handle call collision. It also means that I should expect to find Sue at my cubicle with a large club because it involves changing the FSM. Anyway, I offer that this particular mechanism allows for some sandbagging of the potential problem space. It also makes it easier for those who want to do actual full-out sandboxing by having out and out separate processes a bit easier since you don't have to multiplex your processes across a common transport. There may be other "solutions", but first we need to agree that it's a problem. I think it might be. > Tony -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 7 13:23:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22894 for ; Thu, 7 Aug 2003 13:23:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koTd-00006L-Fk; Thu, 07 Aug 2003 13:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koTB-000060-MS for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 13:22:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22825 for ; Thu, 7 Aug 2003 13:22:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19koT9-0000rR-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 13:22:31 -0400 Received: from shockwave.systems.pipex.net ([62.241.160.9]) by ietf-mx with esmtp (Exim 4.12) id 19koT8-0000rI-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 13:22:30 -0400 Received: from tom3 (1Cust227.tnt16.lnd4.gbr.da.uu.net [62.188.145.227]) by shockwave.systems.pipex.net (Postfix) with SMTP id AAD29160005EE; Thu, 7 Aug 2003 18:21:57 +0100 (BST) Message-ID: <02b501c35d08$2e0f9300$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Danny McPherson" , "Yakov Rekhter" Cc: Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 12:41:59 +0100 Content-Transfer-Encoding: 7bit No problems with enhancing ISIS or OSPF or .... BGP though is unique, it is the only thing we have to glue The Internet together and so we should be wary of jeopardising it which adding ever more function to it is apt to do. Enhance BGP if so doing give us a better Internet - more stable, faster convergence, better router selection; otherwise don't. I see OSPF (more familiar to me that ISIS) being used ever more widely by people whose grasp of it is not so great and in so doing, the ideas of it get diluted or distorted. For example, OSPF defines router id as a 32-bit number, not an IP address (RFC2328 Page 47); at least two working groups produced IDs in 2002 stating that router id was an IP address and could be used as such. (Well, let them try that in IPv6:-) The more we load onto BGP, the more people work on it, the more deviation we will have, the more risk to The Internet. Tom Petch -----Original Message----- From: Yakov Rekhter To: Danny McPherson Cc: routing-discussion@ietf.org Date: 06 August 2003 15:02 Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] >Danny, > >[clipped...] > >> On the topic of RP overloading... >> >> There are [some] very real problems folks are attempting to address and >> given MP-BGP & BGP-CAP, BGP has been the easy answer. Heck, with IGP >> Capabilities being defined we'll be able to do more things even faster >> (although I'm kidding, be wary :-) > >The discussion should certainly include extensions to ISIS, like >carrying both IPv4 and IPv6 unicast routing, IPv4 unicast routes >used by IPv4 multicast, IPv6 unicast routes used by IPv6 multicast, >using ISIS Extensions for BGP Peer Discovery, using ISIS flooding >procedures to carry TE information. > >With this in mind I'd like to hear from the folks who argue against >adding more stuff in BGP whether they also object against adding >more stuff into ISIS. > >Yakov. > > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 7 13:23:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22903 for ; Thu, 7 Aug 2003 13:23:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koU1-0000Cv-Gl for routing-discussion-archive@odin.ietf.org; Thu, 07 Aug 2003 13:23:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HNPDk000790 for routing-discussion-archive@odin.ietf.org; Thu, 7 Aug 2003 13:23:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koTd-00006L-Fk; Thu, 07 Aug 2003 13:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koTB-000060-MS for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 13:22:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22825 for ; Thu, 7 Aug 2003 13:22:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19koT9-0000rR-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 13:22:31 -0400 Received: from shockwave.systems.pipex.net ([62.241.160.9]) by ietf-mx with esmtp (Exim 4.12) id 19koT8-0000rI-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 13:22:30 -0400 Received: from tom3 (1Cust227.tnt16.lnd4.gbr.da.uu.net [62.188.145.227]) by shockwave.systems.pipex.net (Postfix) with SMTP id AAD29160005EE; Thu, 7 Aug 2003 18:21:57 +0100 (BST) Message-ID: <02b501c35d08$2e0f9300$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Danny McPherson" , "Yakov Rekhter" Cc: Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 12:41:59 +0100 Content-Transfer-Encoding: 7bit No problems with enhancing ISIS or OSPF or .... BGP though is unique, it is the only thing we have to glue The Internet together and so we should be wary of jeopardising it which adding ever more function to it is apt to do. Enhance BGP if so doing give us a better Internet - more stable, faster convergence, better router selection; otherwise don't. I see OSPF (more familiar to me that ISIS) being used ever more widely by people whose grasp of it is not so great and in so doing, the ideas of it get diluted or distorted. For example, OSPF defines router id as a 32-bit number, not an IP address (RFC2328 Page 47); at least two working groups produced IDs in 2002 stating that router id was an IP address and could be used as such. (Well, let them try that in IPv6:-) The more we load onto BGP, the more people work on it, the more deviation we will have, the more risk to The Internet. Tom Petch -----Original Message----- From: Yakov Rekhter To: Danny McPherson Cc: routing-discussion@ietf.org Date: 06 August 2003 15:02 Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] >Danny, > >[clipped...] > >> On the topic of RP overloading... >> >> There are [some] very real problems folks are attempting to address and >> given MP-BGP & BGP-CAP, BGP has been the easy answer. Heck, with IGP >> Capabilities being defined we'll be able to do more things even faster >> (although I'm kidding, be wary :-) > >The discussion should certainly include extensions to ISIS, like >carrying both IPv4 and IPv6 unicast routing, IPv4 unicast routes >used by IPv4 multicast, IPv6 unicast routes used by IPv6 multicast, >using ISIS Extensions for BGP Peer Discovery, using ISIS flooding >procedures to carry TE information. > >With this in mind I'd like to hear from the folks who argue against >adding more stuff in BGP whether they also object against adding >more stuff into ISIS. > >Yakov. > > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 7 14:34:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25969 for ; Thu, 7 Aug 2003 14:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpaT-0006ED-Mo for routing-discussion-archive@odin.ietf.org; Thu, 07 Aug 2003 14:34:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77IY9ie023935 for routing-discussion-archive@odin.ietf.org; Thu, 7 Aug 2003 14:34:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpaK-0006D7-Un; Thu, 07 Aug 2003 14:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpZv-0006CI-G6 for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 14:33:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25934 for ; Thu, 7 Aug 2003 14:33:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpZs-0001aU-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 14:33:32 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kpZr-0001aP-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 14:33:32 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h77IX0u70896; Thu, 7 Aug 2003 11:33:00 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308071833.h77IX0u70896@merlot.juniper.net> To: Alex Zinin cc: Routing Discussion Subject: Re: RP overloading: Next Steps In-Reply-To: Your message of "Fri, 01 Aug 2003 01:20:53 PDT." <182700830751.20030801012053@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <96809.1060281180.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 07 Aug 2003 11:33:00 -0700 Alex, > Folks- > > Below is my suggestion on how we move forward, as well as a reply to > the messages from Russ and Robert. Comments are welcome. see below... > 1. Define routing-related and non-routing related information > and guidelines for acceptance of RP extensions. > > Since we already had a discussion on this topic on the rtg-dir, > I would suggest that we ask the rtg-dir to come up with the draft > on this topic and then discuss it here. > The draft should also provide a *rationale* explanation on why acceptance of RP extensions should take into consideration whether the information is classified as "routing-related" vs "non-routing related". > 2. Document concerns/considerations on overloading RPs with non-routing > related information. > > dmm et al seem to be working on this part already. > I suggest we formalize this as a design team and ask them > to come back to this list with the document for further > discussion. Provide *rationale* explanation on why these concerns/considerations are not applicable to the information labeled as "routing", and are limited only to the information labeled as "non-routing". Moreover, specify whether these concerns/considerations are of practical or theoretical significance. > 3. Document "meanwhile recommendations" for MP-BGP > > While we are discussing alternative distribution mechanisms, we > may want document the considerations that we believe are important > to know to deal with the stuff in the pipe already. > > It seems it should be possible to come up with an > architecture-level document operating in terms defined within the > BGP spec, not getting into the code-level details, and yet > providing a list of requirements/recommendations that MP-BGP > implementations should support. Please also add "meanwhile recommendations" for ISIS and OSPF. > 4. Start exploring the alternative space > > There is a considerable part of the community who believe that > overloading MP-BGP is not the right thing in the long run. This > was clear at the meeting, and is clear on this list too. While not > all of us may agree with this, ignoring this would be plain wrong, > I believe. The "overloading" issue (if one believe that it exists) is applicable to ISIS and OSPF as well. Thus folks who believe in the overloading issue need to consider not just MP-BGP, but ISIS and OSPF too. Specifically these folks need to come up with an alternative not just to MP-BGP, but to ISIS and OSPF as well. > I also believe that until we have some documented understanding of > the functional requirements and design considerations for the > alternative, the situation will not change and all our discussions > will remain purely theoretical. Writing requirement and framework > documents is not a pleasant exercise, but it seems that in this > case we need something all of us can read and discuss. In fact, I > think Eric's posting to the list could be a good start. > > What I think we should do is form a design team that would group > people who believe that we DO need an alternative to MP-BGP for > non-routing info distribution and know what functions it should > perform. This team would then be asked to come up with these two This team also needs to provider *rationale* arguments on why the alternative is needed only for "non-routing" info distribution and should not include "routing" info distribution. > documents, that would be discussed on this list and in Minneapolis > (we would either bring it to the open RTG area meeting, or have a > BOF for this topic explicitly.) Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 7 14:34:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25970 for ; Thu, 7 Aug 2003 14:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpaK-0006D7-Un; Thu, 07 Aug 2003 14:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpZv-0006CI-G6 for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 14:33:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25934 for ; Thu, 7 Aug 2003 14:33:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpZs-0001aU-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 14:33:32 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kpZr-0001aP-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 14:33:32 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h77IX0u70896; Thu, 7 Aug 2003 11:33:00 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308071833.h77IX0u70896@merlot.juniper.net> To: Alex Zinin cc: Routing Discussion Subject: Re: RP overloading: Next Steps In-Reply-To: Your message of "Fri, 01 Aug 2003 01:20:53 PDT." <182700830751.20030801012053@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <96809.1060281180.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 07 Aug 2003 11:33:00 -0700 Alex, > Folks- > > Below is my suggestion on how we move forward, as well as a reply to > the messages from Russ and Robert. Comments are welcome. see below... > 1. Define routing-related and non-routing related information > and guidelines for acceptance of RP extensions. > > Since we already had a discussion on this topic on the rtg-dir, > I would suggest that we ask the rtg-dir to come up with the draft > on this topic and then discuss it here. > The draft should also provide a *rationale* explanation on why acceptance of RP extensions should take into consideration whether the information is classified as "routing-related" vs "non-routing related". > 2. Document concerns/considerations on overloading RPs with non-routing > related information. > > dmm et al seem to be working on this part already. > I suggest we formalize this as a design team and ask them > to come back to this list with the document for further > discussion. Provide *rationale* explanation on why these concerns/considerations are not applicable to the information labeled as "routing", and are limited only to the information labeled as "non-routing". Moreover, specify whether these concerns/considerations are of practical or theoretical significance. > 3. Document "meanwhile recommendations" for MP-BGP > > While we are discussing alternative distribution mechanisms, we > may want document the considerations that we believe are important > to know to deal with the stuff in the pipe already. > > It seems it should be possible to come up with an > architecture-level document operating in terms defined within the > BGP spec, not getting into the code-level details, and yet > providing a list of requirements/recommendations that MP-BGP > implementations should support. Please also add "meanwhile recommendations" for ISIS and OSPF. > 4. Start exploring the alternative space > > There is a considerable part of the community who believe that > overloading MP-BGP is not the right thing in the long run. This > was clear at the meeting, and is clear on this list too. While not > all of us may agree with this, ignoring this would be plain wrong, > I believe. The "overloading" issue (if one believe that it exists) is applicable to ISIS and OSPF as well. Thus folks who believe in the overloading issue need to consider not just MP-BGP, but ISIS and OSPF too. Specifically these folks need to come up with an alternative not just to MP-BGP, but to ISIS and OSPF as well. > I also believe that until we have some documented understanding of > the functional requirements and design considerations for the > alternative, the situation will not change and all our discussions > will remain purely theoretical. Writing requirement and framework > documents is not a pleasant exercise, but it seems that in this > case we need something all of us can read and discuss. In fact, I > think Eric's posting to the list could be a good start. > > What I think we should do is form a design team that would group > people who believe that we DO need an alternative to MP-BGP for > non-routing info distribution and know what functions it should > perform. This team would then be asked to come up with these two This team also needs to provider *rationale* arguments on why the alternative is needed only for "non-routing" info distribution and should not include "routing" info distribution. > documents, that would be discussed on this list and in Minneapolis > (we would either bring it to the open RTG area meeting, or have a > BOF for this topic explicitly.) Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 7 16:03:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00421 for ; Thu, 7 Aug 2003 16:03:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqyT-0002Yy-5e; Thu, 07 Aug 2003 16:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqxj-0002YU-CR for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 16:02:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00365 for ; Thu, 7 Aug 2003 16:02:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kqxh-0002Li-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 16:02:13 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kqxg-0002LZ-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 16:02:13 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h77K1du77809; Thu, 7 Aug 2003 13:01:39 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308072001.h77K1du77809@merlot.juniper.net> To: Lars Erik Gullerud cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25530.1060286499.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 07 Aug 2003 13:01:39 -0700 Lars, > Of course you can use multiple sessions and build separate meshes, and > for a lot of cases, this is in fact already the common way to do it. But > that hardly scales ad infinitum, and in fact causes even more > administrative hassles than if each service was carried in it's own > completely separate protocol, as you now also need N addresses set up on > each host to support N services in individual sessions. > > My point was that while you say that "that is what making each AFI/SAFI > fully modular is all about", BGP has certain inherent properties that > does NOT make them fully modular. Could you please point out to these "inherent properties", and explain why they do not make BGP fully modular. > If you really want BGP to be the > generalized "stuff distribution protocol", then the protocol needs even > more changes to generalize it to this level. What *specific* changes does it need ? > Whether making a "BGP5" > with these kinds of changes is the way to go or to create a brand new > "stuff distribution protocol" is something I don't really have an > opinion on - I just don't think BGP as we know it today is the answer. What do you see missing in BGP (please be very specific) ? > I'll just restate my earlier comment - it's about isolating each service > so any failure will impact as small a portion of the customers as > possible. And as the complexity increases, and the chances for failure > with it, this becomes even more important. I don't think there is any disagreement on the need to provide isolation between services. It is just that some folks claim that (a) there is no way to provide such isolation within BGP, (despite the fact that there are products on the market that do provide such isolation with BGP), and that (b) the new protocol is going to provide such isolation (which at the present moment is nothing but an unsubstantiated claim). Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 7 16:03:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00425 for ; Thu, 7 Aug 2003 16:03:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqyl-0002cX-QM for routing-discussion-archive@odin.ietf.org; Thu, 07 Aug 2003 16:03:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77K3JFp010056 for routing-discussion-archive@odin.ietf.org; Thu, 7 Aug 2003 16:03:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqyT-0002Yy-5e; Thu, 07 Aug 2003 16:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqxj-0002YU-CR for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 16:02:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00365 for ; Thu, 7 Aug 2003 16:02:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kqxh-0002Li-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 16:02:13 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kqxg-0002LZ-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 16:02:13 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h77K1du77809; Thu, 7 Aug 2003 13:01:39 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308072001.h77K1du77809@merlot.juniper.net> To: Lars Erik Gullerud cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25530.1060286499.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 07 Aug 2003 13:01:39 -0700 Lars, > Of course you can use multiple sessions and build separate meshes, and > for a lot of cases, this is in fact already the common way to do it. But > that hardly scales ad infinitum, and in fact causes even more > administrative hassles than if each service was carried in it's own > completely separate protocol, as you now also need N addresses set up on > each host to support N services in individual sessions. > > My point was that while you say that "that is what making each AFI/SAFI > fully modular is all about", BGP has certain inherent properties that > does NOT make them fully modular. Could you please point out to these "inherent properties", and explain why they do not make BGP fully modular. > If you really want BGP to be the > generalized "stuff distribution protocol", then the protocol needs even > more changes to generalize it to this level. What *specific* changes does it need ? > Whether making a "BGP5" > with these kinds of changes is the way to go or to create a brand new > "stuff distribution protocol" is something I don't really have an > opinion on - I just don't think BGP as we know it today is the answer. What do you see missing in BGP (please be very specific) ? > I'll just restate my earlier comment - it's about isolating each service > so any failure will impact as small a portion of the customers as > possible. And as the complexity increases, and the chances for failure > with it, this becomes even more important. I don't think there is any disagreement on the need to provide isolation between services. It is just that some folks claim that (a) there is no way to provide such isolation within BGP, (despite the fact that there are products on the market that do provide such isolation with BGP), and that (b) the new protocol is going to provide such isolation (which at the present moment is nothing but an unsubstantiated claim). Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 7 18:05:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05186 for ; Thu, 7 Aug 2003 18:05:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kssX-0007oC-S0; Thu, 07 Aug 2003 18:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTGi-0003z1-GW for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 14:44:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29104 for ; Wed, 6 Aug 2003 14:44:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTGf-0005iK-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:44:13 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19kTGe-0005iH-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:44:13 -0400 Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 3A52B940873; Wed, 6 Aug 2003 11:41:51 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 9CC1B979C1; Wed, 6 Aug 2003 11:41:48 -0700 (PDT) To: Yakov Rekhter Cc: curtis@fictitious.org, erosen@cisco.com, Lars Erik Gullerud , raszuk@cisco.com, Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org, enke@redback.com Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Message from Yakov Rekhter of "Wed, 06 Aug 2003 10:08:46 PDT." <200308061708.h76H8ku70109@merlot.juniper.net> From: Enke Chen Message-Id: <20030806184148.9CC1B979C1@popserv2.redback.com> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 11:41:48 -0700 Yakov, > Message-Id: <200308061708.h76H8ku70109@merlot.juniper.net> > To: curtis@fictitious.org > Cc: erosen@cisco.com, Lars Erik Gullerud , > raszuk@cisco.com, Jeff Parker , > "'Russ White'" , > Kurt Erik Lindqvist , > Randy Bush , routing-discussion@ietf.org > Subject: Re: Open Routing Area meeting in Vienna > In-Reply-To: Your message of "Fri, 01 Aug 2003 21:12:30 EDT." > <200308020110.h721AEQk009533@mailhost.avici.com> > Date: Wed, 06 Aug 2003 10:08:46 -0700 > > > > > In message <200308011707.h71H7txc023043@rtp-core-2.cisco.com>, Eric Rosen wri > te > > s: > > > > > > Lars> One problem as I see it right now though, is that if the contents of > > > Lars> one of those bags isn't satisfactory (i.e. an update message is > > > Lars> invalid), you throw the whole loaf of bread away (i.e. peer sends > > > Lars> notification message and tears down the BGP session). > > > > > > This point is well taken. > > > > > > But don't you think that whatever happens here, this should be fixed in BGP? > > > Even if BGP just carried the IPv4 and IPv6 address families, you might not > > > want an error in one to take down the whole session. > > > > Right now a cease is not AF specific and neither is a crash of the BGP > > task. > > So, as Eric suggested, one could fix this in BGP by making a cease AF > specific. It could also be fixed in BGP by withdrawing the specific AF capability (using the BGP Dynamic Capability). -- Enke _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 7 18:51:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05188 for ; Thu, 7 Aug 2003 18:05:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kssg-0007p4-NL for routing-discussion-archive@odin.ietf.org; Thu, 07 Aug 2003 18:05:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77M5AqU030066 for routing-discussion-archive@odin.ietf.org; Thu, 7 Aug 2003 18:05:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kssX-0007oC-S0; Thu, 07 Aug 2003 18:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTGi-0003z1-GW for routing-discussion@optimus.ietf.org; Wed, 06 Aug 2003 14:44:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29104 for ; Wed, 6 Aug 2003 14:44:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTGf-0005iK-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:44:13 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19kTGe-0005iH-00 for routing-discussion@ietf.org; Wed, 06 Aug 2003 14:44:13 -0400 Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 3A52B940873; Wed, 6 Aug 2003 11:41:51 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.44.81]) by popserv2.redback.com (Postfix) with ESMTP id 9CC1B979C1; Wed, 6 Aug 2003 11:41:48 -0700 (PDT) To: Yakov Rekhter Cc: curtis@fictitious.org, erosen@cisco.com, Lars Erik Gullerud , raszuk@cisco.com, Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org, enke@redback.com Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Message from Yakov Rekhter of "Wed, 06 Aug 2003 10:08:46 PDT." <200308061708.h76H8ku70109@merlot.juniper.net> From: Enke Chen Message-Id: <20030806184148.9CC1B979C1@popserv2.redback.com> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 06 Aug 2003 11:41:48 -0700 Yakov, > Message-Id: <200308061708.h76H8ku70109@merlot.juniper.net> > To: curtis@fictitious.org > Cc: erosen@cisco.com, Lars Erik Gullerud , > raszuk@cisco.com, Jeff Parker , > "'Russ White'" , > Kurt Erik Lindqvist , > Randy Bush , routing-discussion@ietf.org > Subject: Re: Open Routing Area meeting in Vienna > In-Reply-To: Your message of "Fri, 01 Aug 2003 21:12:30 EDT." > <200308020110.h721AEQk009533@mailhost.avici.com> > Date: Wed, 06 Aug 2003 10:08:46 -0700 > > > > > In message <200308011707.h71H7txc023043@rtp-core-2.cisco.com>, Eric Rosen wri > te > > s: > > > > > > Lars> One problem as I see it right now though, is that if the contents of > > > Lars> one of those bags isn't satisfactory (i.e. an update message is > > > Lars> invalid), you throw the whole loaf of bread away (i.e. peer sends > > > Lars> notification message and tears down the BGP session). > > > > > > This point is well taken. > > > > > > But don't you think that whatever happens here, this should be fixed in BGP? > > > Even if BGP just carried the IPv4 and IPv6 address families, you might not > > > want an error in one to take down the whole session. > > > > Right now a cease is not AF specific and neither is a crash of the BGP > > task. > > So, as Eric suggested, one could fix this in BGP by making a cease AF > specific. It could also be fixed in BGP by withdrawing the specific AF capability (using the BGP Dynamic Capability). -- Enke _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 7 21:01:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10687 for ; Thu, 7 Aug 2003 21:01:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvcy-0005eO-Kw for routing-discussion-archive@odin.ietf.org; Thu, 07 Aug 2003 21:01:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78118gk021678 for routing-discussion-archive@odin.ietf.org; Thu, 7 Aug 2003 21:01:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvcr-0005bj-B7; Thu, 07 Aug 2003 21:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvc4-0005aP-BM for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 21:00:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10526 for ; Thu, 7 Aug 2003 21:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvc1-0004Ar-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:00:09 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kvc1-0004Ao-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:00:09 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kvc1-000GpX-Ig for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:00:09 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <910493458.20030807175927@psg.com> To: routing-discussion@ietf.org Subject: Re: Extending BGP In-Reply-To: <200308061440.h76EeYu60088@merlot.juniper.net> References: <200308061440.h76EeYu60088@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 17:59:27 -0700 Content-Transfer-Encoding: 7bit Let's keep the original concerns in mind. Yakov Rekhter wrote: >> Though it is possible to do a fine job of clearly separating different >> applications of the same protocol within the system, using a separate >> protocol makes it much more likely to happen. > Following your logic one should have a separate protocol per > application, each with "its own life with independent (from BGP) > features, extensions optimizations, etc." To repeat what I've said already, one of the major concerns is stability of Internet routing. Separating routing from non-routing applications is the main thing we are talking about here, but one can certainly follow any logic to an absurd extreme. > Since you agree that it is quite possible "to do a fine job of > clearly separating different applications of the same protocol within > the system", let me suggest that the folks who are capable of > doing such "fine job" should continue doing this, while the folks > who need a separate protocol to make this happen should pursue the > avenue of the separate protocol per application. The issue under discussion may affect very wide Internet community, and I believe that shrugging it off in a manner "if you believe there's an issue--it's your problem, feel free to solve it" would not be appropriate and would only further polarize the community. We're here to discuss the issue in the open and work out the direction for future efforts. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 7 21:01:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10690 for ; Thu, 7 Aug 2003 21:01:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvcr-0005br-SW; Thu, 07 Aug 2003 21:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvc8-0005aX-VB for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 21:00:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10531 for ; Thu, 7 Aug 2003 21:00:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvc6-0004Ax-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:00:14 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kvc5-0004Au-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:00:14 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kvc6-000Gq7-3m for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:00:14 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6710496503.20030807175930@psg.com> To: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <200308061513.h76FDUu61724@merlot.juniper.net> References: <200308061513.h76FDUu61724@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 17:59:30 -0700 Content-Transfer-Encoding: 7bit Wednesday, August 6, 2003, 8:13:30 AM, Yakov Rekhter wrote: > We also heard for quite some time that for the Internet inter-domain > routing BGP "may not be THE right choice in the long run". With > this in mind I would suggest for folks interested in "THE right > choice in the long run" to stop arguing against adding more stuff > to BGP, and instead join the folks working on "THE right choice in > the long run" for the Internet inter-domain routing. Discussing whether adding "more stuff to BGP" (or any foo on protocol X for that matter) is a good idea or not, and the long-term implications of the tendency to use protocols in such manner is certainly within the charter of the IETF, and protocol-specific WGs, so I don't believe that asking people who disagree to bail out of this discussion would be in the spirit of openness and fairness of the IETF process. > In a market-driven economy vendors usually pay attention to $$$, not > to a person's bashing his/her head against the brick wall. And here we will pay attention to all people who speak up and explain their positions, regardless of how much $$$ they have, but rather based on the technical substance of their arguments. > To paraphrase, I don't think that the ratio of the operators present > at the Open Routine Area meeting in Vienna (or for that matter the > operators who express their opinion on this mailing list) to operators > in the global marketplace are what they should be to produce a > reasonable sample of the operators' perspective on the issue. We are not in the business of producing "samples of the operators' perspective" worldwide here. Let's leave this to the marketing departments of our employers. We are here to reach consensus among the people who care about the issue and participate in the IETF. If someone believes that not enough SPs have spoken up in this discussion--feel free to invite them to contribute. > I don't think there is any disagreement on the need to provide > isolation between services. It is just that some folks claim that > (a) there is no way to provide such isolation within BGP, (despite > the fact that there are products on the market that do provide such > isolation with BGP), and that (b) the new protocol is going to > provide such isolation (which at the present moment is nothing but > an unsubstantiated claim). I think it is not exactly that black-n-white. The way I read the concerns people have about BGP overloading in particular is that folks feel that the BGP-based approach introduces a higher risk of interference with the routing functions than the non-BGP one. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 7 21:20:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11132 for ; Thu, 7 Aug 2003 21:20:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvvK-0006Sm-C9 for routing-discussion-archive@odin.ietf.org; Thu, 07 Aug 2003 21:20:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h781K6F8024844 for routing-discussion-archive@odin.ietf.org; Thu, 7 Aug 2003 21:20:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvvF-0006Rn-Ou; Thu, 07 Aug 2003 21:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvun-0006RH-Bf for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 21:19:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11109 for ; Thu, 7 Aug 2003 21:19:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvuk-0004IY-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:19:30 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kvuk-0004IV-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:19:30 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kvuk-000I0P-I4 for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:19:30 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <15211650582.20030807181844@psg.com> To: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: <200308061400.h76E0eu58144@merlot.juniper.net> References: <200308061400.h76E0eu58144@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 18:18:44 -0700 Content-Transfer-Encoding: 7bit Wednesday, August 6, 2003, 7:00:40 AM, Yakov Rekhter wrote: > The discussion should certainly include extensions to ISIS, like > carrying both IPv4 and IPv6 unicast routing, IPv4 unicast routes > used by IPv4 multicast, IPv6 unicast routes used by IPv6 multicast, > using ISIS Extensions for BGP Peer Discovery, using ISIS flooding > procedures to carry TE information. > With this in mind I'd like to hear from the folks who argue against > adding more stuff in BGP whether they also object against adding > more stuff into ISIS. ISIS and OSPF are certainly within the discussion. On the other hand, I believe it was emphasized enough on the list that the concern is largely about adding non-routing related info on RPs. I think there is a good level of understanding that RPs will have new features and extensions, but there is a desire to limit this to routing-related applications as opposed to whatever human imagination can come up with. Wednesday, August 6, 2003, 8:05:14 AM, Jeffrey Haas wrote: > (not specifically to Yakov) > Is there any way we can just frame this conversation as "how do we > keep from breaking things when we're working on extended them"? I don;t think so. "What should be put in a protocol" is also an important question in this discussion. Wednesday, August 6, 2003, 10:17:06 AM, Tony Li wrote: > That's an excellent point and perhaps the question that should have > been asked instead. The entire issue was initiated improperly by > assuming the answer. Far from that (assuming you mean another protocol). It is one of the possible directions, and there's nothing wrong in discussing those. Wednesday, August 6, 2003, 11:35:27 AM, Jeffrey Haas wrote: ... > That might be the right action. However, I think Alex (wearing his AD > hat) is trying to get us to tackle the general issue. BGP just > happens to be the thing where the problem is most obvious. Correct. There's a general issue of routing protocol overloading (i.e., what is the right stuff to put on a routing protocol?) and a more specific issue of MP-BGP. Expected outcome of the discussion is the overall direction and very specific action items for design teams and protocol-specific WGs. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 7 21:32:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11385 for ; Thu, 7 Aug 2003 21:32:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kw6r-0006tg-VQ; Thu, 07 Aug 2003 21:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kw5y-0006q6-DM for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 21:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11364 for ; Thu, 7 Aug 2003 21:31:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kw5v-0004Mb-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:31:03 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19kw5u-0004MS-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:31:03 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h781UV7F026898; Thu, 7 Aug 2003 18:30:31 -0700 (PDT) Received: from [192.168.42.4] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA09608; Thu, 7 Aug 2003 21:30:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <15211650582.20030807181844@psg.com> References: <200308061400.h76E0eu58144@merlot.juniper.net> <15211650582.20030807181844@psg.com> To: Alex Zinin From: "John G. Scudder" Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Cc: routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 21:30:11 -0400 At 6:18 PM -0700 8/7/03, Alex Zinin wrote: >Wednesday, August 6, 2003, 8:05:14 AM, Jeffrey Haas wrote: > > (not specifically to Yakov) >> Is there any way we can just frame this conversation as "how do we >> keep from breaking things when we're working on extended them"? > >I don;t think so. "What should be put in a protocol" is also an >important question in this discussion. You're saying that "what should be put in a protocol" is an important question regardless of whether said extensions are demonstrably harmless? It's very difficult to read this any other way. Personally, I thought Jeff's formulation was very good. N.b. I'm not saying anyone HAS demonstrated that is harmless. I am saying that your statement indicates that you're not interested in that question. --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 7 21:46:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10689 for ; Thu, 7 Aug 2003 21:01:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvcr-0005bj-B7; Thu, 07 Aug 2003 21:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvc4-0005aP-BM for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 21:00:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10526 for ; Thu, 7 Aug 2003 21:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvc1-0004Ar-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:00:09 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kvc1-0004Ao-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:00:09 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kvc1-000GpX-Ig for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:00:09 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <910493458.20030807175927@psg.com> To: routing-discussion@ietf.org Subject: Re: Extending BGP In-Reply-To: <200308061440.h76EeYu60088@merlot.juniper.net> References: <200308061440.h76EeYu60088@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 17:59:27 -0700 Content-Transfer-Encoding: 7bit Let's keep the original concerns in mind. Yakov Rekhter wrote: >> Though it is possible to do a fine job of clearly separating different >> applications of the same protocol within the system, using a separate >> protocol makes it much more likely to happen. > Following your logic one should have a separate protocol per > application, each with "its own life with independent (from BGP) > features, extensions optimizations, etc." To repeat what I've said already, one of the major concerns is stability of Internet routing. Separating routing from non-routing applications is the main thing we are talking about here, but one can certainly follow any logic to an absurd extreme. > Since you agree that it is quite possible "to do a fine job of > clearly separating different applications of the same protocol within > the system", let me suggest that the folks who are capable of > doing such "fine job" should continue doing this, while the folks > who need a separate protocol to make this happen should pursue the > avenue of the separate protocol per application. The issue under discussion may affect very wide Internet community, and I believe that shrugging it off in a manner "if you believe there's an issue--it's your problem, feel free to solve it" would not be appropriate and would only further polarize the community. We're here to discuss the issue in the open and work out the direction for future efforts. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 7 21:46:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10688 for ; Thu, 7 Aug 2003 21:01:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvcy-0005eD-KZ for routing-discussion-archive@odin.ietf.org; Thu, 07 Aug 2003 21:01:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78118Pg021679 for routing-discussion-archive@odin.ietf.org; Thu, 7 Aug 2003 21:01:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvcr-0005br-SW; Thu, 07 Aug 2003 21:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvc8-0005aX-VB for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 21:00:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10531 for ; Thu, 7 Aug 2003 21:00:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvc6-0004Ax-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:00:14 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kvc5-0004Au-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:00:14 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kvc6-000Gq7-3m for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:00:14 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6710496503.20030807175930@psg.com> To: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <200308061513.h76FDUu61724@merlot.juniper.net> References: <200308061513.h76FDUu61724@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 17:59:30 -0700 Content-Transfer-Encoding: 7bit Wednesday, August 6, 2003, 8:13:30 AM, Yakov Rekhter wrote: > We also heard for quite some time that for the Internet inter-domain > routing BGP "may not be THE right choice in the long run". With > this in mind I would suggest for folks interested in "THE right > choice in the long run" to stop arguing against adding more stuff > to BGP, and instead join the folks working on "THE right choice in > the long run" for the Internet inter-domain routing. Discussing whether adding "more stuff to BGP" (or any foo on protocol X for that matter) is a good idea or not, and the long-term implications of the tendency to use protocols in such manner is certainly within the charter of the IETF, and protocol-specific WGs, so I don't believe that asking people who disagree to bail out of this discussion would be in the spirit of openness and fairness of the IETF process. > In a market-driven economy vendors usually pay attention to $$$, not > to a person's bashing his/her head against the brick wall. And here we will pay attention to all people who speak up and explain their positions, regardless of how much $$$ they have, but rather based on the technical substance of their arguments. > To paraphrase, I don't think that the ratio of the operators present > at the Open Routine Area meeting in Vienna (or for that matter the > operators who express their opinion on this mailing list) to operators > in the global marketplace are what they should be to produce a > reasonable sample of the operators' perspective on the issue. We are not in the business of producing "samples of the operators' perspective" worldwide here. Let's leave this to the marketing departments of our employers. We are here to reach consensus among the people who care about the issue and participate in the IETF. If someone believes that not enough SPs have spoken up in this discussion--feel free to invite them to contribute. > I don't think there is any disagreement on the need to provide > isolation between services. It is just that some folks claim that > (a) there is no way to provide such isolation within BGP, (despite > the fact that there are products on the market that do provide such > isolation with BGP), and that (b) the new protocol is going to > provide such isolation (which at the present moment is nothing but > an unsubstantiated claim). I think it is not exactly that black-n-white. The way I read the concerns people have about BGP overloading in particular is that folks feel that the BGP-based approach introduces a higher risk of interference with the routing functions than the non-BGP one. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 7 22:06:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11133 for ; Thu, 7 Aug 2003 21:20:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvvF-0006Rn-Ou; Thu, 07 Aug 2003 21:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvun-0006RH-Bf for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 21:19:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11109 for ; Thu, 7 Aug 2003 21:19:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvuk-0004IY-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:19:30 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kvuk-0004IV-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:19:30 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kvuk-000I0P-I4 for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:19:30 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <15211650582.20030807181844@psg.com> To: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: <200308061400.h76E0eu58144@merlot.juniper.net> References: <200308061400.h76E0eu58144@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 18:18:44 -0700 Content-Transfer-Encoding: 7bit Wednesday, August 6, 2003, 7:00:40 AM, Yakov Rekhter wrote: > The discussion should certainly include extensions to ISIS, like > carrying both IPv4 and IPv6 unicast routing, IPv4 unicast routes > used by IPv4 multicast, IPv6 unicast routes used by IPv6 multicast, > using ISIS Extensions for BGP Peer Discovery, using ISIS flooding > procedures to carry TE information. > With this in mind I'd like to hear from the folks who argue against > adding more stuff in BGP whether they also object against adding > more stuff into ISIS. ISIS and OSPF are certainly within the discussion. On the other hand, I believe it was emphasized enough on the list that the concern is largely about adding non-routing related info on RPs. I think there is a good level of understanding that RPs will have new features and extensions, but there is a desire to limit this to routing-related applications as opposed to whatever human imagination can come up with. Wednesday, August 6, 2003, 8:05:14 AM, Jeffrey Haas wrote: > (not specifically to Yakov) > Is there any way we can just frame this conversation as "how do we > keep from breaking things when we're working on extended them"? I don;t think so. "What should be put in a protocol" is also an important question in this discussion. Wednesday, August 6, 2003, 10:17:06 AM, Tony Li wrote: > That's an excellent point and perhaps the question that should have > been asked instead. The entire issue was initiated improperly by > assuming the answer. Far from that (assuming you mean another protocol). It is one of the possible directions, and there's nothing wrong in discussing those. Wednesday, August 6, 2003, 11:35:27 AM, Jeffrey Haas wrote: ... > That might be the right action. However, I think Alex (wearing his AD > hat) is trying to get us to tackle the general issue. BGP just > happens to be the thing where the problem is most obvious. Correct. There's a general issue of routing protocol overloading (i.e., what is the right stuff to put on a routing protocol?) and a more specific issue of MP-BGP. Expected outcome of the discussion is the overall direction and very specific action items for design teams and protocol-specific WGs. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 7 22:15:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12509 for ; Thu, 7 Aug 2003 22:15:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kwmT-0008Lz-5Q; Thu, 07 Aug 2003 22:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kwld-0008LY-Ho for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 22:14:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12449 for ; Thu, 7 Aug 2003 22:14:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kwla-0004cH-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 22:14:06 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19kwlZ-0004cB-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 22:14:05 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Aug 2003 19:18:40 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h782DWtp026541; Thu, 7 Aug 2003 19:13:33 -0700 (PDT) Received: from cisco.com (rtp-vpn2-284.cisco.com [10.82.241.28]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKD14293; Thu, 7 Aug 2003 19:07:18 -0700 (PDT) Message-ID: <3F33074B.6F640E6A@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: Alex Zinin , Routing Discussion Subject: Re: RP overloading: Next Steps References: <200308071833.h77IX0u70896@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 04:13:31 +0200 Content-Transfer-Encoding: 7bit Hi Yakov, > The "overloading" issue (if one believe that it exists) is applicable > to ISIS and OSPF as well. I actually beileve folks which are concerned or worried should not limit themselves to BGP, ISIS & OSPF. Why not also consider RSVP, SNMP, ICMP, LDP or HTTP and many other protocols which were originally desinged for something different and just evolved into other usefull uses ? Taken HTTP for example ... wasn't it the primary application to have a common protocol to access web pages ? Now aren't we also transporting files with http ? Taken ICMP was it meant from day one to serve as tool to determine link bandwith characteristics (pathchar) in the internet ? Thx, R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 7 22:15:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12510 for ; Thu, 7 Aug 2003 22:15:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kwma-0008NK-2s for routing-discussion-archive@odin.ietf.org; Thu, 07 Aug 2003 22:15:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h782F8Ja032172 for routing-discussion-archive@odin.ietf.org; Thu, 7 Aug 2003 22:15:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kwmT-0008Lz-5Q; Thu, 07 Aug 2003 22:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kwld-0008LY-Ho for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 22:14:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12449 for ; Thu, 7 Aug 2003 22:14:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kwla-0004cH-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 22:14:06 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19kwlZ-0004cB-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 22:14:05 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Aug 2003 19:18:40 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h782DWtp026541; Thu, 7 Aug 2003 19:13:33 -0700 (PDT) Received: from cisco.com (rtp-vpn2-284.cisco.com [10.82.241.28]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKD14293; Thu, 7 Aug 2003 19:07:18 -0700 (PDT) Message-ID: <3F33074B.6F640E6A@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: Alex Zinin , Routing Discussion Subject: Re: RP overloading: Next Steps References: <200308071833.h77IX0u70896@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 04:13:31 +0200 Content-Transfer-Encoding: 7bit Hi Yakov, > The "overloading" issue (if one believe that it exists) is applicable > to ISIS and OSPF as well. I actually beileve folks which are concerned or worried should not limit themselves to BGP, ISIS & OSPF. Why not also consider RSVP, SNMP, ICMP, LDP or HTTP and many other protocols which were originally desinged for something different and just evolved into other usefull uses ? Taken HTTP for example ... wasn't it the primary application to have a common protocol to access web pages ? Now aren't we also transporting files with http ? Taken ICMP was it meant from day one to serve as tool to determine link bandwith characteristics (pathchar) in the internet ? Thx, R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 7 22:21:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11386 for ; Thu, 7 Aug 2003 21:32:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kw6z-0006ux-E4 for routing-discussion-archive@odin.ietf.org; Thu, 07 Aug 2003 21:32:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h781W9Bc026562 for routing-discussion-archive@odin.ietf.org; Thu, 7 Aug 2003 21:32:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kw6r-0006tg-VQ; Thu, 07 Aug 2003 21:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kw5y-0006q6-DM for routing-discussion@optimus.ietf.org; Thu, 07 Aug 2003 21:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11364 for ; Thu, 7 Aug 2003 21:31:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kw5v-0004Mb-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:31:03 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19kw5u-0004MS-00 for routing-discussion@ietf.org; Thu, 07 Aug 2003 21:31:03 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h781UV7F026898; Thu, 7 Aug 2003 18:30:31 -0700 (PDT) Received: from [192.168.42.4] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA09608; Thu, 7 Aug 2003 21:30:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <15211650582.20030807181844@psg.com> References: <200308061400.h76E0eu58144@merlot.juniper.net> <15211650582.20030807181844@psg.com> To: Alex Zinin From: "John G. Scudder" Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Cc: routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 21:30:11 -0400 At 6:18 PM -0700 8/7/03, Alex Zinin wrote: >Wednesday, August 6, 2003, 8:05:14 AM, Jeffrey Haas wrote: > > (not specifically to Yakov) >> Is there any way we can just frame this conversation as "how do we >> keep from breaking things when we're working on extended them"? > >I don;t think so. "What should be put in a protocol" is also an >important question in this discussion. You're saying that "what should be put in a protocol" is an important question regardless of whether said extensions are demonstrably harmless? It's very difficult to read this any other way. Personally, I thought Jeff's formulation was very good. N.b. I'm not saying anyone HAS demonstrated that is harmless. I am saying that your statement indicates that you're not interested in that question. --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 00:39:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15670 for ; Fri, 8 Aug 2003 00:39:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz1p-0004aZ-KJ; Fri, 08 Aug 2003 00:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz1J-0004aL-4u for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 00:38:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15625 for ; Fri, 8 Aug 2003 00:38:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kz1G-0005HC-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:38:26 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19kz1G-0005Gu-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:38:26 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 8743D20298 for ; Thu, 7 Aug 2003 22:40:59 -0600 (MDT) Subject: Re: RP overloading: Next Steps Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: Routing Discussion Content-Transfer-Encoding: 7bit In-Reply-To: <3F33074B.6F640E6A@cisco.com> Message-Id: <14B5E92B-C95A-11D7-BD97-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 22:37:56 -0600 Content-Transfer-Encoding: 7bit On Thursday, August 7, 2003, at 08:13 PM, Robert Raszuk wrote: > > I actually beileve folks which are concerned or worried should not > limit > themselves to BGP, ISIS & OSPF. Why not also consider RSVP, SNMP, ICMP, > LDP or HTTP and many other protocols which were originally desinged for > something different and just evolved into other usefull uses ? > > Taken HTTP for example ... wasn't it the primary application to have a > common protocol to access web pages ? Now aren't we also transporting > files with http ? Taken ICMP was it meant from day one to serve as tool > to determine link bandwith characteristics (pathchar) in the internet ? Because this is the Routing Area and we're _primarily concerned with routing protocols, not routed protocols. -danny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 00:47:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15939 for ; Fri, 8 Aug 2003 00:47:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz9Y-0004wC-TV; Fri, 08 Aug 2003 00:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz8d-0004sr-H3 for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 00:46:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15886 for ; Fri, 8 Aug 2003 00:45:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kz8a-0005Kf-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:46:00 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19kz8a-0005Kc-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:46:00 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19kz8a-0008lT-PI; Thu, 07 Aug 2003 21:46:00 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Raszuk Cc: Routing Discussion Subject: Re: RP overloading: Next Steps References: <200308071833.h77IX0u70896@merlot.juniper.net> <3F33074B.6F640E6A@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 21:46:00 -0700 Content-Transfer-Encoding: 7bit > I actually beileve folks which are concerned or worried should not limit > themselves to BGP, ISIS & OSPF. Why not also consider RSVP, SNMP, ICMP, > LDP or HTTP and many other protocols which were originally desinged for > something different and just evolved into other usefull uses ? i, for one, have done so consistently for years. e.g., see my plenary talk from the most recent san diego meeting. but perhaps, instead of discussing personalities, we should stick to principles? randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 00:47:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15940 for ; Fri, 8 Aug 2003 00:47:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz9Z-0004wl-Dt for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 00:47:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h784l1OW018997 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 00:47:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz9Y-0004wC-TV; Fri, 08 Aug 2003 00:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz8d-0004sr-H3 for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 00:46:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15886 for ; Fri, 8 Aug 2003 00:45:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kz8a-0005Kf-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:46:00 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19kz8a-0005Kc-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:46:00 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19kz8a-0008lT-PI; Thu, 07 Aug 2003 21:46:00 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Raszuk Cc: Routing Discussion Subject: Re: RP overloading: Next Steps References: <200308071833.h77IX0u70896@merlot.juniper.net> <3F33074B.6F640E6A@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 21:46:00 -0700 Content-Transfer-Encoding: 7bit > I actually beileve folks which are concerned or worried should not limit > themselves to BGP, ISIS & OSPF. Why not also consider RSVP, SNMP, ICMP, > LDP or HTTP and many other protocols which were originally desinged for > something different and just evolved into other usefull uses ? i, for one, have done so consistently for years. e.g., see my plenary talk from the most recent san diego meeting. but perhaps, instead of discussing personalities, we should stick to principles? randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 00:53:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16094 for ; Fri, 8 Aug 2003 00:53:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kzFN-0005Ay-9S; Fri, 08 Aug 2003 00:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kzES-0005Aa-Nm for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 00:52:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16039 for ; Fri, 8 Aug 2003 00:51:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kzEP-0005NB-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:52:01 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19kzEP-0005N3-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:52:01 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 5401620298 for ; Thu, 7 Aug 2003 22:54:33 -0600 (MDT) Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: routing-discussion@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <15211650582.20030807181844@psg.com> Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 22:51:26 -0600 Content-Transfer-Encoding: 7bit On Thursday, August 7, 2003, at 07:18 PM, Alex Zinin wrote: > ISIS and OSPF are certainly within the discussion. And for many of the same reasons (i.e., IGP instabilities can trigger BGP instability, and subsequently, global instabilities, which are largely what some folks seem to _only be concerned with). For example, IGP adjacency state changes trigger new BGP updates per IGP-derived MED values, subsequently triggering new paths selected by adjacent routing domains, and so forth, resulting in convergence issues and a domino effect for downstream ASes. I think to address the issue generically is best (e.g., to determine what encompasses "routing information"). -danny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 01:27:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15671 for ; Fri, 8 Aug 2003 00:39:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz1w-0004bg-Ch for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 00:39:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h784d8nm017690 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 00:39:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz1p-0004aZ-KJ; Fri, 08 Aug 2003 00:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kz1J-0004aL-4u for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 00:38:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15625 for ; Fri, 8 Aug 2003 00:38:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kz1G-0005HC-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:38:26 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19kz1G-0005Gu-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:38:26 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 8743D20298 for ; Thu, 7 Aug 2003 22:40:59 -0600 (MDT) Subject: Re: RP overloading: Next Steps Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: Routing Discussion Content-Transfer-Encoding: 7bit In-Reply-To: <3F33074B.6F640E6A@cisco.com> Message-Id: <14B5E92B-C95A-11D7-BD97-000393D54EA6@tcb.net> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 22:37:56 -0600 Content-Transfer-Encoding: 7bit On Thursday, August 7, 2003, at 08:13 PM, Robert Raszuk wrote: > > I actually beileve folks which are concerned or worried should not > limit > themselves to BGP, ISIS & OSPF. Why not also consider RSVP, SNMP, ICMP, > LDP or HTTP and many other protocols which were originally desinged for > something different and just evolved into other usefull uses ? > > Taken HTTP for example ... wasn't it the primary application to have a > common protocol to access web pages ? Now aren't we also transporting > files with http ? Taken ICMP was it meant from day one to serve as tool > to determine link bandwith characteristics (pathchar) in the internet ? Because this is the Routing Area and we're _primarily concerned with routing protocols, not routed protocols. -danny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 01:29:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16706 for ; Fri, 8 Aug 2003 01:29:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kzoD-0006Lo-NJ; Fri, 08 Aug 2003 01:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kznd-0006LO-9L for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 01:28:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16678 for ; Fri, 8 Aug 2003 01:28:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kzna-0005W5-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:28:22 -0400 Received: from law12-f126.law12.hotmail.com ([64.4.19.126] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19kznZ-0005Vu-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:28:21 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 Aug 2003 22:27:52 -0700 Received: from 63.197.79.145 by lw12fd.law12.hotmail.msn.com with HTTP; Fri, 08 Aug 2003 05:27:52 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [george_s97@hotmail.com] From: "George Sheng" To: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2003 05:27:52.0423 (UTC) FILETIME=[D0500770:01C35D6D] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 05:27:52 +0000 >For example, IGP adjacency state changes trigger new BGP >updates per IGP-derived MED values, subsequently triggering >new paths selected by adjacent routing domains, and so forth, >resulting in convergence issues and a domino effect for >downstream ASes. Let's also not forget to consider not "overloading" a local IP interface with unnecessary features. If an Interface bounces, it will cause IGP adjacency bounce/unstable, which in turn will cause BGP unstable. We at least need to have some guidelines on what features should or should not be added onto the IP intefaces. - George _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 01:29:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16709 for ; Fri, 8 Aug 2003 01:29:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kzoI-0006N1-3V for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 01:29:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h785T6mZ024466 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 01:29:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kzoD-0006Lo-NJ; Fri, 08 Aug 2003 01:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kznd-0006LO-9L for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 01:28:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16678 for ; Fri, 8 Aug 2003 01:28:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kzna-0005W5-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:28:22 -0400 Received: from law12-f126.law12.hotmail.com ([64.4.19.126] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19kznZ-0005Vu-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:28:21 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 Aug 2003 22:27:52 -0700 Received: from 63.197.79.145 by lw12fd.law12.hotmail.msn.com with HTTP; Fri, 08 Aug 2003 05:27:52 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [george_s97@hotmail.com] From: "George Sheng" To: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2003 05:27:52.0423 (UTC) FILETIME=[D0500770:01C35D6D] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 05:27:52 +0000 >For example, IGP adjacency state changes trigger new BGP >updates per IGP-derived MED values, subsequently triggering >new paths selected by adjacent routing domains, and so forth, >resulting in convergence issues and a domino effect for >downstream ASes. Let's also not forget to consider not "overloading" a local IP interface with unnecessary features. If an Interface bounces, it will cause IGP adjacency bounce/unstable, which in turn will cause BGP unstable. We at least need to have some guidelines on what features should or should not be added onto the IP intefaces. - George _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 01:42:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16095 for ; Fri, 8 Aug 2003 00:53:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kzFO-0005CC-Ny for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 00:53:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h784r2Uo019950 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 00:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kzFN-0005Ay-9S; Fri, 08 Aug 2003 00:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kzES-0005Aa-Nm for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 00:52:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16039 for ; Fri, 8 Aug 2003 00:51:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kzEP-0005NB-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:52:01 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19kzEP-0005N3-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 00:52:01 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 5401620298 for ; Thu, 7 Aug 2003 22:54:33 -0600 (MDT) Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: routing-discussion@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <15211650582.20030807181844@psg.com> Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 22:51:26 -0600 Content-Transfer-Encoding: 7bit On Thursday, August 7, 2003, at 07:18 PM, Alex Zinin wrote: > ISIS and OSPF are certainly within the discussion. And for many of the same reasons (i.e., IGP instabilities can trigger BGP instability, and subsequently, global instabilities, which are largely what some folks seem to _only be concerned with). For example, IGP adjacency state changes trigger new BGP updates per IGP-derived MED values, subsequently triggering new paths selected by adjacent routing domains, and so forth, resulting in convergence issues and a domino effect for downstream ASes. I think to address the issue generically is best (e.g., to determine what encompasses "routing information"). -danny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 02:52:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01503 for ; Fri, 8 Aug 2003 02:52:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l16X-0003Vs-3C; Fri, 08 Aug 2003 02:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l15b-0003UG-2K for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 02:51:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01473 for ; Fri, 8 Aug 2003 02:50:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l15X-0006H8-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 02:50:59 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19l15W-0006H5-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 02:50:58 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19l15X-000Ai3-KM; Fri, 08 Aug 2003 06:50:59 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6631570906.20030807235045@psg.com> To: "John G. Scudder" CC: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: References: <200308061400.h76E0eu58144@merlot.juniper.net> <15211650582.20030807181844@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 23:50:45 -0700 Content-Transfer-Encoding: 7bit John, Let's first make sure we don't interpret Jeff's words differently. What I meant is that not breaking while extending may be read as "without really thinking much _what_ extensions we put in, let's ensure we don't break the thing". While this is necessary, I don't think it's enough. I believe we should be asking ourselves questions whether belongs in a protocol, and add it only if we believe it does and, as you say, it is demonstrably harmless. Are we on the same page? Alex >>> Is there any way we can just frame this conversation as "how do we >>> keep from breaking things when we're working on extended them"? >> >>I don;t think so. "What should be put in a protocol" is also an >>important question in this discussion. > You're saying that "what should be put in a protocol" is an important > question regardless of whether said extensions are demonstrably > harmless? > It's very difficult to read this any other way. Personally, I > thought Jeff's formulation was very good. > N.b. I'm not saying anyone HAS demonstrated that is harmless. > I am saying that your statement indicates that you're not interested > in that question. > --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 02:52:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01518 for ; Fri, 8 Aug 2003 02:52:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l16j-0003Y5-5e for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 02:52:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h786qDwV013563 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 02:52:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l16X-0003Vs-3C; Fri, 08 Aug 2003 02:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l15b-0003UG-2K for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 02:51:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01473 for ; Fri, 8 Aug 2003 02:50:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l15X-0006H8-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 02:50:59 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19l15W-0006H5-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 02:50:58 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19l15X-000Ai3-KM; Fri, 08 Aug 2003 06:50:59 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6631570906.20030807235045@psg.com> To: "John G. Scudder" CC: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: References: <200308061400.h76E0eu58144@merlot.juniper.net> <15211650582.20030807181844@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 7 Aug 2003 23:50:45 -0700 Content-Transfer-Encoding: 7bit John, Let's first make sure we don't interpret Jeff's words differently. What I meant is that not breaking while extending may be read as "without really thinking much _what_ extensions we put in, let's ensure we don't break the thing". While this is necessary, I don't think it's enough. I believe we should be asking ourselves questions whether belongs in a protocol, and add it only if we believe it does and, as you say, it is demonstrably harmless. Are we on the same page? Alex >>> Is there any way we can just frame this conversation as "how do we >>> keep from breaking things when we're working on extended them"? >> >>I don;t think so. "What should be put in a protocol" is also an >>important question in this discussion. > You're saying that "what should be put in a protocol" is an important > question regardless of whether said extensions are demonstrably > harmless? > It's very difficult to read this any other way. Personally, I > thought Jeff's formulation was very good. > N.b. I'm not saying anyone HAS demonstrated that is harmless. > I am saying that your statement indicates that you're not interested > in that question. > --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 03:44:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02438 for ; Fri, 8 Aug 2003 03:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1ur-00068M-OQ; Fri, 08 Aug 2003 03:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1u8-000678-Tw for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 03:43:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02413 for ; Fri, 8 Aug 2003 03:43:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l1u6-0006U0-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 03:43:14 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19l1u5-0006Tn-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 03:43:13 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h787giu21343; Fri, 8 Aug 2003 00:42:44 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h787gir91485; Fri, 8 Aug 2003 00:42:44 -0700 (PDT) (envelope-from roque) Message-Id: <200308080742.h787gir91485@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: a problem statement (was: Extending BGP) In-Reply-To: <910493458.20030807175927@psg.com> References: <200308061440.h76EeYu60088@merlot.juniper.net> <910493458.20030807175927@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 00:42:44 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: > Let's keep the original concerns in mind. > To repeat what I've said already, one of the major concerns is > stability of Internet routing. If that is the goal or one of the goals you are trying to pursue, it would seem to me that you would have to go through the process of analyzing what it depends on and gather data as to what causes of instability. Most service providers keep information of which defects cause faults in their network, for instance, and many times have information about their root causes. However, imho, the reasons behind this discussion have nothing to do with extending routing protocols and much less how to do so. One need only keep in mind that the characteristics of unextended-BGP are much more of an issue in operational networks than any extensions. IMHO, the real issue behind this debate is that services providers are themselfs internally divided about issues of future direction and service offerings. There are people that believe in an IP-centric service offering and/or infrastructure and people that believe that there is the requirement to converge network infrastructure and/or provide additional services. Some in the IP-centric camp are attempting to get a statment from the IETF that going against their particular view of the world threatens the stability of the internet. I personally have no idea which faction is correct in terms of direction given it is essentially a commercial decision based on data which i don't have access to. But it seems to me that it is a rather poor idea to attempt to settle it in the IETF precisely because it is a commercial decision. And one that is particular to each service provider. Lets assume for a moment that the IETF publishes a document which says that "multi-service offering networks" are a treat to internet stability or something of the sort. How is that going to fly on a discussion with management or the marketing department on a given carrier/provider ? Does anyone really intend to suggest to their marketing department to be really creative and sell the fact that they don't provide a given service offering ? The "stability of the internet" is a scare tactic that simply won't fly with management on any service provider, imho. The IETF can and should address engineering problems... in this case it means make the upmost to make services successful and deployable. Which is the exact opposite of what the people that don't "want to see any code changes" are looking for... Providing fault isolation in a multi-service router is something that probably most vendors are working on/have products/have powerpoint. It is however a problem that doesn't start or end in BGP. This is also an issue that service providers have been working on with vendors for a considerable amount of time, in a constructive way and with demonstrable results. If people want to work on this particular goal i would suggest starting w/ the requirement lists that have been developed by several SPs. Some of these are already quite mature by now. Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 04:12:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03125 for ; Fri, 8 Aug 2003 04:12:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2Ly-0007e1-2j; Fri, 08 Aug 2003 04:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2LA-0007aC-MH for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 04:11:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03086 for ; Fri, 8 Aug 2003 04:11:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2L8-0006em-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 04:11:10 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19l2L7-0006eY-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 04:11:09 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 1743523C5A; Fri, 8 Aug 2003 00:21:00 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h788AdYB014234; Fri, 8 Aug 2003 01:10:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: a problem statement (was: Extending BGP) Message-ID: Thread-Topic: a problem statement (was: Extending BGP) Thread-Index: AcNdgOi7KvR7xc8/Q2+eJziEKZytMwAA19Cw From: "Tony Li" To: "Pedro Roque Marques" , "Alex Zinin" Cc: Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 01:10:39 -0700 Content-Transfer-Encoding: quoted-printable Well said, here here!!! Further, if an SP is going to make the commercial=20 decision to support said services, whether or not they are in BGP or some other protocol, they will still be part of whatever implementation, sharing the same processor and memory resources. Just shifting the deck chairs doesn't change the amount of wood on the deck. Tony | -----Original Message----- | From: Pedro Roque Marques [mailto:roque@juniper.net]=20 | Sent: Friday, August 08, 2003 12:43 AM | To: Alex Zinin | Cc: routing-discussion@ietf.org | Subject: a problem statement (was: Extending BGP) | =20 | =20 | Alex Zinin writes: | =20 | > Let's keep the original concerns in mind. | =20 | > To repeat what I've said already, one of the major concerns is | > stability of Internet routing. | =20 | If that is the goal or one of the goals you are trying to=20 | pursue, it | would seem to me that you would have to go through the process of | analyzing what it depends on and gather data as to what causes of | instability. Most service providers keep information of=20 | which defects | cause faults in their network, for instance, and many times have | information about their root causes. | =20 | However, imho, the reasons behind this discussion have=20 | nothing to do | with extending routing protocols and much less how to do=20 | so. One need | only keep in mind that the characteristics of=20 | unextended-BGP are much | more of an issue in operational networks than any extensions. | =20 | IMHO, the real issue behind this debate is that services=20 | providers are | themselfs internally divided about issues of future direction and | service offerings. There are people that believe in an IP-centric | service offering and/or infrastructure and people that believe that | there is the requirement to converge network infrastructure and/or | provide additional services. | =20 | Some in the IP-centric camp are attempting to get a=20 | statment from the | IETF that going against their particular view of the world=20 | threatens | the stability of the internet. | =20 | I personally have no idea which faction is correct in terms of | direction given it is essentially a commercial decision=20 | based on data | which i don't have access to. | =20 | But it seems to me that it is a rather poor idea to=20 | attempt to settle | it in the IETF precisely because it is a commercial=20 | decision. And one | that is particular to each service provider. | =20 | Lets assume for a moment that the IETF publishes a=20 | document which says | that "multi-service offering networks" are a treat to internet | stability or something of the sort. How is that going to fly on a | discussion with management or the marketing department on a given | carrier/provider ? Does anyone really intend to suggest to their | marketing department to be really creative and sell the=20 | fact that they | don't provide a given service offering ? | =20 | The "stability of the internet" is a scare tactic that simply won't | fly with management on any service provider, imho. | =20 | The IETF can and should address engineering problems... in=20 | this case | it means make the upmost to make services successful and | deployable. Which is the exact opposite of what the people=20 | that don't | "want to see any code changes" are looking for... | =20 | Providing fault isolation in a multi-service router is=20 | something that | probably most vendors are working on/have products/have=20 | powerpoint. It | is however a problem that doesn't start or end in BGP. | =20 | This is also an issue that service providers have been=20 | working on with | vendors for a considerable amount of time, in a=20 | constructive way and | with demonstrable results. | =20 | If people want to work on this particular goal i would suggest | starting w/ the requirement lists that have been developed=20 | by several | SPs. Some of these are already quite mature by now. | =20 | Pedro. | =20 | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 04:12:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03127 for ; Fri, 8 Aug 2003 04:12:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2M6-0007es-Vm for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 04:12:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h788CAIK029439 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 04:12:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2Ly-0007e1-2j; Fri, 08 Aug 2003 04:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2LA-0007aC-MH for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 04:11:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03086 for ; Fri, 8 Aug 2003 04:11:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2L8-0006em-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 04:11:10 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19l2L7-0006eY-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 04:11:09 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 1743523C5A; Fri, 8 Aug 2003 00:21:00 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h788AdYB014234; Fri, 8 Aug 2003 01:10:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: a problem statement (was: Extending BGP) Message-ID: Thread-Topic: a problem statement (was: Extending BGP) Thread-Index: AcNdgOi7KvR7xc8/Q2+eJziEKZytMwAA19Cw From: "Tony Li" To: "Pedro Roque Marques" , "Alex Zinin" Cc: Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 01:10:39 -0700 Content-Transfer-Encoding: quoted-printable Well said, here here!!! Further, if an SP is going to make the commercial=20 decision to support said services, whether or not they are in BGP or some other protocol, they will still be part of whatever implementation, sharing the same processor and memory resources. Just shifting the deck chairs doesn't change the amount of wood on the deck. Tony | -----Original Message----- | From: Pedro Roque Marques [mailto:roque@juniper.net]=20 | Sent: Friday, August 08, 2003 12:43 AM | To: Alex Zinin | Cc: routing-discussion@ietf.org | Subject: a problem statement (was: Extending BGP) | =20 | =20 | Alex Zinin writes: | =20 | > Let's keep the original concerns in mind. | =20 | > To repeat what I've said already, one of the major concerns is | > stability of Internet routing. | =20 | If that is the goal or one of the goals you are trying to=20 | pursue, it | would seem to me that you would have to go through the process of | analyzing what it depends on and gather data as to what causes of | instability. Most service providers keep information of=20 | which defects | cause faults in their network, for instance, and many times have | information about their root causes. | =20 | However, imho, the reasons behind this discussion have=20 | nothing to do | with extending routing protocols and much less how to do=20 | so. One need | only keep in mind that the characteristics of=20 | unextended-BGP are much | more of an issue in operational networks than any extensions. | =20 | IMHO, the real issue behind this debate is that services=20 | providers are | themselfs internally divided about issues of future direction and | service offerings. There are people that believe in an IP-centric | service offering and/or infrastructure and people that believe that | there is the requirement to converge network infrastructure and/or | provide additional services. | =20 | Some in the IP-centric camp are attempting to get a=20 | statment from the | IETF that going against their particular view of the world=20 | threatens | the stability of the internet. | =20 | I personally have no idea which faction is correct in terms of | direction given it is essentially a commercial decision=20 | based on data | which i don't have access to. | =20 | But it seems to me that it is a rather poor idea to=20 | attempt to settle | it in the IETF precisely because it is a commercial=20 | decision. And one | that is particular to each service provider. | =20 | Lets assume for a moment that the IETF publishes a=20 | document which says | that "multi-service offering networks" are a treat to internet | stability or something of the sort. How is that going to fly on a | discussion with management or the marketing department on a given | carrier/provider ? Does anyone really intend to suggest to their | marketing department to be really creative and sell the=20 | fact that they | don't provide a given service offering ? | =20 | The "stability of the internet" is a scare tactic that simply won't | fly with management on any service provider, imho. | =20 | The IETF can and should address engineering problems... in=20 | this case | it means make the upmost to make services successful and | deployable. Which is the exact opposite of what the people=20 | that don't | "want to see any code changes" are looking for... | =20 | Providing fault isolation in a multi-service router is=20 | something that | probably most vendors are working on/have products/have=20 | powerpoint. It | is however a problem that doesn't start or end in BGP. | =20 | This is also an issue that service providers have been=20 | working on with | vendors for a considerable amount of time, in a=20 | constructive way and | with demonstrable results. | =20 | If people want to work on this particular goal i would suggest | starting w/ the requirement lists that have been developed=20 | by several | SPs. Some of these are already quite mature by now. | =20 | Pedro. | =20 | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 04:22:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03420 for ; Fri, 8 Aug 2003 04:22:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2Vf-000886-2h; Fri, 08 Aug 2003 04:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2VM-00086M-8U for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 04:21:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03391 for ; Fri, 8 Aug 2003 04:21:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2VJ-0006it-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 04:21:41 -0400 Received: from [192.43.230.3] (helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19l2VI-0006iq-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 04:21:40 -0400 Received: from mrp.net (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h788LSB8001153; Fri, 8 Aug 2003 17:51:37 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F335D88.3060708@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement (was: Extending BGP) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 17:51:28 +0930 Content-Transfer-Encoding: 7bit Tony Li wrote: > > Well said, here here!!! > > Further, if an SP is going to make the commercial > decision to support said services, whether or not they > are in BGP or some other protocol, they will still be part > of whatever implementation, sharing the same processor > and memory resources. Just shifting the deck chairs doesn't > change the amount of wood on the deck. > But if the SP doesn't want those services and they are separate processes then they don't have to turn them on. If they are built into something else that the SP does want to run then they probably get the bugs whether they like it or not. Mark. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 04:22:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03422 for ; Fri, 8 Aug 2003 04:22:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2Vh-00089R-SW for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 04:22:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h788M5F3031282 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 04:22:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2Vf-000886-2h; Fri, 08 Aug 2003 04:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2VM-00086M-8U for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 04:21:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03391 for ; Fri, 8 Aug 2003 04:21:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2VJ-0006it-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 04:21:41 -0400 Received: from [192.43.230.3] (helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19l2VI-0006iq-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 04:21:40 -0400 Received: from mrp.net (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h788LSB8001153; Fri, 8 Aug 2003 17:51:37 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F335D88.3060708@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement (was: Extending BGP) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 17:51:28 +0930 Content-Transfer-Encoding: 7bit Tony Li wrote: > > Well said, here here!!! > > Further, if an SP is going to make the commercial > decision to support said services, whether or not they > are in BGP or some other protocol, they will still be part > of whatever implementation, sharing the same processor > and memory resources. Just shifting the deck chairs doesn't > change the amount of wood on the deck. > But if the SP doesn't want those services and they are separate processes then they don't have to turn them on. If they are built into something else that the SP does want to run then they probably get the bugs whether they like it or not. Mark. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 04:32:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02440 for ; Fri, 8 Aug 2003 03:44:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1uw-00069C-20 for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 03:44:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h787i67F023630 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 03:44:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1ur-00068M-OQ; Fri, 08 Aug 2003 03:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1u8-000678-Tw for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 03:43:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02413 for ; Fri, 8 Aug 2003 03:43:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l1u6-0006U0-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 03:43:14 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19l1u5-0006Tn-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 03:43:13 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h787giu21343; Fri, 8 Aug 2003 00:42:44 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h787gir91485; Fri, 8 Aug 2003 00:42:44 -0700 (PDT) (envelope-from roque) Message-Id: <200308080742.h787gir91485@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: a problem statement (was: Extending BGP) In-Reply-To: <910493458.20030807175927@psg.com> References: <200308061440.h76EeYu60088@merlot.juniper.net> <910493458.20030807175927@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 00:42:44 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: > Let's keep the original concerns in mind. > To repeat what I've said already, one of the major concerns is > stability of Internet routing. If that is the goal or one of the goals you are trying to pursue, it would seem to me that you would have to go through the process of analyzing what it depends on and gather data as to what causes of instability. Most service providers keep information of which defects cause faults in their network, for instance, and many times have information about their root causes. However, imho, the reasons behind this discussion have nothing to do with extending routing protocols and much less how to do so. One need only keep in mind that the characteristics of unextended-BGP are much more of an issue in operational networks than any extensions. IMHO, the real issue behind this debate is that services providers are themselfs internally divided about issues of future direction and service offerings. There are people that believe in an IP-centric service offering and/or infrastructure and people that believe that there is the requirement to converge network infrastructure and/or provide additional services. Some in the IP-centric camp are attempting to get a statment from the IETF that going against their particular view of the world threatens the stability of the internet. I personally have no idea which faction is correct in terms of direction given it is essentially a commercial decision based on data which i don't have access to. But it seems to me that it is a rather poor idea to attempt to settle it in the IETF precisely because it is a commercial decision. And one that is particular to each service provider. Lets assume for a moment that the IETF publishes a document which says that "multi-service offering networks" are a treat to internet stability or something of the sort. How is that going to fly on a discussion with management or the marketing department on a given carrier/provider ? Does anyone really intend to suggest to their marketing department to be really creative and sell the fact that they don't provide a given service offering ? The "stability of the internet" is a scare tactic that simply won't fly with management on any service provider, imho. The IETF can and should address engineering problems... in this case it means make the upmost to make services successful and deployable. Which is the exact opposite of what the people that don't "want to see any code changes" are looking for... Providing fault isolation in a multi-service router is something that probably most vendors are working on/have products/have powerpoint. It is however a problem that doesn't start or end in BGP. This is also an issue that service providers have been working on with vendors for a considerable amount of time, in a constructive way and with demonstrable results. If people want to work on this particular goal i would suggest starting w/ the requirement lists that have been developed by several SPs. Some of these are already quite mature by now. Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 09:55:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10787 for ; Fri, 8 Aug 2003 09:55:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7i1-0005Ij-6H for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 09:55:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Dt9lU020371 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 09:55:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7hu-0005HS-IM; Fri, 08 Aug 2003 09:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7hE-0005G8-OT for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 09:54:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10756 for ; Fri, 8 Aug 2003 09:54:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7hC-0000nG-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 09:54:18 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19l7hB-0000mB-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 09:54:18 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78Drdr4078512; Fri, 8 Aug 2003 09:53:39 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h78DrYLu078500; Fri, 8 Aug 2003 09:53:35 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h78DrTn07308; Fri, 8 Aug 2003 09:53:29 -0400 (EDT) From: Jeffrey Haas To: Alex Zinin Cc: "John G. Scudder" , routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: <20030808095329.A7223@nexthop.com> References: <200308061400.h76E0eu58144@merlot.juniper.net> <15211650582.20030807181844@psg.com> <6631570906.20030807235045@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6631570906.20030807235045@psg.com>; from zinin@psg.com on Thu, Aug 07, 2003 at 11:50:45PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 09:53:29 -0400 [reordering] On Thu, Aug 07, 2003 at 11:50:45PM -0700, Alex Zinin wrote: > I believe we should be asking ourselves questions whether > belongs in a protocol, and add it only if we believe it does and, as > you say, it is demonstrably harmless. There's "harmless" and "harmless". The more state you need to keep and transmit, the more copies of something BGP is going to get. If is suitable to be modified on a hop-by-hop basis then it is posibly suitable to be put into BGP. However, putting more and more in means that the routers have more to transmit, keep state on, do path calculations for, etc. The fact that we have this grand knob for AFI/SAFI's means that so long as we don't put stuff in that makes things *mandatory* for the protocol to scale, we can put stuff in the protocol and let the network operators decide how far their dollars will go in putting enough hardware in place to handle it. VPLS made me think for a bit since many cases seem to be more suited to a flooding-style protocol. The key that Pedro gave me to grok why BGP makes more sense is the fact that *policy* is applied. If we had something that did policy on flooded information, it might make more sense to not use BGP. Unfortunately, then we have to deal with the inter-domain case. Similar "harmless" issues haunt IGP's. If you stick something into the LSDB, it's going to take up memory whether you use it or not. Since the database calculation is distributed rather than by rumor, this means that you simply need one box in an important spot to get too much information, run out of memory and crash and your network is very unhappy. While this isn't quite as bad as flooding your BGP into your OSPF, it can be a close second. [...] > Let's first make sure we don't interpret Jeff's words differently. > > What I meant is that not breaking while extending may be read as > "without really thinking much _what_ extensions we put in, let's > ensure we don't break the thing". While this is necessary, I don't > think it's enough. "He who breaks a thing to understand what it is, has left the paths of wisdom." :-) -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 10:01:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11137 for ; Fri, 8 Aug 2003 10:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7ni-0005WH-1p; Fri, 08 Aug 2003 10:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7nS-0005VG-PQ for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 10:00:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11102 for ; Fri, 8 Aug 2003 10:00:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7nQ-0000sq-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:00:44 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19l7nQ-0000sQ-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:00:44 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 08 Aug 2003 07:05:25 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h78E09Xw018129; Fri, 8 Aug 2003 10:00:10 -0400 (EDT) Message-Id: <200308081400.h78E09Xw018129@rtp-core-1.cisco.com> To: Mark Prior cc: Tony Li , Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement (was: Extending BGP) In-reply-to: Your message of Fri, 08 Aug 2003 17:51:28 +0930. <3F335D88.3060708@mrp.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 10:00:09 -0400 Mark> But if the SP doesn't want those services and they are separate Mark> processes then they don't have to turn them on. If they are built into Mark> something else that the SP does want to run then they probably get the Mark> bugs whether they like it or not. What you are really saying is that you want to be able to get an image which has only the features you care about and no others. It seems to me that this is an issue between you and your vendor, and the IETF has nothing to do with it. No vendor would ever decide how to set up the process structure of a particular box based on what the IETF says. And if you have vendor quality issues, don't expect that they will be resolved by IETF discussion. The discussion has revealed a couple of specific areas where certain protocol features of BGP may make it difficult to get the desired level of robustness. It seems that these can be addressed by BGP enhancements like "soft notifications" or "multiple sessions without multiple addresses", things that can be addressed in the IDR WG. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 10:01:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11152 for ; Fri, 8 Aug 2003 10:01:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7nl-0005YX-UB for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 10:01:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78E15JS021341 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 10:01:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7ni-0005WH-1p; Fri, 08 Aug 2003 10:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7nS-0005VG-PQ for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 10:00:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11102 for ; Fri, 8 Aug 2003 10:00:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7nQ-0000sq-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:00:44 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19l7nQ-0000sQ-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:00:44 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 08 Aug 2003 07:05:25 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h78E09Xw018129; Fri, 8 Aug 2003 10:00:10 -0400 (EDT) Message-Id: <200308081400.h78E09Xw018129@rtp-core-1.cisco.com> To: Mark Prior cc: Tony Li , Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement (was: Extending BGP) In-reply-to: Your message of Fri, 08 Aug 2003 17:51:28 +0930. <3F335D88.3060708@mrp.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 10:00:09 -0400 Mark> But if the SP doesn't want those services and they are separate Mark> processes then they don't have to turn them on. If they are built into Mark> something else that the SP does want to run then they probably get the Mark> bugs whether they like it or not. What you are really saying is that you want to be able to get an image which has only the features you care about and no others. It seems to me that this is an issue between you and your vendor, and the IETF has nothing to do with it. No vendor would ever decide how to set up the process structure of a particular box based on what the IETF says. And if you have vendor quality issues, don't expect that they will be resolved by IETF discussion. The discussion has revealed a couple of specific areas where certain protocol features of BGP may make it difficult to get the desired level of robustness. It seems that these can be addressed by BGP enhancements like "soft notifications" or "multiple sessions without multiple addresses", things that can be addressed in the IDR WG. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 10:09:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12109 for ; Fri, 8 Aug 2003 10:09:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7vR-0006O8-I9; Fri, 08 Aug 2003 10:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7uW-0006MY-VF for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 10:08:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11952 for ; Fri, 8 Aug 2003 10:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7uU-00011G-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:08:02 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19l7uU-00010r-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:08:02 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78E7Vbp078931; Fri, 8 Aug 2003 10:07:31 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h78E7RLu078923; Fri, 8 Aug 2003 10:07:27 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h78E7Mq07351; Fri, 8 Aug 2003 10:07:22 -0400 (EDT) From: Jeffrey Haas To: Pedro Roque Marques Cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement (was: Extending BGP) Message-ID: <20030808100722.B7223@nexthop.com> References: <200308061440.h76EeYu60088@merlot.juniper.net> <910493458.20030807175927@psg.com> <200308080742.h787gir91485@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200308080742.h787gir91485@roque-bsd.juniper.net>; from roque@juniper.net on Fri, Aug 08, 2003 at 12:42:44AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 10:07:22 -0400 On Fri, Aug 08, 2003 at 12:42:44AM -0700, Pedro Roque Marques wrote: > If that is the goal or one of the goals you are trying to pursue, it > would seem to me that you would have to go through the process of > analyzing what it depends on and gather data as to what causes of > instability. Most service providers keep information of which defects > cause faults in their network, for instance, and many times have > information about their root causes. Seeing pointers to some of these would be good. Pretty much every paper I've seen at NANOG has been roughly along these lines: most failures: hardware outages or telecom outages <20%: operator's twiddling something wrong <3-5%: software/protocol problems We can only address the last one. #include :-) > IMHO, the real issue behind this debate is that services providers are > themselfs internally divided about issues of future direction and > service offerings. Very polite of you to put it this way. :-) > I personally have no idea which faction is correct in terms of > direction given it is essentially a commercial decision based on data > which i don't have access to. IMO, the problem isn't so much whether one faction is more "correct" than the others. The issue is that each party has valid reasons for wanting to do what they want to do. The problem is that the faction that wants changes is the one that is *potentially* destabilizing. Or, to channel Randy and Vijay a little bit, many operators want their networks to work stably and well first and foremost. They are convinced for one reason or another that the software quality is such that it isn't as good as it should be and we should concentrate on fixing bugs rather than adding features. Adding features adds more bugs. Push this one level further up towards IETF, these people are convinced that taking a protocol that has known operational headaches will get new features and add more operational headaches. Address this issue and I think we're good. > But it seems to me that it is a rather poor idea to attempt to settle > it in the IETF precisely because it is a commercial decision. And one > that is particular to each service provider. While we aren't a standards body, we get treated that way by people who test the hardware operators use. If we're broken by design (for some metric of broken), people are going to get cranky for good reason. > Does anyone really intend to suggest to their > marketing department to be really creative and sell the fact that they > don't provide a given service offering ? As the saying goes, "New features sell. Stable code doesn't." > The IETF can and should address engineering problems... in this case > it means make the upmost to make services successful and > deployable. Which is the exact opposite of what the people that don't > "want to see any code changes" are looking for... I think you're seeing Alex state this as an extreme. I don't think this is the case. What I see Alex calling for is all about deployment. How can we deploy new stuff without destabilizing old stuff? > Providing fault isolation in a multi-service router is something that > probably most vendors are working on/have products/have powerpoint. It > is however a problem that doesn't start or end in BGP. As I said in a previous e-mail - all eggs, one basket. > If people want to work on this particular goal i would suggest > starting w/ the requirement lists that have been developed by several > SPs. Some of these are already quite mature by now. The trick is pulling those out of NDA enough to get them published in a sufficiently abstract fashion as to make them happy. > Pedro. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 10:12:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12448 for ; Fri, 8 Aug 2003 10:12:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7yL-0006Zf-Mo; Fri, 08 Aug 2003 10:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7xb-0006XB-SK for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 10:11:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12321 for ; Fri, 8 Aug 2003 10:11:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7xZ-00012Z-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:11:13 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19l7xZ-00012H-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:11:13 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78EAYKm079046; Fri, 8 Aug 2003 10:10:34 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h78EAULu079039; Fri, 8 Aug 2003 10:10:30 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h78EAPA07376; Fri, 8 Aug 2003 10:10:25 -0400 (EDT) From: Jeffrey Haas To: Eric Rosen Cc: Mark Prior , Tony Li , Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement (was: Extending BGP) Message-ID: <20030808101025.C7223@nexthop.com> References: <3F335D88.3060708@mrp.net> <200308081400.h78E09Xw018129@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200308081400.h78E09Xw018129@rtp-core-1.cisco.com>; from erosen@cisco.com on Fri, Aug 08, 2003 at 10:00:09AM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 10:10:25 -0400 On Fri, Aug 08, 2003 at 10:00:09AM -0400, Eric Rosen wrote: > The discussion has revealed a couple of specific areas where certain > protocol features of BGP may make it difficult to get the desired level of > robustness. It seems that these can be addressed by BGP enhancements like > "soft notifications" or "multiple sessions without multiple addresses", > things that can be addressed in the IDR WG. I think this covers the majority of the protocol-level fault tolerance I would like to see. Alex, do you think this should go further? -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 10:15:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12734 for ; Fri, 8 Aug 2003 10:15:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l81F-0006jC-GT; Fri, 08 Aug 2003 10:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l80X-0006if-Pq for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 10:14:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12627 for ; Fri, 8 Aug 2003 10:14:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l80S-00013S-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:14:12 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19l80S-00013K-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:14:12 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 08 Aug 2003 07:18:53 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h78EDdxc018836; Fri, 8 Aug 2003 10:13:39 -0400 (EDT) Message-Id: <200308081413.h78EDdxc018836@rtp-core-2.cisco.com> To: Alex Zinin cc: "John G. Scudder" , routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-reply-to: Your message of Thu, 07 Aug 2003 23:50:45 -0700. <6631570906.20030807235045@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 10:13:39 -0400 Alex> I believe we should be asking ourselves questions whether Alex> belongs in a protocol, and add it only if we believe it does and, as Alex> you say, it is demonstrably harmless. I don't think "belongs in a protocol" is a technical term. I think we can ask whether the distribution requirements of foo are a good match for the protocol, we can ask whether putting foo in the protocol is cost effective when compared to the alternatives, we can ask whether a proposed extension breaks some assumption of the protocol or whether it has some unintended side-effects, etc. Once we've answered all those questions, it doesn't make much sense to then ask "but does it belong?" Alex> the concern is largely about adding non-routing related info on RPs On the issue of fate sharing, the issue is not "routing vs. non-routing", but one address family vs. another. Why are people so quick to accept that it's okay to lose your IPv4 routing if you have IPv6 problems? In BGP, it is possible to further distinguish between address families that require the information to be run through a routing decision process and address families that do not. This is one way of drawing the routing vs. non-routing distinction, and separates out the extensions that are focused on L2VPN from the extensions that really carry address prefixes of one sort or another. To justify adding these sorts of extension to BGP, one has to think of BGP as itself layered into a distribution protocol and a decision process layered above it; these sorts of extensions reuse the distribution protocol but layer different "decision processes" above it. Some technical concerns have been expressed about this, but the "soft notification" and "separate session" ideas seem to address these. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 10:15:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12733 for ; Fri, 8 Aug 2003 10:15:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l81G-0006kD-5j for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 10:15:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78EF2WZ025918 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 10:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l81F-0006jC-GT; Fri, 08 Aug 2003 10:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l80X-0006if-Pq for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 10:14:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12627 for ; Fri, 8 Aug 2003 10:14:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l80S-00013S-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:14:12 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19l80S-00013K-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:14:12 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 08 Aug 2003 07:18:53 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h78EDdxc018836; Fri, 8 Aug 2003 10:13:39 -0400 (EDT) Message-Id: <200308081413.h78EDdxc018836@rtp-core-2.cisco.com> To: Alex Zinin cc: "John G. Scudder" , routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-reply-to: Your message of Thu, 07 Aug 2003 23:50:45 -0700. <6631570906.20030807235045@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 10:13:39 -0400 Alex> I believe we should be asking ourselves questions whether Alex> belongs in a protocol, and add it only if we believe it does and, as Alex> you say, it is demonstrably harmless. I don't think "belongs in a protocol" is a technical term. I think we can ask whether the distribution requirements of foo are a good match for the protocol, we can ask whether putting foo in the protocol is cost effective when compared to the alternatives, we can ask whether a proposed extension breaks some assumption of the protocol or whether it has some unintended side-effects, etc. Once we've answered all those questions, it doesn't make much sense to then ask "but does it belong?" Alex> the concern is largely about adding non-routing related info on RPs On the issue of fate sharing, the issue is not "routing vs. non-routing", but one address family vs. another. Why are people so quick to accept that it's okay to lose your IPv4 routing if you have IPv6 problems? In BGP, it is possible to further distinguish between address families that require the information to be run through a routing decision process and address families that do not. This is one way of drawing the routing vs. non-routing distinction, and separates out the extensions that are focused on L2VPN from the extensions that really carry address prefixes of one sort or another. To justify adding these sorts of extension to BGP, one has to think of BGP as itself layered into a distribution protocol and a decision process layered above it; these sorts of extensions reuse the distribution protocol but layer different "decision processes" above it. Some technical concerns have been expressed about this, but the "soft notification" and "separate session" ideas seem to address these. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 10:36:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13539 for ; Fri, 8 Aug 2003 10:36:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8LZ-0007WU-Pg; Fri, 08 Aug 2003 10:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8Kg-0007Sn-09 for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 10:35:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13496 for ; Fri, 8 Aug 2003 10:34:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8Kd-0001CC-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:35:03 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19l8Kd-0001BZ-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:35:03 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07168; Fri, 8 Aug 2003 10:34:30 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01699; Fri, 8 Aug 2003 10:34:31 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 10:34:30 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55FB6F9D@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Mark Prior'" , Tony Li Cc: Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: RE: a problem statement (was: Extending BGP) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 10:34:28 -0400 -> > Further, if an SP is going to make the commercial -> > decision to support said services, whether or not they -> > are in BGP or some other protocol, they will still be part -> > of whatever implementation, sharing the same processor -> > and memory resources. Just shifting the deck chairs doesn't -> > change the amount of wood on the deck. -> > -> -> But if the SP doesn't want those services and they are separate -> processes then they don't have to turn them on. If they are -> built into -> something else that the SP does want to run then they -> probably get the -> bugs whether they like it or not. Building a robust BGP implementation is nothing to do with "what BGP carries". I would like to share some of the historic events in real complex systems...in mid 90's most of the well known operating systems (Linux and BSDs) became so complex to handle. For that they didn't stop adding stuff in to OS. All they did is, modularized the kernels to dynamically load/ unload modules as and when needed. Neither they chose to go for micro kernel architectures nor they re-invented the wheel. AFAIK, every vendor's protocols implementations have a life cycle (accept the truth)...for protocols like BGP the life cycle of an implementation may be less. Because the rate of change may be more for BGP. Every vendor has to re-design their code to enhance the performance. This is nothing to do with changing the BGP protocol spec. More over this is nothing to do with IETF. If service providers think that a particular vendors' BGP implementation became so complex, ask them to re-design their implementation. Or go to different vendor, who is better at that time. The better solution for this (IMHO) is to take the problems case by case basis and evaluate: 1. What is getting overloaded (implementations/design) ? 1. Why *this particular extension* fits (won't) into BGP ? 2. If *this is not the best fit into foo* (after discussion in apt list) then ask, did we accumulate enough such cases to fork another new protocol ? Again, IMHO, the evaluation of a protocol must not be based on current available limitations in the systems engineering. Given a chance, one can really modularize any complex protocol...can do SMP of these modules over different processors... can fork multiple threads/processes...can improve the performance drastically regardless of how many extensions we do. To be frank, BGP is not at all complex when compared to other complex systems. BGP may look complex if we compare it with ping. Venkata. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 10:42:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10786 for ; Fri, 8 Aug 2003 09:55:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7hu-0005HS-IM; Fri, 08 Aug 2003 09:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7hE-0005G8-OT for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 09:54:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10756 for ; Fri, 8 Aug 2003 09:54:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7hC-0000nG-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 09:54:18 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19l7hB-0000mB-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 09:54:18 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78Drdr4078512; Fri, 8 Aug 2003 09:53:39 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h78DrYLu078500; Fri, 8 Aug 2003 09:53:35 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h78DrTn07308; Fri, 8 Aug 2003 09:53:29 -0400 (EDT) From: Jeffrey Haas To: Alex Zinin Cc: "John G. Scudder" , routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: <20030808095329.A7223@nexthop.com> References: <200308061400.h76E0eu58144@merlot.juniper.net> <15211650582.20030807181844@psg.com> <6631570906.20030807235045@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6631570906.20030807235045@psg.com>; from zinin@psg.com on Thu, Aug 07, 2003 at 11:50:45PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 09:53:29 -0400 [reordering] On Thu, Aug 07, 2003 at 11:50:45PM -0700, Alex Zinin wrote: > I believe we should be asking ourselves questions whether > belongs in a protocol, and add it only if we believe it does and, as > you say, it is demonstrably harmless. There's "harmless" and "harmless". The more state you need to keep and transmit, the more copies of something BGP is going to get. If is suitable to be modified on a hop-by-hop basis then it is posibly suitable to be put into BGP. However, putting more and more in means that the routers have more to transmit, keep state on, do path calculations for, etc. The fact that we have this grand knob for AFI/SAFI's means that so long as we don't put stuff in that makes things *mandatory* for the protocol to scale, we can put stuff in the protocol and let the network operators decide how far their dollars will go in putting enough hardware in place to handle it. VPLS made me think for a bit since many cases seem to be more suited to a flooding-style protocol. The key that Pedro gave me to grok why BGP makes more sense is the fact that *policy* is applied. If we had something that did policy on flooded information, it might make more sense to not use BGP. Unfortunately, then we have to deal with the inter-domain case. Similar "harmless" issues haunt IGP's. If you stick something into the LSDB, it's going to take up memory whether you use it or not. Since the database calculation is distributed rather than by rumor, this means that you simply need one box in an important spot to get too much information, run out of memory and crash and your network is very unhappy. While this isn't quite as bad as flooding your BGP into your OSPF, it can be a close second. [...] > Let's first make sure we don't interpret Jeff's words differently. > > What I meant is that not breaking while extending may be read as > "without really thinking much _what_ extensions we put in, let's > ensure we don't break the thing". While this is necessary, I don't > think it's enough. "He who breaks a thing to understand what it is, has left the paths of wisdom." :-) -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 10:57:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12108 for ; Fri, 8 Aug 2003 10:09:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7vU-0006P2-2X for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 10:09:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78E94pj024606 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 10:09:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7vR-0006O8-I9; Fri, 08 Aug 2003 10:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7uW-0006MY-VF for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 10:08:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11952 for ; Fri, 8 Aug 2003 10:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7uU-00011G-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:08:02 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19l7uU-00010r-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:08:02 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78E7Vbp078931; Fri, 8 Aug 2003 10:07:31 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h78E7RLu078923; Fri, 8 Aug 2003 10:07:27 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h78E7Mq07351; Fri, 8 Aug 2003 10:07:22 -0400 (EDT) From: Jeffrey Haas To: Pedro Roque Marques Cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement (was: Extending BGP) Message-ID: <20030808100722.B7223@nexthop.com> References: <200308061440.h76EeYu60088@merlot.juniper.net> <910493458.20030807175927@psg.com> <200308080742.h787gir91485@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200308080742.h787gir91485@roque-bsd.juniper.net>; from roque@juniper.net on Fri, Aug 08, 2003 at 12:42:44AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 10:07:22 -0400 On Fri, Aug 08, 2003 at 12:42:44AM -0700, Pedro Roque Marques wrote: > If that is the goal or one of the goals you are trying to pursue, it > would seem to me that you would have to go through the process of > analyzing what it depends on and gather data as to what causes of > instability. Most service providers keep information of which defects > cause faults in their network, for instance, and many times have > information about their root causes. Seeing pointers to some of these would be good. Pretty much every paper I've seen at NANOG has been roughly along these lines: most failures: hardware outages or telecom outages <20%: operator's twiddling something wrong <3-5%: software/protocol problems We can only address the last one. #include :-) > IMHO, the real issue behind this debate is that services providers are > themselfs internally divided about issues of future direction and > service offerings. Very polite of you to put it this way. :-) > I personally have no idea which faction is correct in terms of > direction given it is essentially a commercial decision based on data > which i don't have access to. IMO, the problem isn't so much whether one faction is more "correct" than the others. The issue is that each party has valid reasons for wanting to do what they want to do. The problem is that the faction that wants changes is the one that is *potentially* destabilizing. Or, to channel Randy and Vijay a little bit, many operators want their networks to work stably and well first and foremost. They are convinced for one reason or another that the software quality is such that it isn't as good as it should be and we should concentrate on fixing bugs rather than adding features. Adding features adds more bugs. Push this one level further up towards IETF, these people are convinced that taking a protocol that has known operational headaches will get new features and add more operational headaches. Address this issue and I think we're good. > But it seems to me that it is a rather poor idea to attempt to settle > it in the IETF precisely because it is a commercial decision. And one > that is particular to each service provider. While we aren't a standards body, we get treated that way by people who test the hardware operators use. If we're broken by design (for some metric of broken), people are going to get cranky for good reason. > Does anyone really intend to suggest to their > marketing department to be really creative and sell the fact that they > don't provide a given service offering ? As the saying goes, "New features sell. Stable code doesn't." > The IETF can and should address engineering problems... in this case > it means make the upmost to make services successful and > deployable. Which is the exact opposite of what the people that don't > "want to see any code changes" are looking for... I think you're seeing Alex state this as an extreme. I don't think this is the case. What I see Alex calling for is all about deployment. How can we deploy new stuff without destabilizing old stuff? > Providing fault isolation in a multi-service router is something that > probably most vendors are working on/have products/have powerpoint. It > is however a problem that doesn't start or end in BGP. As I said in a previous e-mail - all eggs, one basket. > If people want to work on this particular goal i would suggest > starting w/ the requirement lists that have been developed by several > SPs. Some of these are already quite mature by now. The trick is pulling those out of NDA enough to get them published in a sufficiently abstract fashion as to make them happy. > Pedro. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 11:02:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12449 for ; Fri, 8 Aug 2003 10:12:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7yN-0006at-Qx for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 10:12:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78EC3c1025330 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 10:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7yL-0006Zf-Mo; Fri, 08 Aug 2003 10:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7xb-0006XB-SK for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 10:11:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12321 for ; Fri, 8 Aug 2003 10:11:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7xZ-00012Z-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:11:13 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19l7xZ-00012H-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:11:13 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78EAYKm079046; Fri, 8 Aug 2003 10:10:34 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h78EAULu079039; Fri, 8 Aug 2003 10:10:30 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h78EAPA07376; Fri, 8 Aug 2003 10:10:25 -0400 (EDT) From: Jeffrey Haas To: Eric Rosen Cc: Mark Prior , Tony Li , Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement (was: Extending BGP) Message-ID: <20030808101025.C7223@nexthop.com> References: <3F335D88.3060708@mrp.net> <200308081400.h78E09Xw018129@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200308081400.h78E09Xw018129@rtp-core-1.cisco.com>; from erosen@cisco.com on Fri, Aug 08, 2003 at 10:00:09AM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 10:10:25 -0400 On Fri, Aug 08, 2003 at 10:00:09AM -0400, Eric Rosen wrote: > The discussion has revealed a couple of specific areas where certain > protocol features of BGP may make it difficult to get the desired level of > robustness. It seems that these can be addressed by BGP enhancements like > "soft notifications" or "multiple sessions without multiple addresses", > things that can be addressed in the IDR WG. I think this covers the majority of the protocol-level fault tolerance I would like to see. Alex, do you think this should go further? -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 11:19:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14769 for ; Fri, 8 Aug 2003 11:19:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l91B-0001G9-I2; Fri, 08 Aug 2003 11:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l90f-0001Fq-PM for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 11:18:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14752 for ; Fri, 8 Aug 2003 11:18:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l90e-0001RD-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 11:18:28 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 19l90e-0001R9-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 11:18:28 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 28BF44F3D5; Fri, 8 Aug 2003 11:18:13 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16179.48948.362655.692239@durmstrang.padfoot.com> From: Henry Kilmer To: Subject: RE: a problem statement (was: Extending BGP) In-Reply-To: References: X-Mailer: VM 7.14 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 11:18:12 -0400 Content-Transfer-Encoding: 7bit Tony Li writes: > > >Well said, here here!!! > >Further, if an SP is going to make the commercial >decision to support said services, whether or not they >are in BGP or some other protocol, they will still be part >of whatever implementation, sharing the same processor >and memory resources. Just shifting the deck chairs doesn't >change the amount of wood on the deck. One of the concerns I have is the ability to selectively run "new" things. In the past, I have even gone so far as to install extra routers within pops and only turned on new features in them (sometimes using a suite of tunnels to get things working) leaving my core infrastructure alone. This allowed me to test new features, protocols, enhancements and services without jeopardizing the infrastructure carrying live traffic. One network I ran even kept this seperate structure for the service offering for awhile. Every provider that I have worked for prioritized existing IPv4 customers over new products. So even with competing pressures within ISPs (they *need* to generate revenue an commonly use new products to do so), the infrastructure still needs to be the top priority. This sort of rollout can be done within BGP or with a different distribution protocol. The point is the concern for the infrastructures integrity and not necessarily the mechanism. But I would also say that it does not *necessarily* mean they share the same processor and memory resources. Nor do they have to share code. One of the points I thought I heard in this conversation was a concern over the existing BGP stability in the Internet. It has also been pointed out that BGP as a protocol is simple and should not have issues. Randy mentioned stats and a presentation he was working on talking about concerns with existing BGP implementations. Would it not be prudent to get more details on this before extending one of the critical elements of making the infrastructure work? Or do we feel that we have enough from the work Craig did a few years ago? I personally would like to hear more about the issues and concerns before adding more to the protocol. -Hank _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 11:22:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13541 for ; Fri, 8 Aug 2003 10:36:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8Lf-0007XK-Dn for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 10:36:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Ea7R6028968 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 10:36:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8LZ-0007WU-Pg; Fri, 08 Aug 2003 10:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8Kg-0007Sn-09 for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 10:35:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13496 for ; Fri, 8 Aug 2003 10:34:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8Kd-0001CC-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:35:03 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19l8Kd-0001BZ-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 10:35:03 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07168; Fri, 8 Aug 2003 10:34:30 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01699; Fri, 8 Aug 2003 10:34:31 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 10:34:30 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55FB6F9D@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Mark Prior'" , Tony Li Cc: Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: RE: a problem statement (was: Extending BGP) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 10:34:28 -0400 -> > Further, if an SP is going to make the commercial -> > decision to support said services, whether or not they -> > are in BGP or some other protocol, they will still be part -> > of whatever implementation, sharing the same processor -> > and memory resources. Just shifting the deck chairs doesn't -> > change the amount of wood on the deck. -> > -> -> But if the SP doesn't want those services and they are separate -> processes then they don't have to turn them on. If they are -> built into -> something else that the SP does want to run then they -> probably get the -> bugs whether they like it or not. Building a robust BGP implementation is nothing to do with "what BGP carries". I would like to share some of the historic events in real complex systems...in mid 90's most of the well known operating systems (Linux and BSDs) became so complex to handle. For that they didn't stop adding stuff in to OS. All they did is, modularized the kernels to dynamically load/ unload modules as and when needed. Neither they chose to go for micro kernel architectures nor they re-invented the wheel. AFAIK, every vendor's protocols implementations have a life cycle (accept the truth)...for protocols like BGP the life cycle of an implementation may be less. Because the rate of change may be more for BGP. Every vendor has to re-design their code to enhance the performance. This is nothing to do with changing the BGP protocol spec. More over this is nothing to do with IETF. If service providers think that a particular vendors' BGP implementation became so complex, ask them to re-design their implementation. Or go to different vendor, who is better at that time. The better solution for this (IMHO) is to take the problems case by case basis and evaluate: 1. What is getting overloaded (implementations/design) ? 1. Why *this particular extension* fits (won't) into BGP ? 2. If *this is not the best fit into foo* (after discussion in apt list) then ask, did we accumulate enough such cases to fork another new protocol ? Again, IMHO, the evaluation of a protocol must not be based on current available limitations in the systems engineering. Given a chance, one can really modularize any complex protocol...can do SMP of these modules over different processors... can fork multiple threads/processes...can improve the performance drastically regardless of how many extensions we do. To be frank, BGP is not at all complex when compared to other complex systems. BGP may look complex if we compare it with ping. Venkata. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 11:26:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15035 for ; Fri, 8 Aug 2003 11:26:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l97x-0001aB-1u; Fri, 08 Aug 2003 11:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l97C-0001Zf-1d for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 11:25:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15008 for ; Fri, 8 Aug 2003 11:25:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l97B-0001UY-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 11:25:13 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19l97A-0001U3-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 11:25:12 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78FOfiQ081158; Fri, 8 Aug 2003 11:24:41 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h78FObLu081151; Fri, 8 Aug 2003 11:24:37 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h78FOVa08573; Fri, 8 Aug 2003 11:24:31 -0400 (EDT) From: Jeffrey Haas To: George Sheng Cc: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: <20030808112431.D7223@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from george_s97@hotmail.com on Fri, Aug 08, 2003 at 05:27:52AM +0000 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 11:24:31 -0400 On Fri, Aug 08, 2003 at 05:27:52AM +0000, George Sheng wrote: > If an Interface bounces, it will cause IGP adjacency > bounce/unstable, which in turn will cause BGP unstable. Which triggers WRD when it is on. Of course, it triggers WRD because the minroute timers are usually not implemented or have had their values turned down. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 11:26:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15039 for ; Fri, 8 Aug 2003 11:26:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l97x-0001ba-Pq for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 11:26:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78FQ1Nd006133 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 11:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l97x-0001aB-1u; Fri, 08 Aug 2003 11:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l97C-0001Zf-1d for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 11:25:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15008 for ; Fri, 8 Aug 2003 11:25:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l97B-0001UY-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 11:25:13 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19l97A-0001U3-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 11:25:12 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78FOfiQ081158; Fri, 8 Aug 2003 11:24:41 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h78FObLu081151; Fri, 8 Aug 2003 11:24:37 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h78FOVa08573; Fri, 8 Aug 2003 11:24:31 -0400 (EDT) From: Jeffrey Haas To: George Sheng Cc: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Message-ID: <20030808112431.D7223@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from george_s97@hotmail.com on Fri, Aug 08, 2003 at 05:27:52AM +0000 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 11:24:31 -0400 On Fri, Aug 08, 2003 at 05:27:52AM +0000, George Sheng wrote: > If an Interface bounces, it will cause IGP adjacency > bounce/unstable, which in turn will cause BGP unstable. Which triggers WRD when it is on. Of course, it triggers WRD because the minroute timers are usually not implemented or have had their values turned down. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 12:07:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14768 for ; Fri, 8 Aug 2003 11:19:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l91M-0001Iw-EY for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 11:19:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78FJCAL005010 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 11:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l91B-0001G9-I2; Fri, 08 Aug 2003 11:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l90f-0001Fq-PM for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 11:18:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14752 for ; Fri, 8 Aug 2003 11:18:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l90e-0001RD-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 11:18:28 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 19l90e-0001R9-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 11:18:28 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 28BF44F3D5; Fri, 8 Aug 2003 11:18:13 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16179.48948.362655.692239@durmstrang.padfoot.com> From: Henry Kilmer To: Subject: RE: a problem statement (was: Extending BGP) In-Reply-To: References: X-Mailer: VM 7.14 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 11:18:12 -0400 Content-Transfer-Encoding: 7bit Tony Li writes: > > >Well said, here here!!! > >Further, if an SP is going to make the commercial >decision to support said services, whether or not they >are in BGP or some other protocol, they will still be part >of whatever implementation, sharing the same processor >and memory resources. Just shifting the deck chairs doesn't >change the amount of wood on the deck. One of the concerns I have is the ability to selectively run "new" things. In the past, I have even gone so far as to install extra routers within pops and only turned on new features in them (sometimes using a suite of tunnels to get things working) leaving my core infrastructure alone. This allowed me to test new features, protocols, enhancements and services without jeopardizing the infrastructure carrying live traffic. One network I ran even kept this seperate structure for the service offering for awhile. Every provider that I have worked for prioritized existing IPv4 customers over new products. So even with competing pressures within ISPs (they *need* to generate revenue an commonly use new products to do so), the infrastructure still needs to be the top priority. This sort of rollout can be done within BGP or with a different distribution protocol. The point is the concern for the infrastructures integrity and not necessarily the mechanism. But I would also say that it does not *necessarily* mean they share the same processor and memory resources. Nor do they have to share code. One of the points I thought I heard in this conversation was a concern over the existing BGP stability in the Internet. It has also been pointed out that BGP as a protocol is simple and should not have issues. Randy mentioned stats and a presentation he was working on talking about concerns with existing BGP implementations. Would it not be prudent to get more details on this before extending one of the critical elements of making the infrastructure work? Or do we feel that we have enough from the work Craig did a few years ago? I personally would like to hear more about the issues and concerns before adding more to the protocol. -Hank _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 16:46:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25396 for ; Fri, 8 Aug 2003 16:46:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lE6f-0007LX-MC; Fri, 08 Aug 2003 16:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lE5t-0007Ky-0p for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 16:44:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25350 for ; Fri, 8 Aug 2003 16:44:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lE5m-0003zG-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 16:44:06 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19lE5l-0003yq-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 16:44:05 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 8A460344B1; Fri, 8 Aug 2003 13:44:25 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h78KhRYB008190; Fri, 8 Aug 2003 13:43:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: a problem statement (was: Extending BGP) Message-ID: Thread-Topic: a problem statement (was: Extending BGP) Thread-Index: AcNdhh+VhZLHE199StC0D+RlMI+/qQAZ3hqg From: "Tony Li" To: "Mark Prior" Cc: "Pedro Roque Marques" , "Alex Zinin" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 13:43:27 -0700 Content-Transfer-Encoding: quoted-printable | > Well said, here here!!! | >=20 | > Further, if an SP is going to make the commercial=20 | > decision to support said services, whether or not they | > are in BGP or some other protocol, they will still be part | > of whatever implementation, sharing the same processor | > and memory resources. Just shifting the deck chairs doesn't | > change the amount of wood on the deck. | >=20 | =20 | But if the SP doesn't want those services and they are separate=20 | processes then they don't have to turn them on. If they=20 | are built into=20 | something else that the SP does want to run then they=20 | probably get the=20 | bugs whether they like it or not. If the SP doesn't want a service, then the SP shouldn't turn it on. If the SP didn't turn it on, then the code happily sits behind an 'if' statement, never to be executed. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 16:46:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25412 for ; Fri, 8 Aug 2003 16:46:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lE7i-0007N5-6J for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 16:46:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Kk6Db028326 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 16:46:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lE6f-0007LX-MC; Fri, 08 Aug 2003 16:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lE5t-0007Ky-0p for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 16:44:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25350 for ; Fri, 8 Aug 2003 16:44:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lE5m-0003zG-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 16:44:06 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19lE5l-0003yq-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 16:44:05 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 8A460344B1; Fri, 8 Aug 2003 13:44:25 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h78KhRYB008190; Fri, 8 Aug 2003 13:43:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: a problem statement (was: Extending BGP) Message-ID: Thread-Topic: a problem statement (was: Extending BGP) Thread-Index: AcNdhh+VhZLHE199StC0D+RlMI+/qQAZ3hqg From: "Tony Li" To: "Mark Prior" Cc: "Pedro Roque Marques" , "Alex Zinin" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 13:43:27 -0700 Content-Transfer-Encoding: quoted-printable | > Well said, here here!!! | >=20 | > Further, if an SP is going to make the commercial=20 | > decision to support said services, whether or not they | > are in BGP or some other protocol, they will still be part | > of whatever implementation, sharing the same processor | > and memory resources. Just shifting the deck chairs doesn't | > change the amount of wood on the deck. | >=20 | =20 | But if the SP doesn't want those services and they are separate=20 | processes then they don't have to turn them on. If they=20 | are built into=20 | something else that the SP does want to run then they=20 | probably get the=20 | bugs whether they like it or not. If the SP doesn't want a service, then the SP shouldn't turn it on. If the SP didn't turn it on, then the code happily sits behind an 'if' statement, never to be executed. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 17:12:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26351 for ; Fri, 8 Aug 2003 17:12:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEWn-0000TH-6z; Fri, 08 Aug 2003 17:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEWN-0000T3-4t for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 17:11:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26259 for ; Fri, 8 Aug 2003 17:11:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEWK-0004En-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:11:33 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19lEWK-0004EF-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:11:32 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78LB2FK092886; Fri, 8 Aug 2003 17:11:02 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h78LAvLu092879; Fri, 8 Aug 2003 17:10:58 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h78LAqG21272; Fri, 8 Aug 2003 17:10:52 -0400 (EDT) From: Jeffrey Haas To: Tony Li Cc: Mark Prior , Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement (was: Extending BGP) Message-ID: <20030808171052.K7223@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Fri, Aug 08, 2003 at 01:43:27PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 17:10:52 -0400 On Fri, Aug 08, 2003 at 01:43:27PM -0700, Tony Li wrote: > If the SP doesn't want a service, then the SP shouldn't turn it on. > If the SP didn't turn it on, then the code happily sits behind > an 'if' statement, never to be executed. Yet other stuff is still present in the path that wouldn't be there if the feature wasn't in the code base at all, even if we extend your analogy to #ifdef. But we are on the wrong path. Next! :-) > Tony -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 17:19:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26515 for ; Fri, 8 Aug 2003 17:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEdZ-0000hC-Dq; Fri, 08 Aug 2003 17:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEd2-0000gs-DW for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 17:18:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26505 for ; Fri, 8 Aug 2003 17:18:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEcv-0004Iz-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:18:21 -0400 Received: from [131.227.76.5] (helo=prue.eim.surrey.ac.uk ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19lEcv-0004Iv-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:18:21 -0400 Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19lEcD-0000WY-00; Fri, 08 Aug 2003 22:17:37 +0100 Date: Fri, 8 Aug 2003 22:17:35 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: Tony Li cc: Mark Prior , Pedro Roque Marques , Alex Zinin , "" Subject: RE: a problem statement (was: Extending BGP) In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.3 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE,USER_IN_WHITELIST version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19lEcD-0000WY-00*DIhCu8BKHuM* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Fri, 8 Aug 2003, Tony Li wrote: > If the SP doesn't want a service, then the SP shouldn't ...have to pay for it. L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 17:43:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27265 for ; Fri, 8 Aug 2003 17:43:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lF0n-0001kp-RR; Fri, 08 Aug 2003 17:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lF0B-0001kP-4A for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 17:42:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27197 for ; Fri, 8 Aug 2003 17:42:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lF08-0004Rx-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:42:20 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19lF07-0004Rf-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:42:20 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19494; Fri, 8 Aug 2003 17:41:44 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA22378; Fri, 8 Aug 2003 17:41:45 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 17:41:45 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55FB6FA1@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Jeffrey Haas'" , Tony Li Cc: Mark Prior , Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: RE: a problem statement (was: Extending BGP) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 17:41:42 -0400 -> On Fri, Aug 08, 2003 at 01:43:27PM -0700, Tony Li wrote: -> > If the SP doesn't want a service, then the SP shouldn't turn it on. -> > If the SP didn't turn it on, then the code happily sits behind -> > an 'if' statement, never to be executed. -> -> Yet other stuff is still present in the path that wouldn't be there -> if the feature wasn't in the code base at all, even if we -> extend your analogy to #ifdef. -> -> But we are on the wrong path. Next! :-) Ask for dynamically loadable modularized BGP implementation. Why do we always think that "complete BGP" with all (unnecessary) extensions is compiled and loaded into memory even if 75% of code never executes. Ask your vendor to do code profiling and request for better implementation. That will solve the above problem(s). Conditional compilation is not the only solution for the problem. :) Venkata. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 17:43:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27267 for ; Fri, 8 Aug 2003 17:43:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lF0v-0001m5-Nc for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 17:43:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Lh9rR006799 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 17:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lF0n-0001kp-RR; Fri, 08 Aug 2003 17:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lF0B-0001kP-4A for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 17:42:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27197 for ; Fri, 8 Aug 2003 17:42:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lF08-0004Rx-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:42:20 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19lF07-0004Rf-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:42:20 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19494; Fri, 8 Aug 2003 17:41:44 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA22378; Fri, 8 Aug 2003 17:41:45 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 17:41:45 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55FB6FA1@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Jeffrey Haas'" , Tony Li Cc: Mark Prior , Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: RE: a problem statement (was: Extending BGP) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 17:41:42 -0400 -> On Fri, Aug 08, 2003 at 01:43:27PM -0700, Tony Li wrote: -> > If the SP doesn't want a service, then the SP shouldn't turn it on. -> > If the SP didn't turn it on, then the code happily sits behind -> > an 'if' statement, never to be executed. -> -> Yet other stuff is still present in the path that wouldn't be there -> if the feature wasn't in the code base at all, even if we -> extend your analogy to #ifdef. -> -> But we are on the wrong path. Next! :-) Ask for dynamically loadable modularized BGP implementation. Why do we always think that "complete BGP" with all (unnecessary) extensions is compiled and loaded into memory even if 75% of code never executes. Ask your vendor to do code profiling and request for better implementation. That will solve the above problem(s). Conditional compilation is not the only solution for the problem. :) Venkata. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 18:07:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26517 for ; Fri, 8 Aug 2003 17:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEdb-0000iM-Av for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 17:19:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78LJ393002725 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 17:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEdZ-0000hC-Dq; Fri, 08 Aug 2003 17:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEd2-0000gs-DW for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 17:18:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26505 for ; Fri, 8 Aug 2003 17:18:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEcv-0004Iz-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:18:21 -0400 Received: from [131.227.76.5] (helo=prue.eim.surrey.ac.uk ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19lEcv-0004Iv-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:18:21 -0400 Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19lEcD-0000WY-00; Fri, 08 Aug 2003 22:17:37 +0100 Date: Fri, 8 Aug 2003 22:17:35 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: Tony Li cc: Mark Prior , Pedro Roque Marques , Alex Zinin , "" Subject: RE: a problem statement (was: Extending BGP) In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.3 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE,USER_IN_WHITELIST version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19lEcD-0000WY-00*DIhCu8BKHuM* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Fri, 8 Aug 2003, Tony Li wrote: > If the SP doesn't want a service, then the SP shouldn't ...have to pay for it. L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 18:07:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26352 for ; Fri, 8 Aug 2003 17:12:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEWu-0000UP-BK for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 17:12:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78LC8ZG001861 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 17:12:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEWn-0000TH-6z; Fri, 08 Aug 2003 17:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lEWN-0000T3-4t for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 17:11:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26259 for ; Fri, 8 Aug 2003 17:11:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lEWK-0004En-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:11:33 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19lEWK-0004EF-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 17:11:32 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h78LB2FK092886; Fri, 8 Aug 2003 17:11:02 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h78LAvLu092879; Fri, 8 Aug 2003 17:10:58 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h78LAqG21272; Fri, 8 Aug 2003 17:10:52 -0400 (EDT) From: Jeffrey Haas To: Tony Li Cc: Mark Prior , Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement (was: Extending BGP) Message-ID: <20030808171052.K7223@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Fri, Aug 08, 2003 at 01:43:27PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 17:10:52 -0400 On Fri, Aug 08, 2003 at 01:43:27PM -0700, Tony Li wrote: > If the SP doesn't want a service, then the SP shouldn't turn it on. > If the SP didn't turn it on, then the code happily sits behind > an 'if' statement, never to be executed. Yet other stuff is still present in the path that wouldn't be there if the feature wasn't in the code base at all, even if we extend your analogy to #ifdef. But we are on the wrong path. Next! :-) > Tony -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Aug 8 19:04:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00129 for ; Fri, 8 Aug 2003 19:04:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lGHA-0004tn-Li; Fri, 08 Aug 2003 19:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lGGs-0004tK-Cb for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 19:03:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00110 for ; Fri, 8 Aug 2003 19:03:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lGGp-0004rn-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 19:03:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19lGGo-0004rk-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 19:03:38 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19lGGi-000Nqo-DD; Fri, 08 Aug 2003 23:03:32 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14789924945.20030808160319@psg.com> To: Jeffrey Haas CC: Eric Rosen , Mark Prior , Tony Li , Pedro Roque Marques , Subject: Re: a problem statement (was: Extending BGP) In-Reply-To: <20030808101025.C7223@nexthop.com> References: <3F335D88.3060708@mrp.net> <200308081400.h78E09Xw018129@rtp-core-1.cisco.com> <20030808101025.C7223@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 16:03:19 -0700 Content-Transfer-Encoding: 7bit Jeff- Yes. This, I thinks, maps to step 3 "meanwhile considerations" in the message about next steps I sent on Aug 1st. I will be creating the design teams I mentioned, including the one to work on documenting this part of the discussion. The document would then be discussed here and taken to IDR for further actions. More details later on the list. -- Alex http://www.psg.com/~zinin/ Friday, August 8, 2003, 7:10:25 AM, Jeffrey Haas wrote: > On Fri, Aug 08, 2003 at 10:00:09AM -0400, Eric Rosen wrote: >> The discussion has revealed a couple of specific areas where certain >> protocol features of BGP may make it difficult to get the desired level of >> robustness. It seems that these can be addressed by BGP enhancements like >> "soft notifications" or "multiple sessions without multiple addresses", >> things that can be addressed in the IDR WG. > I think this covers the majority of the protocol-level fault tolerance > I would like to see. > Alex, do you think this should go further? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Aug 8 19:04:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00131 for ; Fri, 8 Aug 2003 19:04:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lGHJ-0004up-R2 for routing-discussion-archive@odin.ietf.org; Fri, 08 Aug 2003 19:04:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78N49ZX018881 for routing-discussion-archive@odin.ietf.org; Fri, 8 Aug 2003 19:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lGHA-0004tn-Li; Fri, 08 Aug 2003 19:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lGGs-0004tK-Cb for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 19:03:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00110 for ; Fri, 8 Aug 2003 19:03:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lGGp-0004rn-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 19:03:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19lGGo-0004rk-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 19:03:38 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19lGGi-000Nqo-DD; Fri, 08 Aug 2003 23:03:32 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14789924945.20030808160319@psg.com> To: Jeffrey Haas CC: Eric Rosen , Mark Prior , Tony Li , Pedro Roque Marques , Subject: Re: a problem statement (was: Extending BGP) In-Reply-To: <20030808101025.C7223@nexthop.com> References: <3F335D88.3060708@mrp.net> <200308081400.h78E09Xw018129@rtp-core-1.cisco.com> <20030808101025.C7223@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 8 Aug 2003 16:03:19 -0700 Content-Transfer-Encoding: 7bit Jeff- Yes. This, I thinks, maps to step 3 "meanwhile considerations" in the message about next steps I sent on Aug 1st. I will be creating the design teams I mentioned, including the one to work on documenting this part of the discussion. The document would then be discussed here and taken to IDR for further actions. More details later on the list. -- Alex http://www.psg.com/~zinin/ Friday, August 8, 2003, 7:10:25 AM, Jeffrey Haas wrote: > On Fri, Aug 08, 2003 at 10:00:09AM -0400, Eric Rosen wrote: >> The discussion has revealed a couple of specific areas where certain >> protocol features of BGP may make it difficult to get the desired level of >> robustness. It seems that these can be addressed by BGP enhancements like >> "soft notifications" or "multiple sessions without multiple addresses", >> things that can be addressed in the IDR WG. > I think this covers the majority of the protocol-level fault tolerance > I would like to see. > Alex, do you think this should go further? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Aug 9 08:43:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27103 for ; Sat, 9 Aug 2003 08:43:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lT3k-0005r5-Qf; Sat, 09 Aug 2003 08:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lT2x-0005qg-AY for routing-discussion@optimus.ietf.org; Sat, 09 Aug 2003 08:42:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27093 for ; Sat, 9 Aug 2003 08:42:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lT2v-00010T-00 for routing-discussion@ietf.org; Sat, 09 Aug 2003 08:42:09 -0400 Received: from cpe-144-137-208-24.sa.bigpond.net.au ([144.137.208.24] helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19lT2u-00010Q-00 for routing-discussion@ietf.org; Sat, 09 Aug 2003 08:42:08 -0400 Received: from mrp.net (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h79CevB8001355; Sat, 9 Aug 2003 22:11:13 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F34EBD9.2050609@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: erosen@cisco.com CC: Tony Li , Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement References: <200308081400.h78E09Xw018129@rtp-core-1.cisco.com> In-Reply-To: <200308081400.h78E09Xw018129@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 09 Aug 2003 22:10:57 +0930 Content-Transfer-Encoding: 7bit Eric Rosen wrote: > Mark> But if the SP doesn't want those services and they are separate > Mark> processes then they don't have to turn them on. If they are built into > Mark> something else that the SP does want to run then they probably get the > Mark> bugs whether they like it or not. > > What you are really saying is that you want to be able to get an image which > has only the features you care about and no others. It seems to me that > this is an issue between you and your vendor, and the IETF has nothing to do > with it. No vendor would ever decide how to set up the process structure of > a particular box based on what the IETF says. And if you have vendor > quality issues, don't expect that they will be resolved by IETF discussion. > I don't care if the features are there or not, although my obvious preference would be for them not to be there (that is why I don't run cisco enterprise images or T images for that matter), but I do care if their presence impacts the robustness of the features I am using. While this could be claimed to be a vendor implementation problem if the IETF stops adding unrelated items to BGP just because its there and does sort of the same thing then the vendors will be less likely to add them too. After all marketing are probably only interested in having the longest "supports RFC xxxx" list in their propaganda. Mark. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Sat Aug 9 08:43:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27110 for ; Sat, 9 Aug 2003 08:43:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lT3u-0005tn-Oj for routing-discussion-archive@odin.ietf.org; Sat, 09 Aug 2003 08:43:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h79ChA0J022671 for routing-discussion-archive@odin.ietf.org; Sat, 9 Aug 2003 08:43:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lT3k-0005r5-Qf; Sat, 09 Aug 2003 08:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lT2x-0005qg-AY for routing-discussion@optimus.ietf.org; Sat, 09 Aug 2003 08:42:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27093 for ; Sat, 9 Aug 2003 08:42:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lT2v-00010T-00 for routing-discussion@ietf.org; Sat, 09 Aug 2003 08:42:09 -0400 Received: from cpe-144-137-208-24.sa.bigpond.net.au ([144.137.208.24] helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19lT2u-00010Q-00 for routing-discussion@ietf.org; Sat, 09 Aug 2003 08:42:08 -0400 Received: from mrp.net (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h79CevB8001355; Sat, 9 Aug 2003 22:11:13 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F34EBD9.2050609@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: erosen@cisco.com CC: Tony Li , Pedro Roque Marques , Alex Zinin , routing-discussion@ietf.org Subject: Re: a problem statement References: <200308081400.h78E09Xw018129@rtp-core-1.cisco.com> In-Reply-To: <200308081400.h78E09Xw018129@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 09 Aug 2003 22:10:57 +0930 Content-Transfer-Encoding: 7bit Eric Rosen wrote: > Mark> But if the SP doesn't want those services and they are separate > Mark> processes then they don't have to turn them on. If they are built into > Mark> something else that the SP does want to run then they probably get the > Mark> bugs whether they like it or not. > > What you are really saying is that you want to be able to get an image which > has only the features you care about and no others. It seems to me that > this is an issue between you and your vendor, and the IETF has nothing to do > with it. No vendor would ever decide how to set up the process structure of > a particular box based on what the IETF says. And if you have vendor > quality issues, don't expect that they will be resolved by IETF discussion. > I don't care if the features are there or not, although my obvious preference would be for them not to be there (that is why I don't run cisco enterprise images or T images for that matter), but I do care if their presence impacts the robustness of the features I am using. While this could be claimed to be a vendor implementation problem if the IETF stops adding unrelated items to BGP just because its there and does sort of the same thing then the vendors will be less likely to add them too. After all marketing are probably only interested in having the longest "supports RFC xxxx" list in their propaganda. Mark. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Aug 11 10:23:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17959 for ; Mon, 11 Aug 2003 10:23:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDZd-00053z-Iz; Mon, 11 Aug 2003 10:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kzUe-0005wY-MF for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 01:08:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16433 for ; Fri, 8 Aug 2003 01:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kzUb-0005S8-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:08:45 -0400 Received: from law12-f118.law12.hotmail.com ([64.4.19.118] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19kzUb-0005S5-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:08:45 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 Aug 2003 22:08:15 -0700 Received: from 63.197.79.145 by lw12fd.law12.hotmail.msn.com with HTTP; Fri, 08 Aug 2003 05:08:15 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [george_s97@hotmail.com] From: "George Sheng" To: routing-discussion@ietf.org Subject: Re:Who speaks for whom Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2003 05:08:15.0545 (UTC) FILETIME=[12D6B290:01C35D6B] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 05:08:15 +0000 >For example, IGP adjacency state changes trigger new BGP >updates per IGP-derived MED values, subsequently triggering >new paths selected by adjacent routing domains, and so forth, >resulting in convergence issues and a domino effect for >downstream ASes. Maybe we should also consider IP interface "overloaded" with too many features, since if interface bounce/unstable, causing IGP adjacency bounce, which in turn causing BGP route changes. We should at least have some guidelines on what kind of features should be allowed on an interface. - George _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Aug 11 10:23:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17961 for ; Mon, 11 Aug 2003 10:23:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDZw-00055Y-9Z for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 10:23:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BENKc6019516 for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 10:23:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDZd-00053z-Iz; Mon, 11 Aug 2003 10:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kzUe-0005wY-MF for routing-discussion@optimus.ietf.org; Fri, 08 Aug 2003 01:08:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16433 for ; Fri, 8 Aug 2003 01:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kzUb-0005S8-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:08:45 -0400 Received: from law12-f118.law12.hotmail.com ([64.4.19.118] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19kzUb-0005S5-00 for routing-discussion@ietf.org; Fri, 08 Aug 2003 01:08:45 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 Aug 2003 22:08:15 -0700 Received: from 63.197.79.145 by lw12fd.law12.hotmail.msn.com with HTTP; Fri, 08 Aug 2003 05:08:15 GMT X-Originating-IP: [63.197.79.145] X-Originating-Email: [george_s97@hotmail.com] From: "George Sheng" To: routing-discussion@ietf.org Subject: Re:Who speaks for whom Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2003 05:08:15.0545 (UTC) FILETIME=[12D6B290:01C35D6B] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 08 Aug 2003 05:08:15 +0000 >For example, IGP adjacency state changes trigger new BGP >updates per IGP-derived MED values, subsequently triggering >new paths selected by adjacent routing domains, and so forth, >resulting in convergence issues and a domino effect for >downstream ASes. Maybe we should also consider IP interface "overloaded" with too many features, since if interface bounce/unstable, causing IGP adjacency bounce, which in turn causing BGP route changes. We should at least have some guidelines on what kind of features should be allowed on an interface. - George _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Aug 11 10:48:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19071 for ; Mon, 11 Aug 2003 10:48:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDy1-0006Qn-3f for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 10:48:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BEmDZa024711 for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 10:48:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDxp-0006Pn-1b; Mon, 11 Aug 2003 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDxG-0006O9-5U for routing-discussion@optimus.ietf.org; Mon, 11 Aug 2003 10:47:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19025 for ; Mon, 11 Aug 2003 10:47:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDxD-0006QA-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 10:47:23 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19mDxC-0006Pz-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 10:47:23 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h7BEkqu12013; Mon, 11 Aug 2003 07:46:52 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308111446.h7BEkqu12013@merlot.juniper.net> To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: Extending BGP In-Reply-To: Your message of "Thu, 07 Aug 2003 17:59:27 PDT." <910493458.20030807175927@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98586.1060613211.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 07:46:52 -0700 Alex, > Let's keep the original concerns in mind. > > Yakov Rekhter wrote: > >> Though it is possible to do a fine job of clearly separating different > >> applications of the same protocol within the system, using a separate > >> protocol makes it much more likely to happen. > > > Following your logic one should have a separate protocol per > > application, each with "its own life with independent (from BGP) > > features, extensions optimizations, etc." > > To repeat what I've said already, one of the major concerns is > stability of Internet routing. To repeat what I've (and few other folks) asked already, are we talking about stability of IPv4 unicast Internet routing ? Or IPv6 unicast Internet routing ? Or IPv4 multicast Internet routing ? Or IPv6 multicast Internet routing ? > Separating routing from non-routing > applications is the main thing we are talking about here, This is *one* of the things we are talking about here. But not the only one. We've yet to see any *rationale* explanation from the proponents of "separating routing from non-routing applications" on why such separation is sufficient, and per application separation is not needed. > but one can > certainly follow any logic to an absurd extreme. > > > Since you agree that it is quite possible "to do a fine job of > > clearly separating different applications of the same protocol within > > the system", let me suggest that the folks who are capable of > > doing such "fine job" should continue doing this, while the folks > > who need a separate protocol to make this happen should pursue the > > avenue of the separate protocol per application. > > The issue under discussion may affect very wide Internet community, > and I believe that shrugging it off in a manner "if you believe > there's an issue--it's your problem, feel free to solve it" would not > be appropriate and would only further polarize the community. We're > here to discuss the issue in the open and work out the direction for > future efforts. I have nothing against discussing "the issue in the open". Ditto for "work out the direction for future efforts". In fact, the above (from my original message) is my proposal for the direction: the folks who are capable of doing such "fine job" should continue doing this, while the folks who need a separate protocol to make this happen should pursue the avenue of the separate protocol per application. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Aug 11 10:48:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19070 for ; Mon, 11 Aug 2003 10:48:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDxp-0006Pn-1b; Mon, 11 Aug 2003 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDxG-0006O9-5U for routing-discussion@optimus.ietf.org; Mon, 11 Aug 2003 10:47:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19025 for ; Mon, 11 Aug 2003 10:47:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDxD-0006QA-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 10:47:23 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19mDxC-0006Pz-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 10:47:23 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h7BEkqu12013; Mon, 11 Aug 2003 07:46:52 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308111446.h7BEkqu12013@merlot.juniper.net> To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: Extending BGP In-Reply-To: Your message of "Thu, 07 Aug 2003 17:59:27 PDT." <910493458.20030807175927@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98586.1060613211.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 07:46:52 -0700 Alex, > Let's keep the original concerns in mind. > > Yakov Rekhter wrote: > >> Though it is possible to do a fine job of clearly separating different > >> applications of the same protocol within the system, using a separate > >> protocol makes it much more likely to happen. > > > Following your logic one should have a separate protocol per > > application, each with "its own life with independent (from BGP) > > features, extensions optimizations, etc." > > To repeat what I've said already, one of the major concerns is > stability of Internet routing. To repeat what I've (and few other folks) asked already, are we talking about stability of IPv4 unicast Internet routing ? Or IPv6 unicast Internet routing ? Or IPv4 multicast Internet routing ? Or IPv6 multicast Internet routing ? > Separating routing from non-routing > applications is the main thing we are talking about here, This is *one* of the things we are talking about here. But not the only one. We've yet to see any *rationale* explanation from the proponents of "separating routing from non-routing applications" on why such separation is sufficient, and per application separation is not needed. > but one can > certainly follow any logic to an absurd extreme. > > > Since you agree that it is quite possible "to do a fine job of > > clearly separating different applications of the same protocol within > > the system", let me suggest that the folks who are capable of > > doing such "fine job" should continue doing this, while the folks > > who need a separate protocol to make this happen should pursue the > > avenue of the separate protocol per application. > > The issue under discussion may affect very wide Internet community, > and I believe that shrugging it off in a manner "if you believe > there's an issue--it's your problem, feel free to solve it" would not > be appropriate and would only further polarize the community. We're > here to discuss the issue in the open and work out the direction for > future efforts. I have nothing against discussing "the issue in the open". Ditto for "work out the direction for future efforts". In fact, the above (from my original message) is my proposal for the direction: the folks who are capable of doing such "fine job" should continue doing this, while the folks who need a separate protocol to make this happen should pursue the avenue of the separate protocol per application. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Aug 11 11:01:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19506 for ; Mon, 11 Aug 2003 11:01:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEAX-0006q7-Cn for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 11:01:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BF19li026266 for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 11:01:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEAP-0006nB-KR; Mon, 11 Aug 2003 11:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mE9d-0006mD-R3 for routing-discussion@optimus.ietf.org; Mon, 11 Aug 2003 11:00:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19424 for ; Mon, 11 Aug 2003 11:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mE9b-0006U5-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:00:11 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19mE9a-0006TN-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:00:10 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h7BExdu12516; Mon, 11 Aug 2003 07:59:39 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308111459.h7BExdu12516@merlot.juniper.net> To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Thu, 07 Aug 2003 17:59:30 PDT." <6710496503.20030807175930@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1914.1060613979.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 07:59:39 -0700 Alex, > > I don't think there is any disagreement on the need to provide > > isolation between services. It is just that some folks claim that > > (a) there is no way to provide such isolation within BGP, (despite > > the fact that there are products on the market that do provide such > > isolation with BGP), and that (b) the new protocol is going to > > provide such isolation (which at the present moment is nothing but > > an unsubstantiated claim). > > I think it is not exactly that black-n-white. The way I read the > concerns people have about BGP overloading in particular is that folks > feel that the BGP-based approach introduces a higher risk of > interference with the routing functions than the non-BGP one. "feel" is not exactly an engineering term... (IETF suppose to work on engineering...) With this in mind the folks who *feel* "that the BGP-based approach introduces a higher risk of interference with the routing functions than the non-BGP one", and would like the IETF to work on this need to "convert" their feelings into a set of well-articulated *rationale* arguments of *practical* (as opposed to theoretical) significance. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Aug 11 11:14:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19905 for ; Mon, 11 Aug 2003 11:14:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEMz-0007Vk-Ac; Mon, 11 Aug 2003 11:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEMG-0007Up-4T for routing-discussion@optimus.ietf.org; Mon, 11 Aug 2003 11:13:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19877 for ; Mon, 11 Aug 2003 11:13:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEMF-0006bT-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:13:15 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19mEME-0006bF-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:13:14 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h7BFChu13670; Mon, 11 Aug 2003 08:12:43 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308111512.h7BFChu13670@merlot.juniper.net> To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: Your message of "Thu, 07 Aug 2003 18:18:44 PDT." <15211650582.20030807181844@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5606.1060614763.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 08:12:43 -0700 Alex, > Wednesday, August 6, 2003, 7:00:40 AM, Yakov Rekhter wrote: > > The discussion should certainly include extensions to ISIS, like > > carrying both IPv4 and IPv6 unicast routing, IPv4 unicast routes > > used by IPv4 multicast, IPv6 unicast routes used by IPv6 multicast, > > using ISIS Extensions for BGP Peer Discovery, using ISIS flooding > > procedures to carry TE information. > > > With this in mind I'd like to hear from the folks who argue against > > adding more stuff in BGP whether they also object against adding > > more stuff into ISIS. > > ISIS and OSPF are certainly within the discussion. Seems like we have an agreement on this... > On the other hand, I believe it was emphasized enough on the list that > the concern is largely about adding non-routing related info on RPs. I > think there is a good level of understanding that RPs will have new > features and extensions, but there is a desire to limit this to > routing-related applications as opposed to whatever human imagination > can come up with. Are we talking about theory or practice ? If the latter, then please provide few examples where vendors addition to RPs are based on "whatever human imagination can come up with", and not on the need to solve *practical* problems of their customers. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Aug 11 11:19:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20045 for ; Mon, 11 Aug 2003 11:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mERp-0007ik-Rk for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 11:19:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BFJ1v7029640 for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 11:19:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mERo-0007hJ-TO; Mon, 11 Aug 2003 11:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mERn-0007h8-UV for routing-discussion@optimus.ietf.org; Mon, 11 Aug 2003 11:18:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20037 for ; Mon, 11 Aug 2003 11:18:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mERn-0006d7-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:18:59 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19mERm-0006cu-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:18:58 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h7BFINu14106; Mon, 11 Aug 2003 08:18:23 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308111518.h7BFINu14106@merlot.juniper.net> To: "George Sheng" cc: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: Your message of "Fri, 08 Aug 2003 05:27:52 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7163.1060615103.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 08:18:23 -0700 George, > >For example, IGP adjacency state changes trigger new BGP > >updates per IGP-derived MED values, subsequently triggering > >new paths selected by adjacent routing domains, and so forth, > >resulting in convergence issues and a domino effect for > >downstream ASes. > > Let's also not forget to consider not "overloading" a local IP interface > with > unnecessary features. If an Interface bounces, it will cause IGP adjacency > bounce/unstable, which in turn will cause BGP unstable. We at least need > to have some guidelines on what features should or should not be added > onto the IP intefaces. Agreed. No need to be myopic - we should be looking at this from the *system-wide* point of view. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Aug 11 11:47:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19505 for ; Mon, 11 Aug 2003 11:01:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEAP-0006nB-KR; Mon, 11 Aug 2003 11:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mE9d-0006mD-R3 for routing-discussion@optimus.ietf.org; Mon, 11 Aug 2003 11:00:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19424 for ; Mon, 11 Aug 2003 11:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mE9b-0006U5-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:00:11 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19mE9a-0006TN-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:00:10 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h7BExdu12516; Mon, 11 Aug 2003 07:59:39 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308111459.h7BExdu12516@merlot.juniper.net> To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Your message of "Thu, 07 Aug 2003 17:59:30 PDT." <6710496503.20030807175930@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1914.1060613979.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 07:59:39 -0700 Alex, > > I don't think there is any disagreement on the need to provide > > isolation between services. It is just that some folks claim that > > (a) there is no way to provide such isolation within BGP, (despite > > the fact that there are products on the market that do provide such > > isolation with BGP), and that (b) the new protocol is going to > > provide such isolation (which at the present moment is nothing but > > an unsubstantiated claim). > > I think it is not exactly that black-n-white. The way I read the > concerns people have about BGP overloading in particular is that folks > feel that the BGP-based approach introduces a higher risk of > interference with the routing functions than the non-BGP one. "feel" is not exactly an engineering term... (IETF suppose to work on engineering...) With this in mind the folks who *feel* "that the BGP-based approach introduces a higher risk of interference with the routing functions than the non-BGP one", and would like the IETF to work on this need to "convert" their feelings into a set of well-articulated *rationale* arguments of *practical* (as opposed to theoretical) significance. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Aug 11 12:02:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19906 for ; Mon, 11 Aug 2003 11:14:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEN3-0007XC-HF for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 11:14:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BFE5uC028930 for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 11:14:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEMz-0007Vk-Ac; Mon, 11 Aug 2003 11:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mEMG-0007Up-4T for routing-discussion@optimus.ietf.org; Mon, 11 Aug 2003 11:13:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19877 for ; Mon, 11 Aug 2003 11:13:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEMF-0006bT-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:13:15 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19mEME-0006bF-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:13:14 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h7BFChu13670; Mon, 11 Aug 2003 08:12:43 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308111512.h7BFChu13670@merlot.juniper.net> To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: Your message of "Thu, 07 Aug 2003 18:18:44 PDT." <15211650582.20030807181844@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5606.1060614763.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 08:12:43 -0700 Alex, > Wednesday, August 6, 2003, 7:00:40 AM, Yakov Rekhter wrote: > > The discussion should certainly include extensions to ISIS, like > > carrying both IPv4 and IPv6 unicast routing, IPv4 unicast routes > > used by IPv4 multicast, IPv6 unicast routes used by IPv6 multicast, > > using ISIS Extensions for BGP Peer Discovery, using ISIS flooding > > procedures to carry TE information. > > > With this in mind I'd like to hear from the folks who argue against > > adding more stuff in BGP whether they also object against adding > > more stuff into ISIS. > > ISIS and OSPF are certainly within the discussion. Seems like we have an agreement on this... > On the other hand, I believe it was emphasized enough on the list that > the concern is largely about adding non-routing related info on RPs. I > think there is a good level of understanding that RPs will have new > features and extensions, but there is a desire to limit this to > routing-related applications as opposed to whatever human imagination > can come up with. Are we talking about theory or practice ? If the latter, then please provide few examples where vendors addition to RPs are based on "whatever human imagination can come up with", and not on the need to solve *practical* problems of their customers. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Aug 11 12:12:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20044 for ; Mon, 11 Aug 2003 11:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mERo-0007hJ-TO; Mon, 11 Aug 2003 11:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mERn-0007h8-UV for routing-discussion@optimus.ietf.org; Mon, 11 Aug 2003 11:18:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20037 for ; Mon, 11 Aug 2003 11:18:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mERn-0006d7-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:18:59 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19mERm-0006cu-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 11:18:58 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h7BFINu14106; Mon, 11 Aug 2003 08:18:23 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200308111518.h7BFINu14106@merlot.juniper.net> To: "George Sheng" cc: routing-discussion@ietf.org Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: Your message of "Fri, 08 Aug 2003 05:27:52 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7163.1060615103.1@juniper.net> From: Yakov Rekhter Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 08:18:23 -0700 George, > >For example, IGP adjacency state changes trigger new BGP > >updates per IGP-derived MED values, subsequently triggering > >new paths selected by adjacent routing domains, and so forth, > >resulting in convergence issues and a domino effect for > >downstream ASes. > > Let's also not forget to consider not "overloading" a local IP interface > with > unnecessary features. If an Interface bounces, it will cause IGP adjacency > bounce/unstable, which in turn will cause BGP unstable. We at least need > to have some guidelines on what features should or should not be added > onto the IP intefaces. Agreed. No need to be myopic - we should be looking at this from the *system-wide* point of view. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Aug 11 19:30:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10703 for ; Mon, 11 Aug 2003 19:30:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mM6z-0000kW-SJ; Mon, 11 Aug 2003 19:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mM6a-0000k8-0E for routing-discussion@optimus.ietf.org; Mon, 11 Aug 2003 19:29:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10688 for ; Mon, 11 Aug 2003 19:29:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mM6Y-00035w-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 19:29:34 -0400 Received: from nsw-dial-006-100.dialup.nsw.csiro.au ([130.155.6.100] helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19mM6Q-00035l-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 19:29:30 -0400 Received: from mrp.net (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h7BNQBB8002364; Tue, 12 Aug 2003 08:57:45 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F382613.5000708@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter CC: Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200308111459.h7BExdu12516@merlot.juniper.net> In-Reply-To: <200308111459.h7BExdu12516@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 12 Aug 2003 08:56:11 +0930 Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: > With this in mind the folks who *feel* "that the BGP-based approach > introduces a higher risk of interference with the routing functions > than the non-BGP one", and would like the IETF to work on this need > to "convert" their feelings into a set of well-articulated *rationale* > arguments of *practical* (as opposed to theoretical) significance. > That's all very well but how do you propose that they try to come up with a practical argument if they are arguing not to do something? Can you show them that the reverse is true? Mark. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Aug 11 19:30:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10714 for ; Mon, 11 Aug 2003 19:30:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mM7B-0000mH-Gg for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 19:30:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BNUD4b002930 for routing-discussion-archive@odin.ietf.org; Mon, 11 Aug 2003 19:30:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mM6z-0000kW-SJ; Mon, 11 Aug 2003 19:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mM6a-0000k8-0E for routing-discussion@optimus.ietf.org; Mon, 11 Aug 2003 19:29:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10688 for ; Mon, 11 Aug 2003 19:29:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mM6Y-00035w-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 19:29:34 -0400 Received: from nsw-dial-006-100.dialup.nsw.csiro.au ([130.155.6.100] helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19mM6Q-00035l-00 for routing-discussion@ietf.org; Mon, 11 Aug 2003 19:29:30 -0400 Received: from mrp.net (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h7BNQBB8002364; Tue, 12 Aug 2003 08:57:45 +0930 (CST) (envelope-from mrp@mrp.net) Message-ID: <3F382613.5000708@mrp.net> From: Mark Prior User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter CC: Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200308111459.h7BExdu12516@merlot.juniper.net> In-Reply-To: <200308111459.h7BExdu12516@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 12 Aug 2003 08:56:11 +0930 Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: > With this in mind the folks who *feel* "that the BGP-based approach > introduces a higher risk of interference with the routing functions > than the non-BGP one", and would like the IETF to work on this need > to "convert" their feelings into a set of well-articulated *rationale* > arguments of *practical* (as opposed to theoretical) significance. > That's all very well but how do you propose that they try to come up with a practical argument if they are arguing not to do something? Can you show them that the reverse is true? Mark. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Aug 12 09:47:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13218 for ; Tue, 12 Aug 2003 09:47:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZUn-0003Kr-Nd for routing-discussion-archive@odin.ietf.org; Tue, 12 Aug 2003 09:47:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CDlToP012808 for routing-discussion-archive@odin.ietf.org; Tue, 12 Aug 2003 09:47:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZUL-0003Jm-VQ; Tue, 12 Aug 2003 09:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZTy-0003He-4j for routing-discussion@optimus.ietf.org; Tue, 12 Aug 2003 09:46:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13180 for ; Tue, 12 Aug 2003 09:46:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZTw-0000Vg-00 for routing-discussion@ietf.org; Tue, 12 Aug 2003 09:46:36 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19mZTv-0000VI-00 for routing-discussion@ietf.org; Tue, 12 Aug 2003 09:46:35 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7CDjK322121 for ; Tue, 12 Aug 2003 09:45:20 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Aug 2003 09:45:17 -0400 Message-ID: From: "Hamid Ould-Brahim" To: Alex Zinin , Routing Discussion Subject: RE: RP overloading: Next Steps X-Mailer: Internet Mail Service (5.5.2653.19) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 12 Aug 2003 09:40:59 -0400 Alex, [clipped]... > > What I think we should do is form a design team that would group > people who believe that we DO need an alternative to MP-BGP for > non-routing info distribution and know what functions it should > perform. This team would then be asked to come up with these two > documents, that would be discussed on this list and in Minneapolis > (we would either bring it to the open RTG area meeting, or have a > BOF for this topic explicitly.) > Two comments on that: - If I take the example of former ppvpn wg, there was in fact a design team created specifically for the discovery mechanism or to be more precise, a design team that explores requirements and alternatives to non MP-BGP provider-based VPN discovery for those who didn't like BGP option for one reason or another. After much debate, the outcome of that design team was inconclusive and produced only a requirement document on that topic. My question is how the above proposal is any different from what has already been done in former ppvpn wg? - It looks to me even if some people believe we DO need alternative to MP-BGP for non routing info distribution, this in my opinion should be part of the discussions going on in each specific application (similarly to what has been done in ppvpn). I do not expect *routing-area* discussions/work to produce a protocol that is mainly intended for non routing related application being pursued in other working groups. Hamid. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Aug 12 10:34:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13217 for ; Tue, 12 Aug 2003 09:47:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZUL-0003Jm-VQ; Tue, 12 Aug 2003 09:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZTy-0003He-4j for routing-discussion@optimus.ietf.org; Tue, 12 Aug 2003 09:46:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13180 for ; Tue, 12 Aug 2003 09:46:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZTw-0000Vg-00 for routing-discussion@ietf.org; Tue, 12 Aug 2003 09:46:36 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19mZTv-0000VI-00 for routing-discussion@ietf.org; Tue, 12 Aug 2003 09:46:35 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7CDjK322121 for ; Tue, 12 Aug 2003 09:45:20 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Aug 2003 09:45:17 -0400 Message-ID: From: "Hamid Ould-Brahim" To: Alex Zinin , Routing Discussion Subject: RE: RP overloading: Next Steps X-Mailer: Internet Mail Service (5.5.2653.19) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 12 Aug 2003 09:40:59 -0400 Alex, [clipped]... > > What I think we should do is form a design team that would group > people who believe that we DO need an alternative to MP-BGP for > non-routing info distribution and know what functions it should > perform. This team would then be asked to come up with these two > documents, that would be discussed on this list and in Minneapolis > (we would either bring it to the open RTG area meeting, or have a > BOF for this topic explicitly.) > Two comments on that: - If I take the example of former ppvpn wg, there was in fact a design team created specifically for the discovery mechanism or to be more precise, a design team that explores requirements and alternatives to non MP-BGP provider-based VPN discovery for those who didn't like BGP option for one reason or another. After much debate, the outcome of that design team was inconclusive and produced only a requirement document on that topic. My question is how the above proposal is any different from what has already been done in former ppvpn wg? - It looks to me even if some people believe we DO need alternative to MP-BGP for non routing info distribution, this in my opinion should be part of the discussions going on in each specific application (similarly to what has been done in ppvpn). I do not expect *routing-area* discussions/work to produce a protocol that is mainly intended for non routing related application being pursued in other working groups. Hamid. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 13 17:00:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05850 for ; Wed, 13 Aug 2003 17:00:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2iw-0007wJ-BB; Wed, 13 Aug 2003 17:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2i5-0007v9-Fw for routing-discussion@optimus.ietf.org; Wed, 13 Aug 2003 16:59:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05639 for ; Wed, 13 Aug 2003 16:59:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2i3-0004zm-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 16:59:07 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19n2i2-0004zj-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 16:59:06 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7DKwa6s050387; Wed, 13 Aug 2003 16:58:36 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h7DKwWLu050380; Wed, 13 Aug 2003 16:58:32 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7DKwRE02789; Wed, 13 Aug 2003 16:58:27 -0400 (EDT) From: Jeffrey Haas To: Hamid Ould-Brahim Cc: Alex Zinin , Routing Discussion Subject: Re: RP overloading: Next Steps Message-ID: <20030813165826.A9088@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hbrahim@nortelnetworks.com on Tue, Aug 12, 2003 at 09:40:59AM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 16:58:26 -0400 Hamid, On Tue, Aug 12, 2003 at 09:40:59AM -0400, Hamid Ould-Brahim wrote: > My question is how the above proposal is any different from > what has already been done in former ppvpn wg? I don't think it differs at all. BGP *can* be used for it and is being used successfully. The problem with doing something that you think can break is the people who expect the problems can only look on and either be disappointed that their fears were unjustified if things don't break or look on with horror as they break. > I do not expect *routing-area* discussions/work to produce > a protocol that is mainly intended for non routing related > application being pursued in other working groups. This is the wonderful demi-mess that got us the layer2.5 work in the first place - neither one spot nor another. :-) IMO, the changes can be done in a fairly simple set of changes to BGP that will make all parties happy. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 13 17:00:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05852 for ; Wed, 13 Aug 2003 17:00:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2jQ-000851-PS for routing-discussion-archive@odin.ietf.org; Wed, 13 Aug 2003 17:00:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DL0WYv031043 for routing-discussion-archive@odin.ietf.org; Wed, 13 Aug 2003 17:00:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2iw-0007wJ-BB; Wed, 13 Aug 2003 17:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2i5-0007v9-Fw for routing-discussion@optimus.ietf.org; Wed, 13 Aug 2003 16:59:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05639 for ; Wed, 13 Aug 2003 16:59:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2i3-0004zm-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 16:59:07 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19n2i2-0004zj-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 16:59:06 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7DKwa6s050387; Wed, 13 Aug 2003 16:58:36 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h7DKwWLu050380; Wed, 13 Aug 2003 16:58:32 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7DKwRE02789; Wed, 13 Aug 2003 16:58:27 -0400 (EDT) From: Jeffrey Haas To: Hamid Ould-Brahim Cc: Alex Zinin , Routing Discussion Subject: Re: RP overloading: Next Steps Message-ID: <20030813165826.A9088@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hbrahim@nortelnetworks.com on Tue, Aug 12, 2003 at 09:40:59AM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 16:58:26 -0400 Hamid, On Tue, Aug 12, 2003 at 09:40:59AM -0400, Hamid Ould-Brahim wrote: > My question is how the above proposal is any different from > what has already been done in former ppvpn wg? I don't think it differs at all. BGP *can* be used for it and is being used successfully. The problem with doing something that you think can break is the people who expect the problems can only look on and either be disappointed that their fears were unjustified if things don't break or look on with horror as they break. > I do not expect *routing-area* discussions/work to produce > a protocol that is mainly intended for non routing related > application being pursued in other working groups. This is the wonderful demi-mess that got us the layer2.5 work in the first place - neither one spot nor another. :-) IMO, the changes can be done in a fairly simple set of changes to BGP that will make all parties happy. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 13 18:41:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10039 for ; Wed, 13 Aug 2003 18:41:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4Io-0006Qk-8X for routing-discussion-archive@odin.ietf.org; Wed, 13 Aug 2003 18:41:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DMfA6p024714 for routing-discussion-archive@odin.ietf.org; Wed, 13 Aug 2003 18:41:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4Ig-0006Pk-Ed; Wed, 13 Aug 2003 18:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4Hx-0006P9-QW for routing-discussion@optimus.ietf.org; Wed, 13 Aug 2003 18:40:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10028 for ; Wed, 13 Aug 2003 18:40:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n4Hu-0005n0-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 18:40:14 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19n4Hu-0005mx-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 18:40:14 -0400 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJK00ENUX9RSB@firewall.wcom.com> for routing-discussion@ietf.org; Wed, 13 Aug 2003 22:32:15 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJK00N01X9R00@pmismtp05.wcomnet.com> for routing-discussion@ietf.org; Wed, 13 Aug 2003 22:32:15 +0000 (GMT) Received: from rbonica ([166.32.199.163]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJK00JBPX9QXG@pmismtp05.wcomnet.com> for routing-discussion@ietf.org; Wed, 13 Aug 2003 22:32:14 +0000 (GMT) From: Ron Bonica Subject: Extending BGP To: routing-discussion@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 18:32:55 -0400 Content-Transfer-Encoding: 7bit Folks, To date, I hear two sub-threads running through this discussion. One sub-thread addresses software engineering, while the other addresses Internet Architecture. The software engineering thread revolves around the notions of "functions", "protocols" and "software modules". Some have suggested that if we assign too many functions to a protocol (BGP), we increase the complexity of its supporting software modules beyond acceptable limits. Because BGP is central to the well-being of the Internet, this causes Internet providers great concern. Others have pointed out that the IETF's assignment of functions to protocols does not dictate a vendor's assignment of those same functions to software modules. Therefore, vendors can produce stable, modular implementations of very complex protocols. (They can also produce less stable, less modular implementations of simple protocols!) As the mapping of functions to software modules is beyond the scope of the IETF, I suggest that we not pursue this software engineering sub-thread. As Pedro points out, another sub-thread addresses the Internet Architecture. This sub-thread contains echoes of an older debate between the IP-centric and the IP-convergence-minded. The IP-centric believe that the Internet should provide IP services only. The IP-convergence-minded believe that the Internet should support multiple services by tunneling through an IP platform. As it is not likely that we will settle this debate in this forum, I suggest that we also not pursue this sub-thread, either. So, what is there left to discuss? :-) As we ask routers to do more things, we may need a generic database synchronization mechanism whose capabilities are beyond those of BGP. For example, it may require security, prioritization and convergence features that are not currently supported by BGP. If we take this opportunity to specify a new database convergence mechanism, we could support these features. We could also specify the mechanism in isolation from the many applications that will consume its services. At this point, we might do well to examine whether we have enough new requirements to justify the specification of an new, generic database synchronization protocol. Maybe its time to bring this discussion from the IRTF to the IETF? =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "An eye for an eye only ends up making the whole world blind." -- Gandhi _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 13 19:17:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10776 for ; Wed, 13 Aug 2003 19:17:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4rb-0008Dr-6c for routing-discussion-archive@odin.ietf.org; Wed, 13 Aug 2003 19:17:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DNH7X5031606 for routing-discussion-archive@odin.ietf.org; Wed, 13 Aug 2003 19:17:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4rW-0008Cy-B0; Wed, 13 Aug 2003 19:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4rC-0008Bs-IQ for routing-discussion@optimus.ietf.org; Wed, 13 Aug 2003 19:16:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10758 for ; Wed, 13 Aug 2003 19:16:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n4rA-0005wv-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 19:16:40 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19n4rA-0005ws-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 19:16:40 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19n4rA-000Of3-C0; Wed, 13 Aug 2003 23:16:40 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <159522463923.20030813161218@psg.com> To: "Hamid Ould-Brahim" CC: Routing Discussion Subject: Re: RP overloading: Next Steps In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 16:12:18 -0700 Content-Transfer-Encoding: 7bit Hamid, > Two comments on that: > - If I take the example of former ppvpn wg, there was in fact a design > team created specifically for the discovery mechanism or to be > more precise, a design team that explores requirements and > alternatives to non MP-BGP provider-based VPN discovery for > those who didn't like BGP option for one reason or another. > After much debate, the outcome of that design > team was inconclusive and produced only a requirement document > on that topic. > My question is how the above proposal is any different from > what has already been done in former ppvpn wg? The two are very different. The scope of the discussion of the DT in PPVPN was to look at the specific problem of VPN discovery and possible solutions for it. This one would look at an alternative to MP-BGP for data distribution among routers in general. Fundamental assumptions are also different. In the PPVPN case people with different basic opinions (using MP-BGP is ok vs not ok) were in the same group, which made consensus building hard, if at all possible. In this case, the DT would start off from the statement "OK, if we wanted an alternative to MP-BGP for data distribution among routers, what would it look like?" > - It looks to me even if some people believe we DO need alternative > to MP-BGP for non routing info distribution, this in my opinion > should be part of the discussions going on in each specific > application (similarly to what has been done in ppvpn). > I do not expect *routing-area* discussions/work to produce > a protocol that is mainly intended for non routing related > application being pursued in other working groups. Well, as we can see, apparently routing area did produce a protocol that is being used for non-routing related application. Given that the alternative may inherit a lot from the work that was done here on flooding and policy-based routing info distribution, I believe RTG area would be the right place. Consideration of the application-specific transport requirements should be part of the discussion, of course. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 13 19:28:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10038 for ; Wed, 13 Aug 2003 18:41:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4Ig-0006Pk-Ed; Wed, 13 Aug 2003 18:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4Hx-0006P9-QW for routing-discussion@optimus.ietf.org; Wed, 13 Aug 2003 18:40:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10028 for ; Wed, 13 Aug 2003 18:40:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n4Hu-0005n0-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 18:40:14 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19n4Hu-0005mx-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 18:40:14 -0400 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJK00ENUX9RSB@firewall.wcom.com> for routing-discussion@ietf.org; Wed, 13 Aug 2003 22:32:15 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJK00N01X9R00@pmismtp05.wcomnet.com> for routing-discussion@ietf.org; Wed, 13 Aug 2003 22:32:15 +0000 (GMT) Received: from rbonica ([166.32.199.163]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJK00JBPX9QXG@pmismtp05.wcomnet.com> for routing-discussion@ietf.org; Wed, 13 Aug 2003 22:32:14 +0000 (GMT) From: Ron Bonica Subject: Extending BGP To: routing-discussion@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 18:32:55 -0400 Content-Transfer-Encoding: 7bit Folks, To date, I hear two sub-threads running through this discussion. One sub-thread addresses software engineering, while the other addresses Internet Architecture. The software engineering thread revolves around the notions of "functions", "protocols" and "software modules". Some have suggested that if we assign too many functions to a protocol (BGP), we increase the complexity of its supporting software modules beyond acceptable limits. Because BGP is central to the well-being of the Internet, this causes Internet providers great concern. Others have pointed out that the IETF's assignment of functions to protocols does not dictate a vendor's assignment of those same functions to software modules. Therefore, vendors can produce stable, modular implementations of very complex protocols. (They can also produce less stable, less modular implementations of simple protocols!) As the mapping of functions to software modules is beyond the scope of the IETF, I suggest that we not pursue this software engineering sub-thread. As Pedro points out, another sub-thread addresses the Internet Architecture. This sub-thread contains echoes of an older debate between the IP-centric and the IP-convergence-minded. The IP-centric believe that the Internet should provide IP services only. The IP-convergence-minded believe that the Internet should support multiple services by tunneling through an IP platform. As it is not likely that we will settle this debate in this forum, I suggest that we also not pursue this sub-thread, either. So, what is there left to discuss? :-) As we ask routers to do more things, we may need a generic database synchronization mechanism whose capabilities are beyond those of BGP. For example, it may require security, prioritization and convergence features that are not currently supported by BGP. If we take this opportunity to specify a new database convergence mechanism, we could support these features. We could also specify the mechanism in isolation from the many applications that will consume its services. At this point, we might do well to examine whether we have enough new requirements to justify the specification of an new, generic database synchronization protocol. Maybe its time to bring this discussion from the IRTF to the IETF? =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "An eye for an eye only ends up making the whole world blind." -- Gandhi _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 13 19:33:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11154 for ; Wed, 13 Aug 2003 19:33:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n572-0000NT-P0 for routing-discussion-archive@odin.ietf.org; Wed, 13 Aug 2003 19:33:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DNX4eo001441 for routing-discussion-archive@odin.ietf.org; Wed, 13 Aug 2003 19:33:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n56z-0000M6-Px; Wed, 13 Aug 2003 19:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n56M-0000LT-66 for routing-discussion@optimus.ietf.org; Wed, 13 Aug 2003 19:32:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11115 for ; Wed, 13 Aug 2003 19:32:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n56K-00061y-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 19:32:20 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19n56J-00061v-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 19:32:20 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19n56K-000PW8-B5 for routing-discussion@ietf.org; Wed, 13 Aug 2003 23:32:20 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <161523399949.20030813162754@psg.com> To: Routing Area Mailing List Subject: Mailing list for generic router data distribution effort MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 16:27:54 -0700 Content-Transfer-Encoding: 7bit Folks- In my message on Aug 1st (Subject: RP overloading: Next Steps) I suggested that we start exploring the alternative solutions: > 4. Start exploring the alternative space > > There is a considerable part of the community who believe that > overloading MP-BGP is not the right thing in the long run. This > was clear at the meeting, and is clear on this list too. While not > all of us may agree with this, ignoring this would be plain wrong, > I believe. > > I also believe that until we have some documented understanding of > the functional requirements and design considerations for the > alternative, the situation will not change and all our discussions > will remain purely theoretical. Writing requirement and framework > documents is not a pleasant exercise, but it seems that in this > case we need something all of us can read and discuss. In fact, I > think Eric's posting to the list could be a good start. > > What I think we should do is form a design team that would group > people who believe that we DO need an alternative to MP-BGP for > non-routing info distribution and know what functions it should > perform. This team would then be asked to come up with these two > documents, that would be discussed on this list and in Minneapolis > (we would either bring it to the open RTG area meeting, or have a > BOF for this topic explicitly.) To follow up on this, I requested that a mailing list is created that will host this effort: List name : rtg-rdd@ietf.org List URL : https://www1.ietf.org/mailman/listinfo/rtg-rdd To subscribe : URL above or rtg-rdd-request@ietf.org People interested in contributing to this effort are encouraged to subscribe to the list. A formal e-mail about the formation of the design team, its goals, and milestones will follow. -- Alex Zinin http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 13 20:03:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10777 for ; Wed, 13 Aug 2003 19:17:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4rW-0008Cy-B0; Wed, 13 Aug 2003 19:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4rC-0008Bs-IQ for routing-discussion@optimus.ietf.org; Wed, 13 Aug 2003 19:16:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10758 for ; Wed, 13 Aug 2003 19:16:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n4rA-0005wv-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 19:16:40 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19n4rA-0005ws-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 19:16:40 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19n4rA-000Of3-C0; Wed, 13 Aug 2003 23:16:40 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <159522463923.20030813161218@psg.com> To: "Hamid Ould-Brahim" CC: Routing Discussion Subject: Re: RP overloading: Next Steps In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 16:12:18 -0700 Content-Transfer-Encoding: 7bit Hamid, > Two comments on that: > - If I take the example of former ppvpn wg, there was in fact a design > team created specifically for the discovery mechanism or to be > more precise, a design team that explores requirements and > alternatives to non MP-BGP provider-based VPN discovery for > those who didn't like BGP option for one reason or another. > After much debate, the outcome of that design > team was inconclusive and produced only a requirement document > on that topic. > My question is how the above proposal is any different from > what has already been done in former ppvpn wg? The two are very different. The scope of the discussion of the DT in PPVPN was to look at the specific problem of VPN discovery and possible solutions for it. This one would look at an alternative to MP-BGP for data distribution among routers in general. Fundamental assumptions are also different. In the PPVPN case people with different basic opinions (using MP-BGP is ok vs not ok) were in the same group, which made consensus building hard, if at all possible. In this case, the DT would start off from the statement "OK, if we wanted an alternative to MP-BGP for data distribution among routers, what would it look like?" > - It looks to me even if some people believe we DO need alternative > to MP-BGP for non routing info distribution, this in my opinion > should be part of the discussions going on in each specific > application (similarly to what has been done in ppvpn). > I do not expect *routing-area* discussions/work to produce > a protocol that is mainly intended for non routing related > application being pursued in other working groups. Well, as we can see, apparently routing area did produce a protocol that is being used for non-routing related application. Given that the alternative may inherit a lot from the work that was done here on flooding and policy-based routing info distribution, I believe RTG area would be the right place. Consideration of the application-specific transport requirements should be part of the discussion, of course. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 13 20:23:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11155 for ; Wed, 13 Aug 2003 19:33:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n56z-0000M6-Px; Wed, 13 Aug 2003 19:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n56M-0000LT-66 for routing-discussion@optimus.ietf.org; Wed, 13 Aug 2003 19:32:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11115 for ; Wed, 13 Aug 2003 19:32:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n56K-00061y-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 19:32:20 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19n56J-00061v-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 19:32:20 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19n56K-000PW8-B5 for routing-discussion@ietf.org; Wed, 13 Aug 2003 23:32:20 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <161523399949.20030813162754@psg.com> To: Routing Area Mailing List Subject: Mailing list for generic router data distribution effort MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 16:27:54 -0700 Content-Transfer-Encoding: 7bit Folks- In my message on Aug 1st (Subject: RP overloading: Next Steps) I suggested that we start exploring the alternative solutions: > 4. Start exploring the alternative space > > There is a considerable part of the community who believe that > overloading MP-BGP is not the right thing in the long run. This > was clear at the meeting, and is clear on this list too. While not > all of us may agree with this, ignoring this would be plain wrong, > I believe. > > I also believe that until we have some documented understanding of > the functional requirements and design considerations for the > alternative, the situation will not change and all our discussions > will remain purely theoretical. Writing requirement and framework > documents is not a pleasant exercise, but it seems that in this > case we need something all of us can read and discuss. In fact, I > think Eric's posting to the list could be a good start. > > What I think we should do is form a design team that would group > people who believe that we DO need an alternative to MP-BGP for > non-routing info distribution and know what functions it should > perform. This team would then be asked to come up with these two > documents, that would be discussed on this list and in Minneapolis > (we would either bring it to the open RTG area meeting, or have a > BOF for this topic explicitly.) To follow up on this, I requested that a mailing list is created that will host this effort: List name : rtg-rdd@ietf.org List URL : https://www1.ietf.org/mailman/listinfo/rtg-rdd To subscribe : URL above or rtg-rdd-request@ietf.org People interested in contributing to this effort are encouraged to subscribe to the list. A formal e-mail about the formation of the design team, its goals, and milestones will follow. -- Alex Zinin http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Aug 13 20:23:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12521 for ; Wed, 13 Aug 2003 20:23:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n5tN-0003Qw-F6; Wed, 13 Aug 2003 20:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n5t1-0003Qf-2L for routing-discussion@optimus.ietf.org; Wed, 13 Aug 2003 20:22:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12501 for ; Wed, 13 Aug 2003 20:22:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n5sy-0006S7-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 20:22:36 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19n5sy-0006S4-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 20:22:36 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19n5sy-0002Zc-Rz; Thu, 14 Aug 2003 00:22:36 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <146526401114.20030813171755@psg.com> To: Routing Area Mailing List CC: grow@lists.uoregon.edu Subject: Mailing list for BFD MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 17:17:55 -0700 Content-Transfer-Encoding: 7bit Folks- In order to continue the discussion on draft-katz-ward-bfd in an organized fashion, the following mailing list has been established: List name : rtg-bfd@ietf.org List URL : https://www1.ietf.org/mailman/listinfo/rtg-bfd To subscribe : URL above or rtg-bfd-request@ietf.org Interested participants are encouraged to subscribed to the list. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Aug 13 21:13:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12523 for ; Wed, 13 Aug 2003 20:23:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n5ti-0003S7-6A for routing-discussion-archive@odin.ietf.org; Wed, 13 Aug 2003 20:23:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7E0NMCQ013250 for routing-discussion-archive@odin.ietf.org; Wed, 13 Aug 2003 20:23:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n5tN-0003Qw-F6; Wed, 13 Aug 2003 20:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n5t1-0003Qf-2L for routing-discussion@optimus.ietf.org; Wed, 13 Aug 2003 20:22:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12501 for ; Wed, 13 Aug 2003 20:22:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n5sy-0006S7-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 20:22:36 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19n5sy-0006S4-00 for routing-discussion@ietf.org; Wed, 13 Aug 2003 20:22:36 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19n5sy-0002Zc-Rz; Thu, 14 Aug 2003 00:22:36 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <146526401114.20030813171755@psg.com> To: Routing Area Mailing List CC: grow@lists.uoregon.edu Subject: Mailing list for BFD MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 13 Aug 2003 17:17:55 -0700 Content-Transfer-Encoding: 7bit Folks- In order to continue the discussion on draft-katz-ward-bfd in an organized fashion, the following mailing list has been established: List name : rtg-bfd@ietf.org List URL : https://www1.ietf.org/mailman/listinfo/rtg-bfd To subscribe : URL above or rtg-bfd-request@ietf.org Interested participants are encouraged to subscribed to the list. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 14 20:58:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03184 for ; Thu, 14 Aug 2003 20:58:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nStp-0008Ki-4H; Thu, 14 Aug 2003 20:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nSsw-0008KL-Df for routing-discussion@optimus.ietf.org; Thu, 14 Aug 2003 20:56:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03168 for ; Thu, 14 Aug 2003 20:56:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nSsu-0007H6-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 20:56:04 -0400 Received: from pcp745132pcs.reston01.va.comcast.net ([68.49.139.245] helo=mail.krioukov.net) by ietf-mx with esmtp (Exim 4.12) id 19nSst-0007H0-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 20:56:03 -0400 Received: from DIMA1 (dhcp-host-017.pcp744791pcs.reston01.va.comcast.net [192.168.1.17]) by mail.krioukov.net (8.11.6/8.11.6) with SMTP id h7F0tNX06668; Thu, 14 Aug 2003 20:55:23 -0400 From: "Dmitri Krioukov" To: Cc: "Geoff Huston" , Subject: RE: Open Routing Area meeting in Vienna Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200307302122.h6ULMUxc011134@rtp-core-2.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 14 Aug 2003 20:55:21 -0400 Content-Transfer-Encoding: 7bit I think it would be hard to list various intermingled causes of instability in the order of increasing importance, but the research results we've seen so far suggest that in the first place, it's the routing algorithm the BGP chose to implement running over the Internet topology possessing the small-world property (i.e. the very small average hop distance and distance distribution width). -- dima. http://www.krioukov.net/~dima/ > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Eric Rosen > Sent: Wednesday, July 30, 2003 5:23 PM > To: Geoff Huston > Cc: routing-discussion@ietf.org > Subject: Re: Open Routing Area meeting in Vienna > > > > Geoff> There _are_ problems in BGP deployments, and overloading > the running > Geoff> instance of the protocol to carry more information related > to various > Geoff> overlay signalling applications does not in itself > assist in > Geoff> improving the situation. For me its a counter-intuitive > action that > Geoff> increases the level of operational reliance on a single > element of > Geoff> the network. > > This is all true, but it seems like a deployment issue > rather than a > protocol issue. > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 14 20:58:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03187 for ; Thu, 14 Aug 2003 20:58:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nSus-0008Ln-7y for routing-discussion-archive@odin.ietf.org; Thu, 14 Aug 2003 20:58:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7F0w6wv032098 for routing-discussion-archive@odin.ietf.org; Thu, 14 Aug 2003 20:58:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nStp-0008Ki-4H; Thu, 14 Aug 2003 20:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nSsw-0008KL-Df for routing-discussion@optimus.ietf.org; Thu, 14 Aug 2003 20:56:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03168 for ; Thu, 14 Aug 2003 20:56:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nSsu-0007H6-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 20:56:04 -0400 Received: from pcp745132pcs.reston01.va.comcast.net ([68.49.139.245] helo=mail.krioukov.net) by ietf-mx with esmtp (Exim 4.12) id 19nSst-0007H0-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 20:56:03 -0400 Received: from DIMA1 (dhcp-host-017.pcp744791pcs.reston01.va.comcast.net [192.168.1.17]) by mail.krioukov.net (8.11.6/8.11.6) with SMTP id h7F0tNX06668; Thu, 14 Aug 2003 20:55:23 -0400 From: "Dmitri Krioukov" To: Cc: "Geoff Huston" , Subject: RE: Open Routing Area meeting in Vienna Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200307302122.h6ULMUxc011134@rtp-core-2.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 14 Aug 2003 20:55:21 -0400 Content-Transfer-Encoding: 7bit I think it would be hard to list various intermingled causes of instability in the order of increasing importance, but the research results we've seen so far suggest that in the first place, it's the routing algorithm the BGP chose to implement running over the Internet topology possessing the small-world property (i.e. the very small average hop distance and distance distribution width). -- dima. http://www.krioukov.net/~dima/ > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Eric Rosen > Sent: Wednesday, July 30, 2003 5:23 PM > To: Geoff Huston > Cc: routing-discussion@ietf.org > Subject: Re: Open Routing Area meeting in Vienna > > > > Geoff> There _are_ problems in BGP deployments, and overloading > the running > Geoff> instance of the protocol to carry more information related > to various > Geoff> overlay signalling applications does not in itself > assist in > Geoff> improving the situation. For me its a counter-intuitive > action that > Geoff> increases the level of operational reliance on a single > element of > Geoff> the network. > > This is all true, but it seems like a deployment issue > rather than a > protocol issue. > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 14 21:04:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03492 for ; Thu, 14 Aug 2003 21:04:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nT0K-0000Dn-1A for routing-discussion-archive@odin.ietf.org; Thu, 14 Aug 2003 21:03:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7F13hZ3000815 for routing-discussion-archive@odin.ietf.org; Thu, 14 Aug 2003 21:03:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nSzd-0000AZ-Eo; Thu, 14 Aug 2003 21:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nSzW-0000AH-Es for routing-discussion@optimus.ietf.org; Thu, 14 Aug 2003 21:02:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03446 for ; Thu, 14 Aug 2003 21:02:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nSzU-0007Ju-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:02:52 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19nSzT-0007Jr-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:02:51 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19nSzT-0009BO-Qx for routing-discussion@ietf.org; Fri, 15 Aug 2003 01:02:51 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <96615458792.20030814180213@psg.com> To: routing-discussion@ietf.org Subject: Last Call on draft-gill-gtsh-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 14 Aug 2003 18:02:13 -0700 Content-Transfer-Encoding: 7bit Folks- The IESG received a request to progress draft-gill-gtsh-00.txt as an individual contribution towards the EXPERIMENTAL RFC status. The concept described in the document (as well as the original document known as draft-gill-btsh) has been widely discussed in the community, and I would like to start a 4-week Last Call on the Routing Area mailing list to encourage review and gauge the consensus on the document before taking it to the IESG. Please read the document and indicate if you support it going forward (do send a message if you support). The last call ends on September 12th, 2003. This message will be forwarded as an FYI to certain individual WGs. However, please send your comments to routing-discussion@ietf.org -- Alex Zinin IETF Routing Area Co-Director http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 14 21:09:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03579 for ; Thu, 14 Aug 2003 21:09:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nT4T-0000YR-Bm; Thu, 14 Aug 2003 21:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nT3V-0000Kw-Ll for routing-discussion@optimus.ietf.org; Thu, 14 Aug 2003 21:07:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03558 for ; Thu, 14 Aug 2003 21:06:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nT3T-0007L2-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:06:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19nT3S-0007Kp-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:06:58 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Aug 2003 18:06:30 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7F16QLH000935; Thu, 14 Aug 2003 18:06:26 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-132.cisco.com [128.107.163.132]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKJ93204; Thu, 14 Aug 2003 17:59:12 -0700 (PDT) Message-ID: <3F3C3210.4A1EB08F@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dmitri Krioukov CC: erosen@cisco.com, Geoff Huston , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 15 Aug 2003 03:06:24 +0200 Content-Transfer-Encoding: 7bit Dima, But what you are saying explicitely indicates that even just for ipv4 routing information distribution use of current BGP routing algorithm is a bad choice. I think that even Alex himself did not intended to go that far with this thread :-). R. > Dmitri Krioukov wrote: > > I think it would be hard to list various > intermingled causes of instability in > the order of increasing importance, but > the research results we've seen so far > suggest that in the first place, it's the > routing algorithm the BGP chose to > implement running over the Internet > topology possessing the small-world > property (i.e. the very small average hop > distance and distance distribution width). > -- > dima. > http://www.krioukov.net/~dima/ > > > -----Original Message----- > > From: routing-discussion-admin@ietf.org > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Eric Rosen > > Sent: Wednesday, July 30, 2003 5:23 PM > > To: Geoff Huston > > Cc: routing-discussion@ietf.org > > Subject: Re: Open Routing Area meeting in Vienna > > > > > > > > Geoff> There _are_ problems in BGP deployments, and overloading > > the running > > Geoff> instance of the protocol to carry more information related > > to various > > Geoff> overlay signalling applications does not in itself > > assist in > > Geoff> improving the situation. For me its a counter-intuitive > > action that > > Geoff> increases the level of operational reliance on a single > > element of > > Geoff> the network. > > > > This is all true, but it seems like a deployment issue > > rather than a > > protocol issue. > > > > > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 14 21:46:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04109 for ; Thu, 14 Aug 2003 21:46:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nTf0-0001jE-Ca for routing-discussion-archive@odin.ietf.org; Thu, 14 Aug 2003 21:45:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7F1jk2r006621 for routing-discussion-archive@odin.ietf.org; Thu, 14 Aug 2003 21:45:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nTeH-0001gG-Iq; Thu, 14 Aug 2003 21:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nTdd-0001do-NM for routing-discussion@optimus.ietf.org; Thu, 14 Aug 2003 21:44:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04079 for ; Thu, 14 Aug 2003 21:44:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nTda-0007UG-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:44:19 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19nTda-0007UC-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:44:18 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19nTda-0003rG-5y; Thu, 14 Aug 2003 18:44:18 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Last Call on draft-gill-gtsh-00.txt References: <96615458792.20030814180213@psg.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 14 Aug 2003 18:44:17 -0700 Content-Transfer-Encoding: 7bit the new version is even more useful than the previous, which i thought worthwhile. randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 14 21:53:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03491 for ; Thu, 14 Aug 2003 21:04:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nSzd-0000AZ-Eo; Thu, 14 Aug 2003 21:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nSzW-0000AH-Es for routing-discussion@optimus.ietf.org; Thu, 14 Aug 2003 21:02:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03446 for ; Thu, 14 Aug 2003 21:02:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nSzU-0007Ju-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:02:52 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19nSzT-0007Jr-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:02:51 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19nSzT-0009BO-Qx for routing-discussion@ietf.org; Fri, 15 Aug 2003 01:02:51 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <96615458792.20030814180213@psg.com> To: routing-discussion@ietf.org Subject: Last Call on draft-gill-gtsh-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 14 Aug 2003 18:02:13 -0700 Content-Transfer-Encoding: 7bit Folks- The IESG received a request to progress draft-gill-gtsh-00.txt as an individual contribution towards the EXPERIMENTAL RFC status. The concept described in the document (as well as the original document known as draft-gill-btsh) has been widely discussed in the community, and I would like to start a 4-week Last Call on the Routing Area mailing list to encourage review and gauge the consensus on the document before taking it to the IESG. Please read the document and indicate if you support it going forward (do send a message if you support). The last call ends on September 12th, 2003. This message will be forwarded as an FYI to certain individual WGs. However, please send your comments to routing-discussion@ietf.org -- Alex Zinin IETF Routing Area Co-Director http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 14 21:58:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03578 for ; Thu, 14 Aug 2003 21:09:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nT58-0000dE-Cg for routing-discussion-archive@odin.ietf.org; Thu, 14 Aug 2003 21:08:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7F18g9m002416 for routing-discussion-archive@odin.ietf.org; Thu, 14 Aug 2003 21:08:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nT4T-0000YR-Bm; Thu, 14 Aug 2003 21:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nT3V-0000Kw-Ll for routing-discussion@optimus.ietf.org; Thu, 14 Aug 2003 21:07:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03558 for ; Thu, 14 Aug 2003 21:06:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nT3T-0007L2-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:06:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19nT3S-0007Kp-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:06:58 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 Aug 2003 18:06:30 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7F16QLH000935; Thu, 14 Aug 2003 18:06:26 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-132.cisco.com [128.107.163.132]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKJ93204; Thu, 14 Aug 2003 17:59:12 -0700 (PDT) Message-ID: <3F3C3210.4A1EB08F@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dmitri Krioukov CC: erosen@cisco.com, Geoff Huston , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 15 Aug 2003 03:06:24 +0200 Content-Transfer-Encoding: 7bit Dima, But what you are saying explicitely indicates that even just for ipv4 routing information distribution use of current BGP routing algorithm is a bad choice. I think that even Alex himself did not intended to go that far with this thread :-). R. > Dmitri Krioukov wrote: > > I think it would be hard to list various > intermingled causes of instability in > the order of increasing importance, but > the research results we've seen so far > suggest that in the first place, it's the > routing algorithm the BGP chose to > implement running over the Internet > topology possessing the small-world > property (i.e. the very small average hop > distance and distance distribution width). > -- > dima. > http://www.krioukov.net/~dima/ > > > -----Original Message----- > > From: routing-discussion-admin@ietf.org > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Eric Rosen > > Sent: Wednesday, July 30, 2003 5:23 PM > > To: Geoff Huston > > Cc: routing-discussion@ietf.org > > Subject: Re: Open Routing Area meeting in Vienna > > > > > > > > Geoff> There _are_ problems in BGP deployments, and overloading > > the running > > Geoff> instance of the protocol to carry more information related > > to various > > Geoff> overlay signalling applications does not in itself > > assist in > > Geoff> improving the situation. For me its a counter-intuitive > > action that > > Geoff> increases the level of operational reliance on a single > > element of > > Geoff> the network. > > > > This is all true, but it seems like a deployment issue > > rather than a > > protocol issue. > > > > > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 14 22:33:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04108 for ; Thu, 14 Aug 2003 21:46:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nTeH-0001gG-Iq; Thu, 14 Aug 2003 21:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nTdd-0001do-NM for routing-discussion@optimus.ietf.org; Thu, 14 Aug 2003 21:44:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04079 for ; Thu, 14 Aug 2003 21:44:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nTda-0007UG-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:44:19 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19nTda-0007UC-00 for routing-discussion@ietf.org; Thu, 14 Aug 2003 21:44:18 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19nTda-0003rG-5y; Thu, 14 Aug 2003 18:44:18 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Last Call on draft-gill-gtsh-00.txt References: <96615458792.20030814180213@psg.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 14 Aug 2003 18:44:17 -0700 Content-Transfer-Encoding: 7bit the new version is even more useful than the previous, which i thought worthwhile. randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Aug 19 17:49:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10744 for ; Tue, 19 Aug 2003 17:49:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pELd-0005JE-61; Tue, 19 Aug 2003 17:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nXfA-0000Ze-UP for routing-discussion@optimus.ietf.org; Fri, 15 Aug 2003 02:02:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08497 for ; Fri, 15 Aug 2003 02:02:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nXf7-0000PZ-00 for routing-discussion@ietf.org; Fri, 15 Aug 2003 02:02:09 -0400 Received: from bay8-dav28.bay8.hotmail.com ([64.4.26.85] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19nXf6-0000PW-00 for routing-discussion@ietf.org; Fri, 15 Aug 2003 02:02:08 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Aug 2003 23:01:39 -0700 Received: from 203.221.58.203 by bay8-dav28.bay8.hotmail.com with DAV; Fri, 15 Aug 2003 06:01:39 +0000 X-Originating-IP: [203.221.58.203] X-Originating-Email: [killmipls@hotmail.com] From: "Ang Soo Kee" To: Subject: Bellman-Ford algorithm MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C36347.13244DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Message-ID: X-OriginalArrivalTime: 15 Aug 2003 06:01:39.0480 (UTC) FILETIME=[B16CA180:01C362F2] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 15 Aug 2003 16:05:41 +1000 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C36347.13244DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Does anyone have the implementation of Bellman Ford shortest path = algorithm in Matlab? I'm sure someone had done it and I would be thankful, if someone can = share his/her code with me. Thanks, Nicholas ------=_NextPart_000_0013_01C36347.13244DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Does anyone have the implementation of = Bellman Ford=20 shortest path algorithm in Matlab?
 
I'm sure someone had done it and I = would be=20 thankful, if someone can share his/her code with me.
 
Thanks,
Nicholas
------=_NextPart_000_0013_01C36347.13244DC0-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Aug 19 18:39:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10746 for ; Tue, 19 Aug 2003 17:49:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pELx-0005NR-HL for routing-discussion-archive@odin.ietf.org; Tue, 19 Aug 2003 17:49:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JLnLPn020655 for routing-discussion-archive@odin.ietf.org; Tue, 19 Aug 2003 17:49:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pELd-0005JE-61; Tue, 19 Aug 2003 17:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nXfA-0000Ze-UP for routing-discussion@optimus.ietf.org; Fri, 15 Aug 2003 02:02:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08497 for ; Fri, 15 Aug 2003 02:02:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nXf7-0000PZ-00 for routing-discussion@ietf.org; Fri, 15 Aug 2003 02:02:09 -0400 Received: from bay8-dav28.bay8.hotmail.com ([64.4.26.85] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19nXf6-0000PW-00 for routing-discussion@ietf.org; Fri, 15 Aug 2003 02:02:08 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Aug 2003 23:01:39 -0700 Received: from 203.221.58.203 by bay8-dav28.bay8.hotmail.com with DAV; Fri, 15 Aug 2003 06:01:39 +0000 X-Originating-IP: [203.221.58.203] X-Originating-Email: [killmipls@hotmail.com] From: "Ang Soo Kee" To: Subject: Bellman-Ford algorithm MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C36347.13244DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Message-ID: X-OriginalArrivalTime: 15 Aug 2003 06:01:39.0480 (UTC) FILETIME=[B16CA180:01C362F2] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 15 Aug 2003 16:05:41 +1000 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C36347.13244DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Does anyone have the implementation of Bellman Ford shortest path = algorithm in Matlab? I'm sure someone had done it and I would be thankful, if someone can = share his/her code with me. Thanks, Nicholas ------=_NextPart_000_0013_01C36347.13244DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Does anyone have the implementation of = Bellman Ford=20 shortest path algorithm in Matlab?
 
I'm sure someone had done it and I = would be=20 thankful, if someone can share his/her code with me.
 
Thanks,
Nicholas
------=_NextPart_000_0013_01C36347.13244DC0-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Aug 26 15:24:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27606 for ; Tue, 26 Aug 2003 15:24:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjQD-0000Cn-V0; Tue, 26 Aug 2003 15:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q6s9-0004ss-3g for routing-discussion@optimus.ietf.org; Fri, 22 Aug 2003 04:02:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09459; Fri, 22 Aug 2003 03:47:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q6dm-0000Kg-00; Fri, 22 Aug 2003 03:47:22 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19q6dl-0000KD-00; Fri, 22 Aug 2003 03:47:21 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7M7koC32692; Fri, 22 Aug 2003 10:46:50 +0300 From: Pekka Savola To: routing-discussion@ietf.org cc: bob@thefinks.com, , Subject: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 22 Aug 2003 10:46:50 +0300 (EEST) FYI; Your oxen are being gutted and you're invited to the bloodfest. In other words.. Feedback & Review is sought. Please take a look at the routing IPv4 survey document: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt It's not too long; please send feedback. In particular, it would be good to identify specifications which have incorrect information, or specifications which are not longer relevant and could be moved to historic (if someone bothered to do that, but that's a different topic), or the like. Thanks, Pekka, Jonne & Bob v6ops co-chairs ---------- Forwarded message ---------- Date: Fri, 22 Aug 2003 10:38:49 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Cc: bob@thefinks.com, jonne.soininen@nokia.com, cesar.olvera@consulintel.es, andreas.bergstrom@hiof.no Subject: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents Hi all, This is a WG Last Call for comments on sending the following the next three "Survey of IPv4 Addresses in Currently Deployed IETF Standards" documents to the IESG for consideration as Informational RFCs: Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-01.txt Please review these documents carefully, and send your feedback to the list (editorial modifications may also be sent to the editors, Cesar for the first, Andreas for the other two). Please also indicate whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the documents will not be send to the IESG. The last call will end in 3 weeks, on 12th September. Pekka, Jonne & Bob _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Aug 26 15:25:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27627 for ; Tue, 26 Aug 2003 15:25:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjQf-0000IX-1K for routing-discussion-archive@odin.ietf.org; Tue, 26 Aug 2003 15:24:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QJOXql001145 for routing-discussion-archive@odin.ietf.org; Tue, 26 Aug 2003 15:24:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjQD-0000Cn-V0; Tue, 26 Aug 2003 15:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q6s9-0004ss-3g for routing-discussion@optimus.ietf.org; Fri, 22 Aug 2003 04:02:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09459; Fri, 22 Aug 2003 03:47:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q6dm-0000Kg-00; Fri, 22 Aug 2003 03:47:22 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19q6dl-0000KD-00; Fri, 22 Aug 2003 03:47:21 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7M7koC32692; Fri, 22 Aug 2003 10:46:50 +0300 From: Pekka Savola To: routing-discussion@ietf.org cc: bob@thefinks.com, , Subject: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 22 Aug 2003 10:46:50 +0300 (EEST) FYI; Your oxen are being gutted and you're invited to the bloodfest. In other words.. Feedback & Review is sought. Please take a look at the routing IPv4 survey document: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt It's not too long; please send feedback. In particular, it would be good to identify specifications which have incorrect information, or specifications which are not longer relevant and could be moved to historic (if someone bothered to do that, but that's a different topic), or the like. Thanks, Pekka, Jonne & Bob v6ops co-chairs ---------- Forwarded message ---------- Date: Fri, 22 Aug 2003 10:38:49 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Cc: bob@thefinks.com, jonne.soininen@nokia.com, cesar.olvera@consulintel.es, andreas.bergstrom@hiof.no Subject: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents Hi all, This is a WG Last Call for comments on sending the following the next three "Survey of IPv4 Addresses in Currently Deployed IETF Standards" documents to the IESG for consideration as Informational RFCs: Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-01.txt Please review these documents carefully, and send your feedback to the list (editorial modifications may also be sent to the editors, Cesar for the first, Andreas for the other two). Please also indicate whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the documents will not be send to the IESG. The last call will end in 3 weeks, on 12th September. Pekka, Jonne & Bob _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Aug 26 15:49:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01912 for ; Tue, 26 Aug 2003 15:49:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjoQ-0003vw-Dx; Tue, 26 Aug 2003 15:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjjE-0003JI-OF for routing-discussion@optimus.ietf.org; Tue, 26 Aug 2003 15:43:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00937 for ; Tue, 26 Aug 2003 15:43:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rjjD-0007ea-00 for routing-discussion@ietf.org; Tue, 26 Aug 2003 15:43:43 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19rjjB-0007dV-00 for routing-discussion@ietf.org; Tue, 26 Aug 2003 15:43:41 -0400 Message-ID: From: Jeff Parker To: "'Pekka Savola'" , routing-discussion@ietf.org Cc: bob@thefinks.com, jonne.soininen@nokia.com, cesar.olvera@consulintel.es Subject: RE: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 26 Aug 2003 15:42:53 -0400 > Feedback & Review is sought. Please take a look at the routing IPv4 > survey document: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surve > y-routing-01.txt From the doc above: 5.1 RFC 1195 Use of OSI IS-IS for routing in TCP/IP and dual environments (IS-IS) This document specifies a protocol for the exchange of IPv4 routing information. It is incompatible with IPv6. There are substantial work being done on a newer version of IS-IS that should include IPv6 routing. While RFC 1195 does not claim to describe including v6 info in IS-IS, IS-IS is not incompatible with IPv6. IS-IS is simply agnostic about IP. See draft-ietf-isis-ipv6-05.txt (Routing IPv6 with IS-IS) for details. - jeff parker - axiowave networks - There's no place like 127.0.0.1 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Aug 26 15:49:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01933 for ; Tue, 26 Aug 2003 15:49:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjoZ-0003yM-H8 for routing-discussion-archive@odin.ietf.org; Tue, 26 Aug 2003 15:49:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QJnFXY015188 for routing-discussion-archive@odin.ietf.org; Tue, 26 Aug 2003 15:49:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjoQ-0003vw-Dx; Tue, 26 Aug 2003 15:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjjE-0003JI-OF for routing-discussion@optimus.ietf.org; Tue, 26 Aug 2003 15:43:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00937 for ; Tue, 26 Aug 2003 15:43:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rjjD-0007ea-00 for routing-discussion@ietf.org; Tue, 26 Aug 2003 15:43:43 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19rjjB-0007dV-00 for routing-discussion@ietf.org; Tue, 26 Aug 2003 15:43:41 -0400 Message-ID: From: Jeff Parker To: "'Pekka Savola'" , routing-discussion@ietf.org Cc: bob@thefinks.com, jonne.soininen@nokia.com, cesar.olvera@consulintel.es Subject: RE: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 26 Aug 2003 15:42:53 -0400 > Feedback & Review is sought. Please take a look at the routing IPv4 > survey document: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surve > y-routing-01.txt From the doc above: 5.1 RFC 1195 Use of OSI IS-IS for routing in TCP/IP and dual environments (IS-IS) This document specifies a protocol for the exchange of IPv4 routing information. It is incompatible with IPv6. There are substantial work being done on a newer version of IS-IS that should include IPv6 routing. While RFC 1195 does not claim to describe including v6 info in IS-IS, IS-IS is not incompatible with IPv6. IS-IS is simply agnostic about IP. See draft-ietf-isis-ipv6-05.txt (Routing IPv6 with IS-IS) for details. - jeff parker - axiowave networks - There's no place like 127.0.0.1 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Aug 26 16:24:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05797 for ; Tue, 26 Aug 2003 16:24:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rkGl-0006Hh-Vr; Tue, 26 Aug 2003 16:18:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjtv-0004Lr-Ba for routing-discussion@optimus.ietf.org; Tue, 26 Aug 2003 15:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02428 for ; Tue, 26 Aug 2003 15:54:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rjtt-0000GE-00 for routing-discussion@ietf.org; Tue, 26 Aug 2003 15:54:45 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19rjts-0000Fm-00 for routing-discussion@ietf.org; Tue, 26 Aug 2003 15:54:44 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28780; Tue, 26 Aug 2003 15:54:03 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA07208; Tue, 26 Aug 2003 15:54:04 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 15:54:03 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55FB6FDA@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Pekka Savola'" , routing-discussion@ietf.org Cc: bob@thefinks.com, jonne.soininen@nokia.com, cesar.olvera@consulintel.es Subject: RE: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 26 Aug 2003 15:53:55 -0400 Pekka, -> FYI; -> -> Your oxen are being gutted and you're invited to the bloodfest. -> -> In other words.. -> -> Feedback & Review is sought. Please take a look at the routing IPv4 -> survey document: -> -> -> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surv -> ey-routing-01.txt -> -> It's not too long; please send feedback. In particular, it -> would be good -> to identify specifications which have incorrect information, or -> specifications which are not longer relevant and could be moved to -> historic (if someone bothered to do that, but that's a -> different topic), -> or the like. RFC 1745 is historic now. Look at RFC 3167. Looks like BCP RFCs are not considered. Venkata. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Aug 26 17:16:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10627 for ; Tue, 26 Aug 2003 17:16:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rkLs-0006cn-2I for routing-discussion-archive@odin.ietf.org; Tue, 26 Aug 2003 16:23:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QKNdqL025384 for routing-discussion-archive@odin.ietf.org; Tue, 26 Aug 2003 16:23:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rkGl-0006Hh-Vr; Tue, 26 Aug 2003 16:18:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rjtv-0004Lr-Ba for routing-discussion@optimus.ietf.org; Tue, 26 Aug 2003 15:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02428 for ; Tue, 26 Aug 2003 15:54:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rjtt-0000GE-00 for routing-discussion@ietf.org; Tue, 26 Aug 2003 15:54:45 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19rjts-0000Fm-00 for routing-discussion@ietf.org; Tue, 26 Aug 2003 15:54:44 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28780; Tue, 26 Aug 2003 15:54:03 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA07208; Tue, 26 Aug 2003 15:54:04 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 15:54:03 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55FB6FDA@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Pekka Savola'" , routing-discussion@ietf.org Cc: bob@thefinks.com, jonne.soininen@nokia.com, cesar.olvera@consulintel.es Subject: RE: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 26 Aug 2003 15:53:55 -0400 Pekka, -> FYI; -> -> Your oxen are being gutted and you're invited to the bloodfest. -> -> In other words.. -> -> Feedback & Review is sought. Please take a look at the routing IPv4 -> survey document: -> -> -> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surv -> ey-routing-01.txt -> -> It's not too long; please send feedback. In particular, it -> would be good -> to identify specifications which have incorrect information, or -> specifications which are not longer relevant and could be moved to -> historic (if someone bothered to do that, but that's a -> different topic), -> or the like. RFC 1745 is historic now. Look at RFC 3167. Looks like BCP RFCs are not considered. Venkata. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 28 04:52:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18574 for ; Thu, 28 Aug 2003 04:52:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDLK-0005w4-UK; Wed, 27 Aug 2003 23:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8aN-0003uD-QZ for routing-discussion@optimus.ietf.org; Wed, 27 Aug 2003 18:16:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13742 for ; Wed, 27 Aug 2003 18:16:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s8aK-0001g9-00 for routing-discussion@ietf.org; Wed, 27 Aug 2003 18:16:12 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19s8aK-0001g6-00 for routing-discussion@ietf.org; Wed, 27 Aug 2003 18:16:12 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.22) id 19s8aK-000CwY-OF for routing-discussion@ietf.org; Wed, 27 Aug 2003 22:16:12 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <45526260933.20030827151530@psg.com> To: routing-discussion@ietf.org Subject: Design Team: Routing Protocol Overloading MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 27 Aug 2003 15:15:30 -0700 Content-Transfer-Encoding: 7bit Design Team: Routing Protocol Overloading Mission Statement: The design team will document the concerns and considerations for using Internet routing protocols for functions not directly related to routing of IP packets within the Internet and IP networks. DT Lead: David Meyer Membership: David Meyer Kireeti Kompella Hank Kilmer Danny McPherson Pete Whiting Milestones: September 2003: Submit the -00 version of the draft for the discussion within the DR November 2003: Submit the -01 version of the draft for the discussion on the RTG area mailing list _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 28 07:22:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02431 for ; Thu, 28 Aug 2003 07:22:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIVT-0000MM-Sd for routing-discussion-archive@odin.ietf.org; Thu, 28 Aug 2003 04:51:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S8ppGn001300 for routing-discussion-archive@odin.ietf.org; Thu, 28 Aug 2003 04:51:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDLK-0005w4-UK; Wed, 27 Aug 2003 23:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8aN-0003uD-QZ for routing-discussion@optimus.ietf.org; Wed, 27 Aug 2003 18:16:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13742 for ; Wed, 27 Aug 2003 18:16:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s8aK-0001g9-00 for routing-discussion@ietf.org; Wed, 27 Aug 2003 18:16:12 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19s8aK-0001g6-00 for routing-discussion@ietf.org; Wed, 27 Aug 2003 18:16:12 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.22) id 19s8aK-000CwY-OF for routing-discussion@ietf.org; Wed, 27 Aug 2003 22:16:12 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <45526260933.20030827151530@psg.com> To: routing-discussion@ietf.org Subject: Design Team: Routing Protocol Overloading MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 27 Aug 2003 15:15:30 -0700 Content-Transfer-Encoding: 7bit Design Team: Routing Protocol Overloading Mission Statement: The design team will document the concerns and considerations for using Internet routing protocols for functions not directly related to routing of IP packets within the Internet and IP networks. DT Lead: David Meyer Membership: David Meyer Kireeti Kompella Hank Kilmer Danny McPherson Pete Whiting Milestones: September 2003: Submit the -00 version of the draft for the discussion within the DR November 2003: Submit the -01 version of the draft for the discussion on the RTG area mailing list _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Aug 28 18:23:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25549 for ; Thu, 28 Aug 2003 18:23:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQTF-0002KK-GW; Thu, 28 Aug 2003 13:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8bL-0003zS-IP for routing-discussion@optimus.ietf.org; Wed, 27 Aug 2003 18:17:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13879 for ; Wed, 27 Aug 2003 18:17:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s8bI-0001hy-00 for routing-discussion@ietf.org; Wed, 27 Aug 2003 18:17:12 -0400 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 19s8bH-0001hG-00 for routing-discussion@ietf.org; Wed, 27 Aug 2003 18:17:11 -0400 Received: from agns3k11.eng.timetra.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h7RMGfwA010380 for ; Wed, 27 Aug 2003 17:16:41 -0500 (CDT) From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <109526289704.20030827151559@alcatel.com> To: routing-discussion@ietf.org Subject: Design team: Router Data Distribution MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 27 Aug 2003 15:15:59 -0700 Content-Transfer-Encoding: 7bit Design team: Router Data Distribution Mission Statement: The design team will document functional requirements and design considerations for a protocol for distribution of generic data among IP routers within and between different Autonomous Systems and Service Provider networks. Applications described in the following drafts will be considered as examples of data that would need to be distributed: draft-ietf-l3vpn-bgpvpn-auto-00.txt draft-ietf-l2vpn-vpls-bgp-00.txt DT Lead: David Meyer Membership: Open subscription To subscribe: https://www1.ietf.org/mailman/listinfo/rtg-rdd Archives: https://www1.ietf.org/mail-archive/working-groups/rtg-rdd/current/maillist.html Milestones: SEP 2003: Submit the -00 version of the document for discussion within the DT OCT 2003: Submit the -01 version of the document for discussion on the RTG area mailing list -- Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Aug 28 21:40:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10302 for ; Thu, 28 Aug 2003 21:40:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sVAo-0008VG-VW for routing-discussion-archive@odin.ietf.org; Thu, 28 Aug 2003 18:23:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SMNMPH032683 for routing-discussion-archive@odin.ietf.org; Thu, 28 Aug 2003 18:23:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQTF-0002KK-GW; Thu, 28 Aug 2003 13:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8bL-0003zS-IP for routing-discussion@optimus.ietf.org; Wed, 27 Aug 2003 18:17:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13879 for ; Wed, 27 Aug 2003 18:17:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s8bI-0001hy-00 for routing-discussion@ietf.org; Wed, 27 Aug 2003 18:17:12 -0400 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 19s8bH-0001hG-00 for routing-discussion@ietf.org; Wed, 27 Aug 2003 18:17:11 -0400 Received: from agns3k11.eng.timetra.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h7RMGfwA010380 for ; Wed, 27 Aug 2003 17:16:41 -0500 (CDT) From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <109526289704.20030827151559@alcatel.com> To: routing-discussion@ietf.org Subject: Design team: Router Data Distribution MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 27 Aug 2003 15:15:59 -0700 Content-Transfer-Encoding: 7bit Design team: Router Data Distribution Mission Statement: The design team will document functional requirements and design considerations for a protocol for distribution of generic data among IP routers within and between different Autonomous Systems and Service Provider networks. Applications described in the following drafts will be considered as examples of data that would need to be distributed: draft-ietf-l3vpn-bgpvpn-auto-00.txt draft-ietf-l2vpn-vpls-bgp-00.txt DT Lead: David Meyer Membership: Open subscription To subscribe: https://www1.ietf.org/mailman/listinfo/rtg-rdd Archives: https://www1.ietf.org/mail-archive/working-groups/rtg-rdd/current/maillist.html Milestones: SEP 2003: Submit the -00 version of the document for discussion within the DT OCT 2003: Submit the -01 version of the document for discussion on the RTG area mailing list -- Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion