RFC 1863

A BGP/IDRP Route Server alternative to a full mesh routing

📅 published October 1995, from ietf

RFC 1863: A BGP/IDRP Route Server alternative to a full mesh routing ✨

Okay bestie, this is RFC 1863 💖 It was written by D. Haskin from Bay Networks, Inc. in October 1995, and it's filed as Experimental 🧪. The header doesn't list anything it obsoletes or updates, so it's just vibing solo 🌸

Status of This Memo 📜

This memo defines an Experimental Protocol for the Internet community 🧪. It does not specify an Internet standard of any kind, so no official stamp of approval here 🙈. Discussion and suggestions for improvement are requested, so bring your ideas 💬. Distribution of this memo is unlimited 🌈.

Abstract 🦋

This doc is all about Route Servers and how they help BGP/IDRP speaking routers pass routing info around 🧚

The goal is to cut down the overhead and management complexity of keeping up tons of direct BGP/IDRP sessions. Those sessions might otherwise be needed or wanted between routers inside a single routing domain, and also between routers in different domains that hang out on a common switched fabric (like an ATM cloud ☁️). 🫶

1. Overview 💅

Okay so current deployments of exterior routing protocols, like the Border Gateway Protocol [BGP4] and the adaptation of the ISO Inter-Domain Routing Protocol [IDRP], require that every BGP/IDRP router doing inter-domain routing (border routers) in the same routing domain sets up a full mesh connection with every other one 😭. That's so they can share the routing info they picked up from other routing domains. In big routing domains, the number of intra-domain connections each border router has to keep up can get seriously big 💀

Also, a border router might want routing sessions with all the border routers in other domains that can be reached over a shared communication media. Routers that are directly reachable over a shared media are called adjacent routers 🧚 Direct peering like this lets a router learn "first hand" info about destinations directly reachable through adjacent routers, so it can pick the optimum direct paths to them ✨. If every adjacent border router set up BGP/IDRP sessions with each other, you'd end up with full mesh routing connectivity. Unfortunately, for a switched media like ATM, SMDS or Frame Relay, which can inter-connect a large number of routers, the number of connections needed to keep a full mesh of direct peering going makes this approach impractical 😵‍💫

To solve the "full mesh" problem, this paper proposes using IDRP/BGP Route Servers 💖 They relay external routes, with all of their attributes, between client routers. Clients only keep IDRP/BGP sessions with their assigned route servers (sessions with more than one server are needed if you want redundancy 🛡️). Every route received from a client gets propagated to the other clients by the Route Server. Since all external routes and their attributes are relayed unmodified, clients end up with the same routing info they'd get from direct peering. This setup is called virtual peering 🦋 It lets client routers apply selection criteria to the acquired external routes according to their local policies, just like they would with a direct peering 👑

The routing approach in this paper assumes that border routers possess a mechanism to resolve the media access address of the next hop router for any route acquired from a virtual peer 🔍

To be fair, this approach only reduces the number of routing connections each border router needs to maintain. It doesn't reduce the volume of routing info that needs to be maintained at each border router 🤷‍♀️

Besides addressing the "full mesh" problems, the proposal is aiming for these goals:

  • to minimize BGP/IDRP changes that need to be implemented in client routers in order to inter-operate with route servers; 🔧
  • to provide for redundancy of distribution of routing information to route server clients; 🛡️
  • to minimize the amount of routing updates that have to be sent to route server clients; 📦
  • to provide load distribution between route servers; ⚖️
  • to avoid an excessive complexity of the interactions between Route Servers themselves. 🧘‍♀️

2. Terms And Acronyms 📖

Here's the glossary for the terms and acronyms used in this paper 📖

  Routing Domain     -  a collection of routers with the same set of
                        routing policies.  For IPv4 it can be identified
                        with an Autonomous System Number, for IPv6
                        it can be identified with a Routing Domain
                        Identifier.

  Border Router (BR) -  a router that acquires external routes, i.e.
                        routes to internet points outside its routing
                        domain.

  Route Server (RS)  -  a process that collects routing information
                        from border routers and distributes this
                        information to 'client routers'.

  RS Client (RC)     -  a router than peers with an RS in order to
                        acquire routing information.  A server's client
                        can be a router or another route server.

  RS Cluster (RSC)   -  two or more of route servers that share the same
                        subset of clients.  A RS Cluster provides
                        redundancy of routing information to its
                        clients,  i.e. routing information is provided
                        to all RS Cluster clients as long as there is
                        at least one functional route server in the RS
                        Cluster.

  RCID             -    Cluster ID

