Subject: Internal Update Process of BGP

From: Deepak Srivastava <[email-masked]>
Date: Wed, 02 May 2001 16:40:20 +0530

Hi, 

I am looking for some clarification on BGP internal update process as
stated in section 9.2.1 of rfc 1771. To illustrate my point let me
explain using the example given below.

According to rfc 1771 an internal update should be sent to internal
peers as part of phase 1 itself i.e. before start of phase 2. 

			    (x3)
		  ----------C-----------
	     IBGP|	  AS I	       |IBGP
		 |		       |
		 |		       |     EBGP
		 A---------------------B------------M (x2)
	       /AS I	  IBGP	    AS I \	    AS IV
	      /				  \
	     /EBGP			   \EBGP
	    /				    \
	    H				     K (x1)	
	   AS II			    AS III

	1. A, B and C are IBGP peers.
	2. H is an EBGP peer of A.
	3. K and M are EBGP peers of B.

Consider the following scenario in which a bgp speaker, say B, has three
updates for same destination x in its Adj-RIBs-IN viz x1, x2 and x3 with
degree of preference d1, d2 and d3 such that d3 >d2 >d1. Lets suppose
that
 
   1. Local system B does not have Next hop reachability for destination
      x2 in its Loc-RIB. 
   2. x3 is originated by one of the internal peers, say C.
   3. x1 and x2 are sent by external peers K and M, respectively.

According to decision process of rfc1771, x3 having larger DOP, will be
installed in Loc-RIB of B as best phase 2 route. 

Now my questions are : 

a) Will there ever be a situation when a BGP speaker (B) receive a route
   (x2) through an EBGP update for which there is no NH reachablity in
   its Loc_RIB.
   
   One way this could happen is if the sending speaker (M) sets some
   policy for next hop then it may be possible for receiving speaker
   (B) to not have NH reachability in its Loc-RIB.
   
   But then section 5.1.3 of <draft-ietf-idr-bgp4-12.txt> says

      When advertising a NEXT_HOP attribute to an external peer, a
      router may use one of its own interface addresses in the NEXT_HOP
      attribute provided the external peer to which the route is
      being advertised shares a common subnet with the NEXT_HOP address.
      This is known as a "first party" NEXT_HOP attribute.  A BGP
      speaker can advertise to an external peer an interface of any
      internal peer router in the NEXT_HOP attribute provided the
      external peer to which the route is being advertised shares a
      common subnet with the NEXT_HOP address.  This is known as a
      "third party" NEXT_HOP attribute.
      
   What I understand from this is, a bgp speaker (M) can only set
   some policy to change the NH of an update message to one of
   its interface address provided that the receiving external
   peer (B) shares a common subnet with that address.  
   
   I would appreciate if someone can enlighten this with a practical
   scenario when such a thing can happen.

b) What routes should be there in Adj-RIBs-IN of internal peer A.

1. x3 and x2. 
   x3 from C and x2 from B as it is the best route to send to internal
   peers according to section 9.2.1 of rfc 1771 having larger value of
   DOP among externally received route. 

2. x3 and x1. (If the answer to (a) is NO ). 

   But its nowhere written in rfc 1771 or in draft that  an external
   route for which next hop reachability is not there, should not be
   sent to internal peers.

3. x3 alone. 
   As it is the route which will be selected after phase 2 to be put
   in Loc-RIB of B, therefore B should withdraw the route x2 (or
   x1, whichever it has advertised earlier to A as part of internal
   update process) as according section 9.2.1 of draft:
   
      "When a BGP speaker receives a new route from an external peer, it
      MUST advertise that route to all other internal peers by means of
      an UPDATE message if this route will be installed in its Loc-RIB
      according to the route selection rules in 9.1.2."

   This means that only those route should be sent to internal peers
   which *will* be there in Loc-RIB after phase 2.

   ===================================================================
   The point of concern is, if the necessary condition for a route to
   be advertised to internal peers is that it should be present in
   Loc-RIB, then why rfc and draft both say that internal update can be
   sent (at the end/as part of) phase 1. 
   
   It appears that if the above is necessary condition then internal
   updates should be sent after phase 2 i.e. when Loc-RIB has been
   modified. Whats the point in first sending the update after phase 1
   and then withdrawing it if that route is not there in Loc-RIB.

   ===================================================================
   
NOTE: where ever I have given reference for draft, I
meant                                       

               <draft-ietf-idr-bgp4-12.txt>  

Regards,
Deepak Srivastava    

-- 
---------------------------------------------------------------------------------
DEEPAK SRIVASTAVA                          [email-masked]
Infosys- India Development Team            Phone Office: 91-80-8520261
Bangalore -INDIA                           Extn: 6522
--------------------------------------------------------------------------------