Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA02989 for ; Thu, 30 Mar 2000 09:35:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id C87C55DDB5; Thu, 30 Mar 2000 09:35:06 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B5C6A5DDB9; Thu, 30 Mar 2000 09:35:06 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by segue.merit.edu (Postfix) with ESMTP id 319545DDB5 for ; Thu, 30 Mar 2000 09:35:05 -0500 (EST) Received: from adn.alcatel.com (workstation.adn.alcatel.com [198.205.32.33] (may be forged)) by mail.nyp.ans.net (8.9.3/8.9.3) with ESMTP id JAA04447 for ; Thu, 30 Mar 2000 09:34:54 -0500 (EST) Received: from postal.adn.alcatel.com (postal [143.209.80.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id JAA11517 for ; Thu, 30 Mar 2000 09:27:48 -0500 (EST) Received: from adn.alcatel.com ([143.209.82.55]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA593; Thu, 30 Mar 2000 09:41:32 -0500 Message-ID: <38E365D5.2A337706@adn.alcatel.com> Date: Thu, 30 Mar 2000 09:33:58 -0500 From: Ben Abarbanel X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li Cc: cal022@lmpsil02.comm.mot.com, bgp@ans.net Subject: Re: Forcing routes in BGP References: <0F762B016151D2118F8900805FA795AF0365ECA2@s-il02-n.comm.mot.com> <38E293EC.9351CF46@adn.alcatel.com> <200003300029.QAA27648@miata.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Thanks Tony I appreciate the insight. Ben Tony Li wrote: > Gents, > > You're re-exploring much of the BGP design path from the early '90s. > > This is a fairly hard problem. You're looking for a symmetric route > between arbitrary domains that satisfies the policies of all transit > domains. This is decidedly non-trivial. We intentionally didn't go down > this path. > > Suggest you also check out IDPR for more background information. > > Tony > > | From: Ben Abarbanel > | Cc: BGP mailing list > | > | Sounds very reasonable to me that you want packets to take the same path on a > | round trip scenario. This > | I would consider as traffic engineering or somewhat constraint based routing. I > | think you imply that it should be done at the AS level and not at the IGP node > | level. correct me if I am wrong. I doubt seriously > | if this feature is possible in todays networks and level of routing. IP by its > | nature is unidirectional in nature and packets get to a destination via one > | criteria and arrive back from that destination via another criteria. > | In order to control/steer the packets along the same path and criteria a > | bidirectional routing system has > | to be in place. I dont see it now. Anybody else got any clues on how to solve > | this? > | > | Regards, > | Ben > | > | Lewis Adam-CAL022 wrote: > | > | > This is probably going to be viewed as a strange question, but ... > | > > | > Are there any means by which we can guarantee that a return route take the > | > same path as the source router? For example, assume there are 5 equally > | > weighted paths between Autononmous System-1 and Autonomous System-2. Also > | > assume this is symmetrical, such that the same 5 paths are equally weighted > | > when going between Autonomous System-2 and Autonomous System-1. What I hope > | > to do is ensure that a Unicast packet originating from Autonomous System-1 > | > destined to Autonomous System-2 always traverse the same path (links and > | > routers) as a Unicast packet originating from Autonomous System-2 destined > | > to Autonomous System-1. > | > > | > I am looking (if it exists) for a clean way to do this. We will be > | > designing many such networks, and each will have a different topology and > | > can be quite complex. So in other words I am not interested in attempting a > | > permutation of routes and weighting them accordingly. I don't know if what > | > I ask for is possible. Please advise. > | > > | > Thank you! > | > > | > adam > | > | -- > | Remember > | ======== > | "Don't be afraid to try something new. Amateurs built the Arc, professionals > | built Titanic" > | > | > | -- Remember ======== "Don't be afraid to try something new. Amateurs built the Arc, professionals built Titanic" Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA22670 for ; Wed, 29 Mar 2000 19:29:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id F1D775DE02; Wed, 29 Mar 2000 19:29:25 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E1AD65DDFD; Wed, 29 Mar 2000 19:29:25 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by segue.merit.edu (Postfix) with ESMTP id 475E65DDE6 for ; Wed, 29 Mar 2000 19:29:24 -0500 (EST) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by mail.nyp.ans.net (8.9.3/8.9.3) with ESMTP id TAA09133 for ; Wed, 29 Mar 2000 19:29:23 -0500 (EST) Received: (from tli@localhost) by miata.procket.com (8.9.3/8.8.7) id QAA27648; Wed, 29 Mar 2000 16:29:14 -0800 Date: Wed, 29 Mar 2000 16:29:14 -0800 Message-Id: <200003300029.QAA27648@miata.procket.com> X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: miata.procket.com: tli set sender to tli@miata.procket.com using -f From: Tony Li To: Benjamin.Abarbanel@adn.alcatel.com Cc: cal022@lmpsil02.comm.mot.com, bgp@ans.net In-reply-to: <38E293EC.9351CF46@adn.alcatel.com> (message from Ben Abarbanel on Wed, 29 Mar 2000 18:38:20 -0500) Subject: Re: Forcing routes in BGP References: <0F762B016151D2118F8900805FA795AF0365ECA2@s-il02-n.comm.mot.com> <38E293EC.9351CF46@adn.alcatel.com> Sender: owner-idr@merit.edu Precedence: bulk Gents, You're re-exploring much of the BGP design path from the early '90s. This is a fairly hard problem. You're looking for a symmetric route between arbitrary domains that satisfies the policies of all transit domains. This is decidedly non-trivial. We intentionally didn't go down this path. Suggest you also check out IDPR for more background information. Tony | From: Ben Abarbanel | Cc: BGP mailing list | | Sounds very reasonable to me that you want packets to take the same path on a | round trip scenario. This | I would consider as traffic engineering or somewhat constraint based routing. I | think you imply that it should be done at the AS level and not at the IGP node | level. correct me if I am wrong. I doubt seriously | if this feature is possible in todays networks and level of routing. IP by its | nature is unidirectional in nature and packets get to a destination via one | criteria and arrive back from that destination via another criteria. | In order to control/steer the packets along the same path and criteria a | bidirectional routing system has | to be in place. I dont see it now. Anybody else got any clues on how to solve | this? | | Regards, | Ben | | Lewis Adam-CAL022 wrote: | | > This is probably going to be viewed as a strange question, but ... | > | > Are there any means by which we can guarantee that a return route take the | > same path as the source router? For example, assume there are 5 equally | > weighted paths between Autononmous System-1 and Autonomous System-2. Also | > assume this is symmetrical, such that the same 5 paths are equally weighted | > when going between Autonomous System-2 and Autonomous System-1. What I hope | > to do is ensure that a Unicast packet originating from Autonomous System-1 | > destined to Autonomous System-2 always traverse the same path (links and | > routers) as a Unicast packet originating from Autonomous System-2 destined | > to Autonomous System-1. | > | > I am looking (if it exists) for a clean way to do this. We will be | > designing many such networks, and each will have a different topology and | > can be quite complex. So in other words I am not interested in attempting a | > permutation of routes and weighting them accordingly. I don't know if what | > I ask for is possible. Please advise. | > | > Thank you! | > | > adam | | -- | Remember | ======== | "Don't be afraid to try something new. Amateurs built the Arc, professionals | built Titanic" | | | Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA22088 for ; Wed, 29 Mar 2000 18:39:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA51B5DDD5; Wed, 29 Mar 2000 18:39:17 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C8E335DDA4; Wed, 29 Mar 2000 18:39:17 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by segue.merit.edu (Postfix) with ESMTP id 7FB6A5DD9C for ; Wed, 29 Mar 2000 18:39:16 -0500 (EST) Received: from adn.alcatel.com (workstation.adn.alcatel.com [198.205.32.33] (may be forged)) by mail.nyp.ans.net (8.9.3/8.9.3) with ESMTP id SAA07621 for ; Wed, 29 Mar 2000 18:39:15 -0500 (EST) Received: from postal.adn.alcatel.com (postal [143.209.80.56]) by adn.alcatel.com with ESMTP (8.7.6/8.7.1) id SAA00704 for ; Wed, 29 Mar 2000 18:32:09 -0500 (EST) Received: from adn.alcatel.com ([143.209.82.55]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA1C92; Wed, 29 Mar 2000 18:45:52 -0500 Message-ID: <38E293EC.9351CF46@adn.alcatel.com> Date: Wed, 29 Mar 2000 18:38:20 -0500 From: Ben Abarbanel X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Lewis Adam-CAL022 Cc: BGP mailing list Subject: Re: Forcing routes in BGP References: <0F762B016151D2118F8900805FA795AF0365ECA2@s-il02-n.comm.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sounds very reasonable to me that you want packets to take the same path on a round trip scenario. This I would consider as traffic engineering or somewhat constraint based routing. I think you imply that it should be done at the AS level and not at the IGP node level. correct me if I am wrong. I doubt seriously if this feature is possible in todays networks and level of routing. IP by its nature is unidirectional in nature and packets get to a destination via one criteria and arrive back from that destination via another criteria. In order to control/steer the packets along the same path and criteria a bidirectional routing system has to be in place. I dont see it now. Anybody else got any clues on how to solve this? Regards, Ben Lewis Adam-CAL022 wrote: > This is probably going to be viewed as a strange question, but ... > > Are there any means by which we can guarantee that a return route take the > same path as the source router? For example, assume there are 5 equally > weighted paths between Autononmous System-1 and Autonomous System-2. Also > assume this is symmetrical, such that the same 5 paths are equally weighted > when going between Autonomous System-2 and Autonomous System-1. What I hope > to do is ensure that a Unicast packet originating from Autonomous System-1 > destined to Autonomous System-2 always traverse the same path (links and > routers) as a Unicast packet originating from Autonomous System-2 destined > to Autonomous System-1. > > I am looking (if it exists) for a clean way to do this. We will be > designing many such networks, and each will have a different topology and > can be quite complex. So in other words I am not interested in attempting a > permutation of routes and weighting them accordingly. I don't know if what > I ask for is possible. Please advise. > > Thank you! > > adam -- Remember ======== "Don't be afraid to try something new. Amateurs built the Arc, professionals built Titanic" Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA27900 for ; Tue, 28 Mar 2000 15:18:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9FFEA5DDC3; Tue, 28 Mar 2000 15:15:29 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8F4B95DDBD; Tue, 28 Mar 2000 15:15:29 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by segue.merit.edu (Postfix) with ESMTP id 2E4FA5DDB3 for ; Tue, 28 Mar 2000 15:15:28 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by mail.nyp.ans.net (8.9.3/8.9.3) with ESMTP id PAA18121 for ; Tue, 28 Mar 2000 15:15:13 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA23874 for ; Tue, 28 Mar 2000 13:15:08 -0700 (MST)] Received: [from s-il02-e.comm.mot.com (s-il02-e.comm.mot.com [145.1.204.15]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA23493 for ; Tue, 28 Mar 2000 13:15:07 -0700 (MST)] Received: by s-il02-e.comm.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 14:15:06 -0600 Message-ID: <0F762B016151D2118F8900805FA795AF0365ECA2@s-il02-n.comm.mot.com> From: Lewis Adam-CAL022 To: BGP mailing list Subject: Forcing routes in BGP Date: Tue, 28 Mar 2000 14:15:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk This is probably going to be viewed as a strange question, but ... Are there any means by which we can guarantee that a return route take the same path as the source router? For example, assume there are 5 equally weighted paths between Autononmous System-1 and Autonomous System-2. Also assume this is symmetrical, such that the same 5 paths are equally weighted when going between Autonomous System-2 and Autonomous System-1. What I hope to do is ensure that a Unicast packet originating from Autonomous System-1 destined to Autonomous System-2 always traverse the same path (links and routers) as a Unicast packet originating from Autonomous System-2 destined to Autonomous System-1. I am looking (if it exists) for a clean way to do this. We will be designing many such networks, and each will have a different topology and can be quite complex. So in other words I am not interested in attempting a permutation of routes and weighting them accordingly. I don't know if what I ask for is possible. Please advise. Thank you! adam Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA10767 for ; Fri, 3 Mar 2000 09:20:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 728F25DD9A; Fri, 3 Mar 2000 09:19:55 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6246A5DD99; Fri, 3 Mar 2000 09:19:55 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 03DF75DD90 for ; Fri, 3 Mar 2000 09:19:54 -0500 (EST) Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA26923 for ; Fri, 3 Mar 2000 06:19:53 -0800 (PST) Message-Id: <200003031419.GAA26923@omega.cisco.com> To: idr@merit.edu Subject: revised version of draft-ietf-idr-bgp4-cap-neg-06.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26919.952093193.1@cisco.com> Date: Fri, 03 Mar 2000 06:19:53 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, Following request from the IESG the document uses the term "capability advertisement" rather than "capability negotiation". Yakov. ------- Forwarded Message Date: Fri, 03 Mar 2000 06:27:49 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-bgp4-cap-neg-06.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : Capabilities Advertisement with BGP-4 Author(s) : R. Chandra, J. Scudder Filename : draft-ietf-idr-bgp4-cap-neg-06.txt Pages : 5 Date : 02-Mar-00 Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP. This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability negotiation without requiring that BGP peering be terminated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-cap-neg-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-cap-neg-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-cap-neg-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000302150019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-cap-neg-06.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-cap-neg-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000302150019.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message