3. RS Model 🧩

In this scheme, a Route Server (RS) doesn't apply any selection criteria to the routes it gets from border routers when distributing them to its clients 💅 All routes acquired from border routers or other Route Servers get relayed to the client border routers ✨

There can be two classes of Route Servers 🎀: ones that relay external routes between routers in a single routing domain, and ones that relay external routes between border routers in different routing domains. The former are Intra-Domain Route Servers and the latter are Inter-Domain Route Servers 🫶

In the RS model proposed here, there's no routing exchange between Intra-Domain Route Servers and Inter-Domain Route Servers 🙅‍♀️ Routes that cross a domain boundary must always pass through a border router of that domain, and that border router may apply administrative filters to those routes 🚧

Intra-Domain Route Servers and Inter-Domain Route Servers operate identically 👯

One or more Route Servers form an RS Cluster (RSC) 🧁 For redundancy's sake, two or more RSs can be configured to operate in an RS Cluster 🛡️ All route servers in an RSC share the same clients, so cluster clients establish connections to all route servers in that RSC to exchange routing info 🤝 Each cluster is assigned a unique RSC Identifier (RCID), represented by a 2-octet unsigned integer 🔢

Clusters that provide virtual connectivity between their clients will normally be exchanging routing info among themselves, so that all external routes get propagated to all participating clients 🌐

Though a Route Server Client (RC) can be associated with multiple RSCs, it seems there's no real advantage to doing that, except for a short transition period for a graceful re-assignment from one RSC to another. Or, if for some reason, there are multiple RS groups that don't exchange routing info with each other 🙃

Inter-cluster route exchange can be done by forming a full mesh routing adjacency between clusters 🕸️ In this approach, shown in the diagram below 👇, each RS in each RSC maintains a routing connection with every RS in other RS clusters. Only routes acquired from border routers are propagated to RSs in other RS clusters 💫

         BR11   BR12   BR1n     BR21  BR22  BR2n
           |     |  ... |        |     | ...  |
          -----------------     ------------------
          !  RS11  RS12   ! --- !  RS21    RS22  !
          -----------------     ------------------
               <RSC#1>  \           /    <RSC#2>
                         \         /
                       -----------------
                       !  RS31  RS32   !   <RSC#3>
                       -----------------
                         |     | ... |
                        BR31  BR32  BR3n

Another way to propagate routing info between clusters is a cluster hierarchy 🌳, where an RS in one cluster maintains sessions only with RSs in designated clusters. In this approach, an RS must advertise all acquired routes to an RS in another cluster, except the routes it acquired from that cluster. It allows for minimizing the number of routing sessions, which can be highly desirable in some networks ✨ For the hierarchical scheme, it's important that the inter-cluster route exchange links form a tree, meaning there's only one route propagation path between any two clusters. Otherwise, routing loops may result 😱 For detection and pruning of routing loops in a hierarchical cluster topology, it's advisable to include the "RCID Path" attribute (see 4.3.4) in all routing updates sent between route servers 🔁 This attribute lists IDs of all clusters in the route propagation path. When a duplicate ID is detected in this attribute, the offending route needs to be discarded 🗑️

The diagram below illustrates the hierarchical approach. It's made from the diagram above by removing the route exchange link between clusters 2 and 3 ✂️

         BR11   BR12   BR1n     BR21  BR22  BR2n
           |     |  ... |        |     | ...  |
          -----------------     ------------------
          !  RS11  RS12   ! --- !  RS21    RS22  !
          -----------------     ------------------
               <RSC#1>  \                <RSC#2>
                         \
                       -----------------
                       !  RS31  RS32   !   <RSC#3>
                       -----------------
                         |     | ... |
                        BR31  BR32  BR3n

The only real downside of the hierarchical model seems to be the management headache of avoiding routing loops and redundant information flow, by making sure inter-cluster links always form a tree 🤯 But more study is needed to fully evaluate the comparative merits of the full-mesh and hierarchical models 📚

Since RSs in the same cluster maintain routing sessions with the same set of clients, it might seem there's no need to exchange routing info between RSs in the same cluster 🤔 But such a route exchange may help keep routing databases identical in the servers during client acquisition periods, and when a partial failure may affect some routing sessions 🧠

