Drafts of interest to ROLC

Curtis Villamizar <curtis@ans.net> Tue, 21 February 1995 03:58 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12822; 20 Feb 95 22:58 EST
Received: from acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa12818; 20 Feb 95 22:58 EST
Received: from curtis.ansremote.com (curtis.ansremote.com [152.161.2.3]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id WAA27962 for <rolc@maelstrom.acton.timeplex.com>; Mon, 20 Feb 1995 22:32:37 -0500
Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id WAA01939; Mon, 20 Feb 1995 22:31:05 -0500
Message-Id: <199502210331.WAA01939@curtis.ansremote.com>
To: rolc@maelstrom.acton.timeplex.com
cc: curtis@ans.net
Reply-To: curtis@ans.net
Subject: Drafts of interest to ROLC
Date: Mon, 20 Feb 1995 22:30:16 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Curtis Villamizar <curtis@ans.net>


The following entries are from the 1id-abstracts file.

The IDR WG is considering the following draft:

  "Extensions for Selective Updates in Inter Domain Routing", Y. Rekhter,
  K. Varadhan, C. Villamizar,, 02/16/1995, <draft-ietf-idr-rifs-00.txt>

    Under certain circumstances[4, 5] it is desirable for an entity that
    participates in inter-domain routing (either via BGP or IDRP) to
    specify the routing information it wishes to receive from its peer.
    This document proposes a mechanism that provides this functionality.
    Unless stated otherwise, for the rest of the document we do not
    distinguish between a BGP and an IDRP speaker.

Some of the functionality defined in RIFs can be used to reduce the
routing information that a host or stubby router needs to hold, while
still supporting the ability to deaggregate.  RIFs are also being
considered in support of the ERP routing protocol.

  "Inter-Domain Routing over ATM networks", Y. Rekhter, C. Villamizar,
  02/16/1995, <draft-rekhter-idr-over-atm-00.txt>

    Consider an ATM network and a set of IP routers connected to it. The
    set of routers is under control of different organizations, so that
    some of the routers participate in intra-domain routing protocol(s) of
    each organization, and some routers exchange routing information across
    organizational boundaries (by participating in inter-domain routing).
    We refer to to latter as "exterior" routers.  Moreover, we assume that
    the inter-domain routing protocols supported by these routers are
    either BGP-4 [BGP-4] or IDRP (for IP or IPv6) [IDRP].

The above informational draft describes means of using the existing
BGP and IDRP routing protocols, mostly as is, to do routing over large
clouds in which many stations on the large cloud (ATM in the draft)
are routers which support multihomed destinations off the large cloud.
Some of the extensions, such as multiview server and RIFs are already
being undertaken by the RA and will appear in gated.  A simple
attribute is described which can be used to determine if an attempt
should be made to deaggregate a route.

Comments are welcome.

Curtis