Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/idr/idr-minutes-95apr.txt

Text File | 1995-05-26 | 11KB | 293 lines

CURRENT_MEETING_REPORT_

Reported by Susan Harris/Merit, Elliot Schwartz/UUNET Canada and
Tony Li/cisco Systems

Minutes of the Inter-Domain Routing Working Group (IDR)



First Session -- Tuesday, 4 April

This first of three IDR sessions was comprised of three presentations:


   o Selective Updates in Inter-Domain Routing
   o A Further Application for RIFs:  De-aggregation in ATM Clouds
   o BGP/IDRP Route Server Proposal


Each is briefly summarized below.


Selective Updates in Inter-Domain Routing

By Kannan Varadhan, USC/ISI (presented by Ramesh Govindan, USC/ISI).

This presentation focused on Routing Information Filters (RIFs), which
make it possible for an entity that participates in inter-domain routing
(either via BGP or IDRP) to specify additional routing information it
wishes to receive from a peer.  RIFs are described in detail in
``Extensions for Selective Updates in Inter Domain Routing,''
draft-ietf-idr-rifs-00.txt, by Yakov Rekhter, Kannan Varadhan, and
Curtis Villamizer.

RIFs can be used to obtain routing information that might otherwise be
lost through aggregation or by the dropping of multiple routes to a
given destination by an intermediate router.  Ideally, the price for
obtaining the information would be paid only by the domain that desires
it.

One solution for obtaining the data might be to query the domain where
the information loss occurred for more detailed information.  However,
this method would incur some cost for the routers where the information
loss occurred.  It addition, both routers must speak a common protocol,
such as BGP or IDRP. RIFs present an ideal way to obtain the
information.  RIFs are based on NLRI (Network Layer Reachability
Information), and not on other route attributes.  RIFs are applicable to
both BGP and IDRP, and work with CIDR.

As described in the draft specification, a RIF is a tuple of the form
<Action, Scope, Base, NLRI>.  Govindan described each component in
detail.  He then outlined methods for carrying RIFs in the BGP/IDRP OPEN
message, the BGP UPDATE message, and the IDRP RIB_REFRESH message.  He
concluded by describing the application of RIFs in ERP (Explicit Routing
Protocol.)


A Further Application for RIFs:  De-aggregation in ATM Clouds

Curtis Villamizer, ANS, began his presentation by enumerating three
factors that affect route scaling problems:  the number of routing
adjacencies, the number of routes (or amount of state required), and the
volume of route change.  He then discussed a typical NSP's view of
Internet routing, and noted that on average there are 2.5 paths per for
each NLRI. He described scaling problems in a full mesh IBGP, and
discussed aggregation problems for single-AS and multiple-AS route
servers.

Villamizer's comments on scaling problems for inbound aggregation of
hosts and outbound aggregation to hosts and routers provoked a lively
discussion among attendees of the problems of defining a mechanism for
cut-through and de-aggregation.  Villamizer strongly recommended that
inbound aggregation of routers should not be performed, since this can
lead to a very large number of adjacencies.

He noted that the following actions should be taken to de-aggregate
using RIFs:


  1. Look up the route and determine the next hop (NH).

  2. If the NH has the ``SameNBMA'' attribute, open a BGP adjacency with
     the aggregator and send a RIF with the destination.  (As defined in
     RFC 1583, NBMA refers to the Non-Broadcast Multi-Access network,
     e.g., X.25, SMDS, Frame Relay, and ATM.)

  3. If a more specific route is returned with ``SameNBMA,'' repeat step
     2.

  4. When the most specific route for the destination no longer has the
     attribute ``Same NBMA,'' stop and use that next hop.


Villamizer also noted that several issues remain for the next version of
the RIF draft.  These include:


   o Host and route actions need to be described in detail.  For
     example, RIF responses should never be readvertised in BGP routes,
     and should not be placed in the Local RIB, only in the FIB.
     The draft would benefit from a clear description of how to
     determine when a next hop can be further refined, what to put in
     the RIF request, the actions taken by an aggregator responding to
     RIFs, and the actions taken when RIF responses arrive.

   o BGP attributes are needed for the originator's media address, to
     identify RIF responses, and to specify missing sets of routes.


BGP/IDRP Route Server Proposal

Dimitry Haskin's proposed Route Server (RS) differs from multi-view RSs,
like those deployed at the NAPs (Network Access Points), in that it does
not perform any route selection, but only relays routing information to
its peers.  Actual route selection and filtering is performed by the
client routers themselves.  The proposed RS emulates full mesh peering.
Individual RSs can be grouped into RS Clusters that share the same
subset of client routers.  A cluster with more than one RS provides
redundancy of routing information to its client routers.


Second Session -- Wednesday, 5 April

Agenda

   o BGP/IDRP Route Server status
   o BGP Communities
   o Routing Confederations
   o AS Guidelines
   o BGP-4 to Full Standard


BGP/IDRP Route Server