Route servers in the same RS cluster exchange control messages, trying to subdivide the job of providing routing info to their clients 🤝 To keep the RS design simple, the RS messaging is implemented on top of the exterior protocol that route servers use for the routing information exchange 💡

4. Operation ✨

4.1. ADVERTISER Path Attribute ✨

okay bestie, route servers are basically the concentrators 💅 for routes that border routers pick up. So border routers only have to keep routing connections with one or two designated route servers 🫶. Then the route servers pass that routing info along to ALL their clients 🌈

but here's the drama 😭 if routes got relayed in UPDATE messages with only the path attributes that are currently defined in the BGP-4/IDRP spec, the RS clients would NOT be able to link the external routes they get back to the border routers that submitted them. And that link is kinda necessary for making a correct route selection decision 🙈 so the new path attribute, ADVERTISER, gets defined. iconic 👑

The ADVERTISER is an optional non-transitive attribute. It tells you the identifying address of the border router that originally submitted the route to a route server so it can be relayed to other RS clients 🦋 Its Type Code is 255. This attribute must be included in every UPDATE message that is relayed by route servers, and it must be recognized by RS clients. no skipping this one 💖

4.2. Route Client Operation 🎀

an RS client sets up a BGP/IDRP connection to every route server in the RS cluster it's assigned to 🧚

RS clients must be able to recognize the ADVERTISER path attribute that's included in all UPDATE messages received from route servers ✨ Routes that come in UPDATE messages from route servers get processed as if they came straight from the border routers named in the ADVERTISER attributes of those updates. main character energy 💅

if an RS client gets a route from an Intra-Domain Route Server, it is assumed that the border router named in the ADVERTISER attribute is located in the client's own routing domain 🏠

if an RS client gets a route from an Inter-Domain Route Server, the locality of that border router can be figured out from the BGP's AS_PATH attribute or IDRP's RD_PATH attribute, respectively 🗺️

if an UPDATE message from a route server doesn't include an ADVERTISER attribute, the route server itself is assumed to be the advertiser of that route 🫶

