Subject: Re: Forcing routes in BGP
From: Ben Abarbanel <[email-masked]>
To: Tony Li <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Thu, 30 Mar 2000 09:33:58 -0500

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 <[email-masked]>
> |  Cc: BGP mailing list <[email-masked]>
> |
> |  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"

Date: Wed, 29 Mar 2000 16:29:14 -0800
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Forcing routes in BGP
Sender: [email-masked]

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 <[email-masked]>
|  Cc: BGP mailing list <[email-masked]>
|  
|  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"
|  
|  
|  

Date: Wed, 29 Mar 2000 18:38:20 -0500
From: Ben Abarbanel <[email-masked]>
To: Lewis Adam-CAL022 <[email-masked]>
Cc: BGP mailing list <[email-masked]>
Subject: Re: Forcing routes in BGP
Sender: [email-masked]

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"

From: Lewis Adam-CAL022 <[email-masked]>
To: BGP mailing list <[email-masked]>
Subject: Forcing routes in BGP
Date: Tue, 28 Mar 2000 14:15:05 -0600
Sender: [email-masked]

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

To: [email-masked]
Subject: revised version of draft-ietf-idr-bgp4-cap-neg-06.txt 
Date: Fri, 03 Mar 2000 06:19:53 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message