Dimitry Haskin's Internet-Draft,
draft-haskin-bgp-idrp-mesh-routing-00.txt, will be submitted as an
Experimental RFC after review by Dennis Ferguson.

This document describes the use and detailed design of Route Servers for
dissemination of routing information among BGP/IDRP speaking routers.

The intention of the proposed technique is to reduce overhead and
management complexity of maintaining numerous direct BGP/IDRP sessions
which otherwise might be required or desired among routers within a
single routing domain as well as among routers in different domains that
are connected to a common switched fabric (e.g., an ATM cloud).


BGP Communities

Paul Traina, cisco Systems, presented an overview of the Internet-Draft,
draft-chandra-bgp-communities-01.txt.

This document describes an extension to BGP which may be used to pass
additional information to both neighboring and remote BGP peers.

The intention of the proposed technique is to aid in policy
administration and reduce the management complexity of maintaining the
Internet.

Cengiz Alaettinoglu/ISI brought up the idea of putting in a provision
for defining intersections and unions of communities (for aggregation
purposes).

Jon Postel agreed that the IANA would take care of registering BGP
attribute numbers.  A list of the currently used ones needs to be sent
to him.

Andrew Partan asked about methods of grouping communities.  Paul said
there could be a way to delete or modify a range of communities.

There was a discussion on what to do with the Internet-Draft.  Dimitry
said Bay Networks could implement this attribute.  It will be moved to
an Experimental RFC after being reviewed by Dennis.



Routing Confederations


Paul Traina presented an overview of the Internet-Draft,
draft-traina-bgp-confed-02.txt.

This document describes an extension to BGP which may be used to create
a confederation of autonomous systems which is represented as one single
autonomous system to BGP peers external to the confederation.

The intention of the proposed technique is to aid in policy
administration and reduce the management complexity of maintaining a
large autonomous system.

Yakov Rekhter asked if the internal AS numbers should come out of a
private address space, similar to IP addresses under RFC 1597.
Consensus was that this is a good idea.

Vadim Antonov mentioned confederations would help in identifying who
uses what AS numbers (i.e., a network provider would appear to be one AS
externally).  He said that Sprint uses something like this in
production, and that it helps with routing convergence since next hops
are consistent.

It was noted that the current cisco implementation requires that all the
routers in a confederation be aware of this.  This could be fixed.

Paul will do more research before this Internet-Draft is submitted as
Experimental.



AS Guidelines

John Hawkinson provided a brief recap of the Internet-Draft,
draft-ietf-idr-autosys-guide-02.txt, and discussion to date.

Peter Lothberg agreed with the aim of the paper in general, but was
unhappy with how it had been used by the RIPE NCC. He spoke about a
specific case in which an AS number was refused (based on the content of
the paper), where he considered it legitimate.

A discussion about Peter's case, the role of registries, and the
possibility of AS number exhaustion occurred.  Most people felt that the
registries should use this document in assignment.

The creation of a private AS number space for use in confederations was
discussed.  It was suggested that we ask the IANA to set aside the top
1K AS numbers for this, and reserve the top 8K in case.  The exact
numbers will be discussed off-line and reported to the IANA.

It was suggested that transit providers should probably filter these by
default (like IP numbers under RFC 1597).

Consensus was to send this Internet-Draft to the IESG for consideration
as a Proposed Standard, as soon as final editing was done.


BGP-4 to Full Standard

The whole Internet runs BGP-4, and there are multiple interoperable
implementations.  The document was a Draft Standard at the last meeting.

Paul will update the experience document.  If there are any new
implementations (besides those mentioned in the document), people should
send e-mail to Paul.

Editorial changes should be sent to Tony Li and Yakov Rekhter.

There is a need to clarify (a) handling of unrecognized optional
parameters in the OPEN message.  There is also a need to add text on
suppressing routing information looping.

There was consensus that BGP-4 should be a Full Standard by the next
IETF.


Third Session -- Thursday, 6 April

Agenda

   o IDRP for IPv4 and IPv6
      -  Performance related attributes for IDRP
      -  BGP AS Path Metrics


IDRP for IPv4 and IPv6 -- Paul Traina

   o Add parameters to open and refresh message so that they are
     extensible.
   o Parameters use standard IDRP TLV layout.
   o Add support for QOS attribute, residual error attribute,
     transmit-delay attribute.
   o No support for distinguishing attribute.
   o Support for IPv4 transport.
   o IPv4 prefixes or AS numbers may be RDIs.
   o Need to add soft notifications.


Performance Related Metrics in IDRP -- Paul Traina

   o Add global notions of bandwidth and delay to updates.
   o Simplifies global optimization.
   o Cannot easily use true capacity due to load fluctuations and route
     flap.


BGP AS Path Metrics -- Tony Li

   o AS path metrics.
   o There was a concern that this would increase flapping due to the
     dynamic nature of the metric.  Limit propagation of change to the
     dynamic part.