if the NEXT_HOP path attribute of an UPDATE message lists the address of the receiving router itself, the route carried in that update must be declared unreachable 💀 (yes, that's a real rule, not a vibe)

also, it's highly desirable, albeit not required, to slightly modify the "standard" BGP/IDRP operation when acquiring routes from RSs 🍓 here's the tweak:

when a route is received from an RS and a route with completely identical attributes has previously been acquired from another RS in the same cluster, the previously acquired route should be replaced with the newly acquired route. that replacement should not trigger any route advertisement action on behalf of the route. ✨

RSs are built so that RS clients don't need to keep multiple copies of the same route, and so that a route flap is less likely when the BGP/IDRP connection to one of the redundant route servers goes down 🦋

the goal is to split the route dissemination load between route servers so that only one RS provides routing updates to a given client. BUT the reconciliation algorithm doesn't completely eliminate the possibility of races (it would get way too complex 😭), so a client may still receive updates from more than one route server. That's where the client's ability to discard duplicate routes comes in, because it can cut down on how big a routing database it needs 🌸

4.3. Route Server Operation 👑

a Route Server keeps BGP-4/IDRP sessions with its clients according to the respective BGP-4/IDRP specification, except for the protocol modifications outlined in this document 💖

UPDATE messages sent by route servers have the same format and semantics as their BGP-4/IDRP counterparts. The difference is that they also carry the ADVERTISER path attribute, which specifies the BGP Identifier of the border router that submitted the route advertised in that UPDATE message 🫶 Also, if the hierarchical model is used to interconnect Route Server clusters, it is advisable to include the "RCID Path" attribute in all routing updates sent between route servers, as described in 4.3.4 ✨

when route servers exchange OPEN messages, they include the Route Server protocol version (the current version is 1) and the Cluster IDs of their respective clusters in an Optional Parameter of the OPEN message 🧚 The Parameter Type for this parameter is 255. The parameter data is 3 octets long, laid out like this:

+-----------------------+------------------------------------+
| Version = 1 (1 octet) |      Cluster ID (2 octets)         |
+-----------------------+------------------------------------+

route servers in the same cluster also send each other LIST messages with lists of the clients they're giving routing info to 📝 In a LIST message, an RS specifies the Router Identifier of each client it's providing routing updates to. LIST messages are pretty small, so there's no need to add the complexity of generating incremental updates when a list changes. Instead, the complete list gets sent whenever RSs need to hear about the changes 🌈 The LIST message format is in 4.3.1.

4.3.1. LIST Message Format 🍓

the LIST message starts with the fixed BGP/IDRP header, followed by the fields shown below. The type code in the fixed header of a LIST message is 255 🦋

  +----------+----------+----------+----------+
  |        Client Identifying Address         | Repeated for each
  +-------------------------------------------+ informed client

the number of "Client Identifying Address" fields isn't encoded explicitly, but you can calculate it like this 🧮

     (<LIST message Length> - <Header Length>) / <Address Length>,

where <LIST message Length> is the value encoded in the fixed BGP/IDRP header, <Header Length> is the length of that header, and <Address Length> is 4 for IPv4 and 16 for IPv6 💜

4.3.2. External Route Acquisition And Advertisement 💅

a route server acquires external routes from RS clients that are also border routers. An RS may also acquire external routes from other RSs. Route servers relay all acquired routes unaltered to their clients. No route selection is performed for the purpose of route re-advertisement to RS clients ✨

while route servers receive and store routing data from all their clients, Routing Servers in the same cluster coordinate their route advertisement so that only one RS provides routing updates to a given client 🫶 If an RS fails, the other Route Servers in the cluster take over providing routing updates to the clients that the failed RS used to serve. A route flap that can come from this switch-over can be avoided by configuring the client's "Hold Time" for its BGP-4/IDRP sessions with the route servers to be larger than the switch-over time 🕰️ The switch-over time is determined by the Hold Time of the BGP-4/IDRP sessions between the route servers in the cluster, plus the period those route servers need to reconcile their route advertisement responsibilities. The reconciliation protocol is described in 4.3.3 💖

the BGP-4/IDRP operations of route servers differ from the "standard" operation in the following ways 👑

  • when receiving routes from another RS, the RS Client mode of operation is assumed. That means when a route with completely identical attributes has previously been acquired from an RS in the same cluster as the RS advertising the new route, the previously acquired route should be discarded and the newly acquired route should be accepted. Such a route replacement should not trigger any route advertisement action on behalf of the route.
  • all acquired routes are advertised to a client router EXCEPT routes that were acquired from that client (no route echoing 🙅‍♀️)
  • if the hierarchical model of inter-cluster route exchange is used, all acquired routes are advertised to an RS in another RSC EXCEPT routes that are acquired from that RSC. In the full-mesh model, only routes acquired from border routers are advertised to route servers in other clusters.
  • if route servers in the same RS cluster are configured to exchange routing information, only external routes acquired from border routers are advertised to route servers in the local cluster.
  • the ADVERTISER path attribute is included in every UPDATE message generated by an RS. This attribute must specify the identifying address of the border router from which the information in the UPDATE was acquired. All other routing attributes should be relayed to the RS's peers unaltered.
  • when a route advertised to an RS by a client becomes unreachable, that route needs to be declared unreachable to all other clients. To withdraw a route, the route server sends an UPDATE for that route to each client (except the client the route was originally acquired from), with the NEXT_HOP path attribute set to the address of the client that this UPDATE is sent to. The ADVERTISER path attribute, with the identifying address of the border router that originally advertised the withdrawn route, must also be included in such an update message.
  • if the hierarchical model is deployed to interconnect Route Server clusters, it is advisable to include the RCID_PATH attribute in all routing updates sent between route servers, as described in 4.3.4. The RCID_PATH attribute is never included in UPDATE messages sent to border routers.

4.3.3. Intra-Cluster Coordination 🧚

to coordinate route advertisement activities, route servers that are members of the same RS cluster establish and maintain BGP/IDRP connections between themselves, forming a full-mesh connectivity 🕸️ Normally, there's no need for more than two-three route servers in one cluster.

route servers belonging to the same cluster send each other LIST messages with lists of the clients they're providing routing information to. Let's call those clients "informed clients" 🫶

each RS maintains a separate "informed client" list for each RS in the local cluster, including itself 📋 All these lists are linked in ascending order, determined by the number of clients in each list. The order among lists with the same number of clients is determined by comparing the identifying addresses of the corresponding RSs. An RS in such a "same number of clients" subset is positioned after all the RSs with the lower address 🌸

an RS can be in one of two RS coordination states: 'Initiation' and 'Active' 💖

4.3.3.1 Initiation State 🌱

Okay bestie, this is the very first state a route server is in, the moment it boots up 🌱. As soon as it enters Initiation, the 'InitiationTimer' starts ticking ⏰. The RS moves to Active when that timer runs out, or as soon as every configured BGP/IDRP connection to the other route servers in the local RS Cluster is established and their LIST messages have arrived. Either way, it's giving glow-up 💅

While it's in Initiation, an RS:

  • tries to establish connections with other RSs in the local and remote clusters.
  • accepts BGP/IDRP connections from client routers.
  • receives and processes BGP/IDRP updates, but doesn't send any routing updates 🤫
  • stores "informed client" lists received from other RSs in the local cluster. A newly received list replaces the existing list for the same RS. If a LIST message is received from the route server in another RS cluster, it SHOULD be silently ignored.
  • initializes an empty "informed client" list for its own clients.
  • as soon as a BGP/IDRP connection to an RS in the same RS Cluster is established, transmits an empty LIST message to such an RS.

4.3.3.2 Active State 🚀

This state kicks in when the 'InitiationTimer' expires, or when all configured BGP/IDRP connections to other route servers in the local RS Cluster are established and their LIST messages have been received. Now we're live 🚀

In the Active state, an RS:

  • continues attempts to establish connections with other route servers in the local and remote clusters;
  • accepts new BGP/IDRP connections;
  • transmits a LIST message to an RS in the local cluster as soon as a BGP/IDRP session with the RS is established, and then whenever the local "informed client" list changes;
  • receives and processes BGP/IDRP updates;
  • receives and processes "informed client" lists as described below:
    • a) If a LIST message is received from the route server in another RS cluster, it SHOULD be silently ignored.
    • b) If a LIST message is received from a route server that belongs to the same RS Cluster, the differences between the old and the new list are determined, and the old "informed client" list for that RS is replaced by the list from the new message. For each client that was in the old list but not in the new list, it is checked whether the server has an established BGP/IDRP connection to that client and the client is not in any of the other "informed client" lists. If both conditions are met, the processing described for a new client takes place (see 4.3.3.3).
  • for each new BGP/IDRP client (including connections established in Initiation state), decides if that client SHOULD become an "informed client", i.e. whether routing updates are to be sent to the client, or whether that client has already been taken care of by another RS in the local cluster. The decision process is described in the next section.

