BGP4 path attribute

>----- Text sent by Tony Li follows -------
From tli@localhost Wed Feb 16 20:34:14 1994
X-Delivered: at request of jimi on dxcoms.cern.ch
Date: Wed, 16 Feb 1994 11:33:47 -0800
From: Tony Li tli@localhost
Message-Id: <199402161933.AA17081@localhost
To: jimi
Cc: MARTIN@localhost, bgp4-support@localhost
In-Reply-To: Jean-Michel Jouanigot's message of Wed, 16 Feb 1994 16:46:11 +0100 (MET) <9402161546.AA20622@localhost
Subject: BGP4 and 9.21


   From: jimi@localhost (Jean-Michel Jouanigot)

   Tony,
	   Sorry to bother you, but I have two questions  concerning
	   BGP4  and 9.21 (Feb5).  I think I've discovered something
	   odd.

You should use bgp4-support instead, please.  I have nothing to do
with BGP4.

	   Firstly, I'm currently playing with BGP4 on our  DMZ,  on
	   which  we used to run BGP3 for a while.  I configured one
	   test box as talking BGP4 with all the other  boxes,  some
	   of  them  being  in  the  same  AS  (513),  some other in
	   different ASes (1755).  When I did this, I kept  all  the
	   defaults in the BGP4 configurations.



			2043
			 |
			 |
	   +----+      +----+      +----+      +-----+
	   |EBS |      |H3  |      |H2  |      |TEST |
	   |1755|      |513 |      |513 |      |513  |    ......
	   +----+      +----+      +----+      +-----+
	     |           |           |           |
	     |           |           |           |   192.65.185.0
	     --------------------------------------------------


	   All boxes but TEST peer using  BGP3.  The  next  hop  for
	   them  is always on 192.65.185.0 when they want to reach a
	   net connected thru onother router.

	   For TEST, things are different. Suppose TEST wants to route to
	   192.87.45.1:

	   ctest1>sh ip bgp 192.87.45.1
	   BGP routing table entry for 192.87.45.0/255.255.255.0, version 5684
	   Paths: (2 available, best #1)
	     2043 1103 1104
	       193.172.24.9 from 192.65.185.5, weight 0
		 Origin IGP, valid, internal, best
	     1755 1128 1103 1104
	       192.65.185.4 from 192.65.185.4, metric 8481, weight 0
		 Origin IGP, valid, external

	   The Prefered path is the shortest, 2043  1103  1104,  but
	   the next hop is 193.172.24.9, which  happens  to  be  the
	   interface of 2043, but

	   ctest1>sh ip ro 193.172.24.9
	   Routing entry for 193.172.24.0 (mask 255.255.255.0)
	     Known via "bgp 513", distance 20, metric 8481
	     Tag 1755
	     Last update from 192.65.185.4 1:42:07 ago
	     Routing Descriptor Blocks:
	     * 192.65.185.4, from 192.65.185.4, 1:42:07 ago
		 Route metric is 8481, traffic share count is 1

That's a bug.  The routing table should always reflect the "best"
route.

	   since

	   ctest1>sh ip bgp 193.172.24.9
	   BGP routing table entry for 193.172.24.0/255.255.255.0, version 8755
	   Paths: (1 available, best #1)
	     1755 1128 2043
	       192.65.185.4 from 192.65.185.4, metric 8481, weight 0
		 Origin IGP, valid, external, best

	   OK, your going to  tell  me  that  2043  should  announce
	   193.172.24.0  to  H3,  or  that  we  can  fix  this using
	   next-hop-self or route maps, but still, it's not  what  I
	   understand from the BGP4 draft:

	   "A BGP speaker can advertise any external  border  router
	   as the next hop [1], provided that the IP address of this
	   border router was learned from one of the  BGP  speaker's
	   peers,  [2]  and  the  interface  associated  with the IP
	   address of  this  border  router  (as  specified  in  the
	   NEXT_HOP  path attribute) shares a common subnet with the
	   local and remote BGP speakers [3]."

	   [1] this is our case
	   [2] yes, from 1755
	   [3] No, the interconnection network is 192.65.185.0,  and
	   the   interconnection   between   2043   and  513  is  in
	   193.172.24.0

	   Am I wrong ?

	   Of  course,  the  routes  received  from  1755  were  all
	   indicating  a  NEXT_HOP  on  192.65.185.0.  This question
	   only concerns routes within 513.

	   Another question I  have  is  why  is  this  new  concept
	   introduced in BGP4?  What's the idea behind  this?  Who's
	   using  it?  This is very dangerous in the sense that if a
	   network is not announced by an external peer (2043 in  my
	   case), then all the routing is gone...

	   Another  point:  the  previous  drafts   of   BGP4   were
	   introducing  a  "BGP  path  attribute"  which was carried
	   together with the route.  In some  recent  extensions  of
	   Ripe-81,  and  after some discussions with Peter Lothberg
	   and Tony Bates, it appeared to us that this could be used
	   to   "color"   network   advertisements  and  carry  this
	   information thru the  Internet.  Any  reason  why  you've
	   dropped the idea ?

Yes, it tends to break aggregation.  Since you can't aggregate colored
routes together, it would cause people to not aggregate.  This would
increase the size of the routing tables.

Tony


-- 
Jean-Michel