Subject: Evaluation of the gateway location proposals

From: "Hussein F. Salama" <[email-masked]>
Date: Tue, 06 Apr 1999 11:31:39 -0700

Iptellers,

The consensus during the Minneapolis IPTEL meeting was that more
detailed comparison of the two gateway location proposals is needed.
Below I am providing an evaluation of the two proposals: GLP/SCSP and
TBGP/BGP.

1. Introduction:
GLP is based on SCSP which is a generic link-state based protocol for
synchronizing the databases of a server group. GLP uses SCSP's message
formats and defines new fields specific for call routing and gateway
location. GLP uses SCSP's transport mechanism only for intra-domain
synchronization of LSs. For inter-domain communication, GLP proposes a
model that's based on BGP. At runtime, GLP defines a server group (the
set of LSs) which uses SCSP for synchronization and update
advertisement, i.e., GLP is a user of SCSP.

TBGP is based on the BGP-4 and its multi-protocol extensions. It uses
BGP's transport mechanism for both inter-domain and intra-domain. TBGP
uses the same message formats defined by BGP, and benefits from the
attributes already defined 
in BGP. In addition, TBGP defines new attributes to serve the specific
goals of call routing and gateway location. With regards to
implementation, BGP and TBGP are completely independent protocols. The
two protocols do not interfere with each other at runtime. A TBGP
speaker (or LS) does not have to be a BGP speaker.

2. Reliability:
GLP runs on a reliable transport, e.g. TCP. In addition, GLP/SCSP uses
request/response transactions.  Responses are not simple Acks. They are
long messages. This significant overhead is needed with intra-domain
link-state protocols to achieve transitive closure and to make sure that
all LSs in a domain have synced up following a routing change. However,
it is still a significant overhead that may be avoided. The
request/response mechanism does not add any benefit for inter-domain
GLP.	

TBGP, on the other hand, relies on TCP for reliability. It uses Update
messages only with no responses. This is sufficient.

3. Inter-Domain Topologies:
Both protocols can support any general topology.

4. Intra-Domain Topologies:
GLP can support any general topology.

TBGP requires either a full mesh configuration or the use of route
reflectors or confederations. It is possible to configure each TBGP
speaker in a domain as a route reflector, and thereby to support any
general topology.	

Questions: 
- What's so bad about route reflectors and confederations? 
- What's the need for supporting a general topology? All that's required
is synchronizing the LSs of the same domain. It doesn't matter how they
interconnected, as long as there sufficient redundancy in the topology.

5. Loop Avoidance:
5.1 Intra-domain Loop Detection: 
GLP detects loops using SCSP's Originator ID and Sequence Number fields.

For TBGP, internal updates are limited to one hop only in case of  a
mesh, therefore there is no danger of loops. With route reflectors,
loops are detected using the Originator_ID and Cluster_List attributes.

5.2 Inter domain Loop Detection:
Nothing defined for GLP yet.

TBGP uses BGP's AS_PATH (or call it AD_PATH) attribute to detect
inter-domain loops.

6. Hold-down Timers and Route Flaps:
GLP/SCSP does not specify any mechanisms for avoiding route flaps.

TBGP leverages BGP's well defined mechanisms for reducing route flaps.
BGP defines two timers: 
- MinRouteAdvertismentInterval (min. time between successive
advertisements of routes to the same destination from the same TBGP
speaker).
- MinASOriginationInterval (min. time between two successive
advertisements of routing changes within the TBGP speaker's own AD).

7. Policy Enforcement:
GLP/SCSP does not specify any mechanisms for enforcing policies on the
routes being advertised.

BGP defines two useful attributes which are leveraged by TBGP:
Multi_Exit_Disc and Local_Pref.

Multi_Exit_Disc is used by an advertising AD with multiple entry points
to indicate to its neighbors which entry point(s) into that domain are
preferred.

Local_Pref is used locally within an AD with multiple exit points to
indicate which exit point(s) towards a certain destination are
preferred.

8. Coping with Aggregation Side Effects:
GLP/SCSP does not specify any mechanisms.

TBGP can leverage two attributes already defined in BGP: Aggregator and
Atomic_Aggregate.

The Aggregator attribute indicates that an advertised prefix is an
aggregate, and includes the number of the aggregating AD and the
aggregating TBGP speaker's IP address.

The Atomic_Aggregate attribute indicates that aggregation has resulted
in loss of information for this prefix and therefore deaggregation is
not appropriate.
 
9. Addressing Formats:
GLP proposes to advertise E.164 ranges. During the meeting, it has been
agreed that E.164 prefixes are more space-efficient.

The multi-protocol extensions for BGP-4 (RFC 2283) have already defined
fields for advertising E.164 prefixes in BGP messages. These extensions
are used by TBGP.

10. Leveraging Existing Attributes:	
Most of BGP-4's fields and attributes can be used by TBGP, as evident
from the above discussion. Still there are some attributes which are of
no use to TBGP. for example the layer 3 NEXT_HOP attribute.

GLP, on the other hand, will have to redefine several of BGP's existing
attributes within the SCSP's message formats. Consider for example, the
policy attributes and aggregation attributes discussed above. Also SCSP
defines several mandatory fields which are redundant or of no use for
GLP. E.g., the Sender ID and Recvr ID are not needed in every Update
messages. The peers already recognize each other. Also the Cache Key
field is not needed since the tables will be indexed by the E.164
prefixes.

TBGP can define its own message formats and remove any useless fields
from the current BGP messages, because BGP and TBGP are separate
protocols. On the other hand, GLP can not remove useless fields from
SCSP messages, because it is just a another user of SCSP.

11. Protocol Phases:	
GLP/SCSP has three phases: Hello, Cache Alignment, and Update. 

TBGP/BGP consists of two phases only: Hello and Update. It uses the same
mechanisms of the update phase for aligning the call routing tables when
a new connection between wo peers is established.

12. Security Consideration:	
Both protocols define optional fields to include authentication data.
Both of them  permit the use of different authentication mechanisms, and
both provide sufficient space to include the 128-bit MD5 digests. 

However, TBGP messages can't carry authentication data larger than 128
bits, while SCSP messages can.

13. Routing Experience:
This is not a feature of the protocol, but I think it is worth repeating
that SCSP was not designed for, and was never used for, inter-domain
routing.

On the other hand, BGP has been specifically designed for inter-domain
routing. It (a) is known to work, (b) is widely deployed in the
Internet, (c) has an extensive operational experience, and (d) known to
scale.

Comments, objections, questions? 

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

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