4.3.3.3 New Client Processing 🧩

Whenever an RS acquires a new BGP/IDRP peer, it scans through all "informed client" lists to figure out if this peer is already getting routing updates from another RS in the local RS cluster. If the identifying address of the peer is found in one of the lists, no routing updates are sent to that peer.

If the peer's Router Id is not found, the route server starts a 'DelayTimer' for that peer and postpones the decision until that timer expires. The delay value is calculated as follows: the RS determines the relative position of its own "informed client" list in the linked list of all "informed client" lists. If that position is expressed as a number, say N, in the 1 to "maximum number of lists" range, then the delay value is set to (N-1)*<DelayGranularity>.

Once the 'DelayTimer' expires, the "informed client" lists are scanned once again to see if the peer is already receiving routing updates from another RS in the local RS cluster. If the Router ID of the peer is found in one of the lists as a result of receiving a new LIST message, no routing updates are sent to that peer. Otherwise, the peer's Router ID is entered in the "informed client" list that belongs to the RS, the transmission of the updated LIST message is immediately scheduled, and routing updates are sent to the client.

The rationale for the delay is to minimize races over which RS among the route servers in the same RSC is going to provide routing information to a given client. The RS with the fewest "informed clients" gets the shortest delay and is the most probable to win the race. This helps to equalize the number of "informed clients" between RSs in a cluster 🤝.

After a BGP/IDRP peer is placed in the "informed client" list, it is only removed from the list when the BGP/IDRP connection to this peer is lost. While a client is in the list, it is accurately updated with all routing changes 📬.

4.3.3.5 Inter-RS Connection Failure 💥

If a route server loses a routing session with a route server in the same cluster, it MUST consider taking over the responsibilities of route advertisement to the clients that are in the "informed client" list of the remote route server of the failed session.

For each such client, it is checked whether the server has an established BGP/IDRP connection to that client and the client is not in any of the "informed client" lists of active RS. If both conditions are true, the processing described for a new client takes place (see 4.3.3.3).

After advertisement responsibilities are reconciled, the "informed client" list associated with the failed session SHOULD be discarded.

4.3.4 RCID_PATH Attribute 🪪

