Subject: Re: Evaluation of Gateway Location proposals

From: Matt Squire <[email-masked]>
Date: Wed, 12 May 1999 13:48:14 -0400

Hussein - 

I included answers/comments interspersed with the original message.  I
tried to delete anything not relevant to your comments.

- Matt

>In
>order to scale well and not to overload the network with too much
>control traffic, routing protocols may have to tolerate a lower level of
>reliability than some application protocols. 
>

I'm not sure what you mean by a "lower level of reliability".  If the
routing information is not transmitted reliably, then routing loops can
occur.  All peers in a BGP administrative domain must have the same view of
the network.  Otherwise they can make independent decisions that cause
loops.  Reliability is a requirement, the question is where reliability
comes from.  

>>  Each UPDATE message may contain a number
>> of withdrawn routes and a single feasible route.  A withdrawn route is a
>> route that should be removed from the peer's RIB-IN.  A withdrawn route is
>> defined by a address/prefix-length.  A feasible route is defined as the
>> NLRI (network layer reachability information, ie a list of
>> address/prefix-length combinations) and its attributes.   A key mandatory
>> attribute is the NEXT-HOP attribute which gives the next-hop for the NLRI.
>> Basically, you send an UPDATE for each possible NEXT-HOP in your routing
>> database.
>
>You are talking here strictly about BGP for layer 3 routing. Even in
>this case, a single UPDATE message may contain multiple NLRI
>(destination prefixes) under the condition that they share the same
>attributes (NEXT_HOP, AS_PATH, ...) . 

I think I said that.  

> TBGP uses the MP_REACH_NLRI
>attribute to advertise prefixes. Similar to BGP, the MP_REACH_NLRI
>contains a list of NLRIs which share the same attributes.
>
>The original BGP NEXT_HOP attribute will not be used in call routing.

Right, but the restriction is the same, one next-hop per message.  There is
a list of addr prefixes with each next-hop.  

>
>>From reading the SCSP spec, I thought that in the Cache State Update
>phase no CSA
>Solicit messages are required? Just CSA Request/CSA Reply messages. If a
>CSA Solicit message is required, this makes SCSP's overhead three
>messages per update as compared to BGP's one message per update.
>

The solicit messages are used in recovery and link activation.  When a link
comes up between two peers, the peers exchange summaries of all of their
data.  If they need the full record then they ask for it via a solicit.
Suppose you have the servers A-B-C all synchronized, with A-B being peers,
and B-C being peers.  Then a link is brought up between A and C.  The
servers exchange summaries, realize that they already have all of the
records that the other guy has, and are synchronized without ever
synchronizing the real data.  

When restricted to two peers, the solicit adds an extra message during the
initial synchronization.  Solicits are not used after things are up.  

In steady state (after the peers are synchronized), the local server sends
requests to the peer containing the data, and the peer acknowledges via a
reply.  So the general sequence is information followed by ack.  Data is
not solicited.  

>
>BGP does not provide a mechanism to positively Ack UPDATE messages.
>However the NOTIFICATION message is used to provide a negative Ack in
>response to errors in the contents of, or in the processing of, an
>UPDATE message. This may be looked at as a more efficient mechanism for
>reliability than positive Acks. Since transport reliability is already
>guaranteed by TCP, error Notification usually indicates fatal problems
>with the BGP FSM, and therefore is followed by closing the peer
>connection. I can see situations where, in response to an error in
>processing an UPDATE message, it should be sufficient to send an error
>NOTIFICATION and to ignore that UPDATE, but not closing the entire
>connection. But that's the way BGP works.
>

And if the route process is busy or its queues are full or for some reason
it just can't take the socket upcall from the TCP layer at this time, then
the information is lost.  And that is a problem.  Hence one has to hack the
TCP stack and the OS to ensure this never happens.  

>
>>From discussions with people who implemented IDRP in the past, my
>understanding is that
>it relied on a key for record location, which proved to be "difficult to
>implement with little practical gain."
>

When the "uniqueness" information in a record is an 4-byte IP address, then
a key is useless.  When the uniqueness information is more (ie an IPv6 addr
or an E164 addr), then there is benefit from using a short key.  What is so
difficult to implement about a key?

- Matt

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: "Hussein F. Salama" <[email-masked]>
Date: Fri, 14 May 1999 12:35:56 -0700

Matt Squire wrote:

......

> TCP stack and the OS to ensure this never happens.

I'd appreciate pointers to specific implementations where the OS and the
TCP stack has been hacked. I am not aware of any. Please also check the
the NSFNET backbone (phase II) for BGP implementations on standard OSes
and TCP stacks. And what about the Gated implementation? 

> difficult to implement about a key?

A cache key's benefits will be quite limited, I think. True, it may
simplify the search for an older version of the same record received in
an Update message. However, a routing/call routing protocol does not
just search for older versions of the same record. It also searches for
other existing records having the same destination prefix, in order to
do route selection amongst them. So a prefix-based search is needed
anyways, because this can't be done using the cache key. 

Hussein 

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

---------