The RCID_PATH is an OPTIONAL non-transitive attribute made up of a sequence of RS Cluster Identifiers (RCID). It identifies the RS Cluster that the routing information carried in the UPDATE message has passed through. Its Type Code is 254. The attribute value field holds one or more RS Cluster Identifiers, each encoded as a 2-octets long field.

When a route server propagates a route that was learned from another Route Server's UPDATE message, the following happens with respect to the RCID_PATH attribute:

  • if the destination of the route is not a route server, the RCID_PATH Attribute is excluded from the UPDATE message sent to that client.
  • if the destination of the route is another route server that is located in the advertising server's own RS cluster, the RCID_PATH attribute is sent unmodified.
  • if the destination of the route is a route server in a different RS cluster, the advertising route server SHALL verify that the RCID of the destination speaker's cluster is not present in the RCID_PATH attribute associated with the route. If it is present, the route SHALL NOT be advertised, and an event indicating that a route loop was detected SHOULD be logged. Otherwise, the advertising router SHALL prepend its own RCID to the RCID sequence in the RCID_PATH attribute (put it in the leftmost position).

When a route server propagates a route that was learned from a border router to another route server, then:

  • if the destination of the route is a route server that is located in the advertising router's own RS cluster, an empty RCID_PATH attribute SHALL be included in the UPDATE message (an empty RCID_PATH attribute is one whose length field contains the value zero).
  • if the destination of the route is a route server in a different RS cluster, the advertising route server SHALL include its own RCID in the RCID_PATH attribute. In this case, the RCID of the advertising route server will be the only entry in the RCID_PATH attribute.

4.3.5 NOTIFICATION Error Codes 🚨

In addition to the error codes defined in the BGP-4/IDRP specification, the following error can be indicated in a NOTIFICATION message that is sent by a route server:

255  LIST Message Error

The following error subcodes can be associated with the LIST Message Error:

1  - Bad Address.  This subcode indicates that a Client Identifying
     Address in the received LIST message does not represent
     a valid network layer address of a router interface.

The following additional UPDATE error subcodes are also defined:

255 - Invalid ADVERTISER Attribute.  This subcode indicates that
      a value of the ADVERTISER Attribute does not represent
      a valid network layer address of a router interface.

4.3.7 Timers ⏱

The 'InitiationTimer' value of 5 minutes is suggested.

To avoid route flaps during an RS switch-over, a value of DelayGranularity SHOULD be such that the maximum possible value of the 'DelayTimer' (see 4.3.3.3) combined with the Hold Time of inter-RS connections would be shorter than two-thirds of the smallest Hold Time interval of all BGP/IDRP connections between the route servers and their clients (including RSs in other clusters). So in a cluster with three RSs and the respective Hold Times of 30 and 90 seconds, the DelayGranularity of 15 seconds would be a RECOMMENDED value.

For the same reason, it is RECOMMENDED that the Hold Time of BGP/IDRP connections between route servers in the same cluster is set to one-third of the smallest Hold Time of all BGP/IDRP connections between the route servers and their clients (including RSs in other clusters). So, if the smallest Hold Time of BGP/IDRP sessions with clients is 90 seconds, the RECOMMENDED value of the Hold Time of BGP/IDRP connections between route servers in that cluster would be 30 seconds.

5. Route Server Discovery 🔍

This document does not propose any mechanism for the dynamic RS discovery by RS clients or/and by other route servers. It is assumed that at minimum a manual configuration will be provided in participating routers to achieve the needed connectivity 🛠️.

7. Security Considerations 🔐

Security issues are not discussed in this document. Full stop 💀

8. Acknowledgment 🙏

Some design concepts presented in this paper benefited from discussions with Tony Li (cisco Systems).

Author likes to thank John Krawczyk (Bay Networks) and Susan Harris (Merit) for their review and valuable comments.

Also, author would like to thank Yakov Rekhter (IBM) for the review of the earlier version of this document and constructive comments.

Special thanks to Ray Chang (Bay Networks) whose experience in implementing the concepts presented in this document helped to refine the route server design ✨.

9. References 📚

  • [BGP4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems, March 1995.
  • [IDRP] Rekhter, Y., and P. Traina, "IDRP for IPv6", Work In Progress.

10. Author's Address 💌

Dimitry Haskin
Bay Networks, Inc.
2 Federal Street
Billerica, MA 01821

EMail: dhaskin@baynetworks.com

That's the whole RFC, bestie! 🌈💖

📦 where this page comes from