CURRENT_MEETING_REPORT_
Reported by Dave Katz/cisco Systems
Minutes of the joint session of BGP and IPIDRP Working Groups
Call to Order
Susan Hares, Chair of the OSI IDRP for IP Over IP Working Group
(IPIDRP), and Yakov Rekhter, Chair of the Border Gateway Protocol
Working Group (BGP), called the meeting to order.
Dave Katz agreed to act as recording secretary.
The following agenda was presented:
o BGP4 progression to Proposed Standard
o BGP4 MIB progression to Proposed Standard
o BGP/IDRP policy MIB
o BGP/IDRP over X.25
o IDRP status
o IDRP for IP next step
o IDRP for IPng
BGP4 Progression to Proposed Standard
Yakov described the requirements for progressing a document to Proposed
Standard status. One of these requirements is a report to the Routing
Area Director describing, among other things, implementation experience.
Yakov solicited an implementor to write this report and Paul Traina
graciously volunteered.
BGP4 MIB Progression to Proposed Standard
Yakov reported that no comments were received on the Internet-Draft MIB,
and that no implementations are currently known, although it is reported
that several implementations are underway. Once implementations appear,
the required report will be written, and the document will be progressed
at that point.
BGP/IDRP Policy MIB
John Krawczyk was asked by Yakov shortly before the meeting to report on
Wellfleet's implementation of BGP policy control via SNMP. John
described the following elements of Wellfleet's proprietary policy MIB:
o AS Weights Table
A one-to-one mapping between AS numbers and "weights" (or
infinity). The weight is calculated over the path to the AS, and
the path with the smallest weight is used. This is currently
implemented for BGP3.
o Import Filter
Combinations of the network number, originating AS number, peer IP
address, and origin attribute are matched to incoming routes.
Possible actions are to ignore the route, or assign a route
preference. Default is to ignore routes.
o Export Filter
Combinations of network number, source protocol, outbound peer AS,
peer IP address, OSPF type, and OSPF tag (the tags can be
automatically generated). Possible actions are whether or not to
propagate, set the inter-AS metric (currently hardcoded but could
potentially be synthesized from the IGP path cost), set the origin
attribute, and assign an AS number (if the origin is set to EGP).
A discussion ensued about the practicality of standardizing a policy
MIB. There is a tension between trying to provide a mechanism by which a
router can be completely configured using SNMP, and the fact that policy
mechanisms are product differentiation features that are likely to
differ from vendor to vendor. A standardized MIB would be an advantage
operationally, but it is likely to be difficult to describe a canonical
MIB that would reflect the breadth of functionality available in all
implementations. One possibility would be to define a standard
canonical subset of functionality and then use proprietary MIB branches
for features unique to particular implementations.
As there are very few policy MIB implementations at this point in time,
it was agreed to table this topic until more implementations are
available, at which time the issue will be revisited.
BGP/IDRP over X.25
Gerry Meyer described a scheme for use of BGP over tariffed switched
circuits, including X.25. There is a general problem with protocols
that send periodic messages, in that they tend to hold switched circuits
open forever, and generate lots of (potentially costly) traffic. They
also may require full mesh connectivity, which requires many circuits.
An Internet-Draft has been published that describes a mechanism for
running RIP in such environments. Gerry described an adaptation of this
mechanism to BGP:
o Most behavior would be similar to current practice:
- Exchange of messages to open and confirm connection parameters
- Initial data flow of entire BGP table
- Incremental updates sent as the routing table changes
- Use of TCP to provide reliable delivery
o Some things would need to change:
- No periodic keepalives
- Holding timer would not normally be running
- On sending an update:
* Start holding timer
* Poll TCP to see if data got through
* Cancel holding timer if data got through
* Follow current practice if holding timer expires (tear down
BGP connection)
- Use of "circuit down" indication from circuit manager:
* BGP would start holding timer and follow normal behavior on
timer expiration
* TCP connection should be notified to not attempt to send
Circuit manager attempts to reestablish connection
- Use of "circuit up" indication from circuit manager:
* If holding timer still running (temporary glitch), holding
timer is cancelled
* TCP would forward queued data
* If holding timer expired (longer term problem), equivalent
to starting from scratch
Susan pointed out that a similar scheme for IDRP has been published by
the Aeronautical Telecommunications Network forum.
A discussion ensued about how this type of functionality could be
accomplished with minimal changes to BGP itself. It was decided that
the only necessary functional change to the BGP protocol would be to
specify that a negotiated holding timer value of zero would indicate
that periodic keepalive packets are not in use. Other functionality
would be part of a connection manager which would not be specified by
the BGP Working Group, although the functionality expected by BGP would
be. Gerry agreed to modify the BGP usage document to specify the
expected connection manager functionality. Yakov agreed to make the
holding time modification to the BGP4 document.
BGP Working Group Status
Tony Li moved that the BGP Working Group status be changed to
``hiatus.'' Yakov pointed out that this does not mean that the group is
disbanding, but rather that it will lie dormant until it is necessary to
resurrect it (in particular, to advance documents through the standards
track). The group agreed by consensus.
IDRP Standard Status
Dave Katz reported that the IDRP specification, ISO 10747, had passed
the DIS ballot and the document editor had accommodated all ballot
comments. The final IS text was sent to the ISO Secretariat in Geneva
this week, and ISO will formally ratify the document during the next ISO
SC6 meeting in Seoul, South Korea in October.
It was announced that an ASCII version of the IDRP document, to be
published as an RFC, had been created by the document editor and was
available on the ISO document archive on merit.edu.
IDRP Usage Document
The question was raised as to whether IDRP requires a usage document,
distinct from the BGP usage document. It was noted that IDRP has a
number of features that BGP does not, in particular, Routing Domain
Confederations and Distribution Lists, and that it would be useful for a
usage document to discuss the use of these features. It was decided
that there would be a unified BGP/IDRP usage document based on the
current BGP usage document. Susan and John Scudder agreed to write this
document; Tony agreed to review it.
IDRP MIB
A MIB document exists, with local MIB extensions. The question was
raised as to whether it would be worthwhile to create a unified MIB
document. It was agreed that the BGP and IDRP MIB documents would
remain distinct.
IDRP Implementation Status
The Aeronautical Telecommunications Network standards specify IDRP over
a fully connected SMDS-like network running without an intra-domain
routing protocol. One European router vendor expects an implementation
within ``eight to ten weeks.'' Two ports of gated are being worked on
(Sun and Hewlett-Packard). CSC is doing a scratch implementation for
the Federal Aviation Administration. IBM is also doing a scratch
implementation, but stressed that this was not a product. The
implementation is expected to become available (end of 1993).
No implementation provides any significant policy functionality at this
time. The IBM implementation is intended to support the full policy
syntax specified in an appendix in the IDRP specification. No
implementation, except for IBM, supports Routing Domain Confederations
at this time, though all implementors plan to do this (especially since
it is a mandatory part of the protocol). The IBM implementation will
support Routing Domain Confederations as part of its initial release
(end of 1993).
IDRP is currently active in Europanet, connecting two parts of Europanet
together.
Susan asked for volunteers to provide information on implementation
experiences to be provided in support of progression of IDRP for IP to
Proposed Standard status. The group agreed to pursue this progression.
IDRP for IPng
Susan reported that IDRP has been offered to all of the IPng working
groups as a candidate inter-domain routing protocol. The TUBA group
plans to use IDRP; the SIP and PIP groups are evaluating the protocol.
Susan is preparing an IDRP for SIP document.
IDRP for IP Working Group Status
Susan moved that the IDRP for IP Working Group be moved to ``hiatus''
status until the documents are ready for progression to Proposed
Standard status. The group agreed to this proposal.
The meeting was then adjourned.
Attendees
Bernt Allonen bal@tip.net
Arun Arunkumar nak@3com.com
Toshiya Asaba asaba@iij.ad.jp
Dennis Baker dbaker@wellfleet.com
Tony Bates tony@ripe.net
Ronald Broersma ron@nosc.mil
Thomas Brunner brunner@switch.ch
Henry Clark henryc@oar.net
David Conrad davidc@iij.ad.jp
Tom Easterday tom@cic.net
Hans Eriksson hans@sics.se
Stefan Fassbender stf@easi.net
Mark Fedor fedor@psi.com
Dennis Ferguson dennis@ans.net
Peter Ford peter@goshawk.lanl.gov
Shoji Fukutomi fuku@furukawa.co.jp
Vince Fuller vaf@stanford.edu
Craig Haney craig@icp.net
Susan Hares skh@merit.edu
Frank Hoffmann hoffmann@dhdibm1.bitnet
David Jacobson dnjake@vnet.ibm.com
J. Jensen jensen@ic.dk
Cyndi Jung cmj@3com.com
Marijke Kaat marijke@sara.nl
Dave Katz dkatz@cisco.com
Sean Kennedy liam@nic.near.net
Rajeev Kochhar rajeev_kochhar@3com.com
Ton Koelman koelman@stc.nato.int
John Krawczyk jkrawczy@wellfleet.com
Tony Li tli@cisco.com
Robin Littlefield robin@wellfleet.com
Peter Lothberg roll@stupi.se
Peter Merdian merdian@rus.uni-stuttgart.de
Gerry Meyer gerry@spider.co.uk
Keith Mitchell keith@pipex.net
Ramin Najmabadi najmabadi@helios.iihe.rtt.be
Peder Chr. Noergaard pcn@tbit.dk
Michael O'Dell mo@uunet.uu.net
Andrew Partan asp@uunet.uu.net
Willi Porten porten@gmd.de
Juergen Rauschenbach jrau@dfn.de
Yakov Rekhter yakov@watson.ibm.com
Georg Richter richter@uni-muenster.de
Duncan Rogerson d.rogerson@nosc.ja.net
Miguel Sanz miguel.sanz@rediris.es
John Scudder jgs@merit.edu
Henk Steenman henk@sara.nl
Ed Stern els@proteon.com
John Stewart jstewart@cnri.reston.va.us
John Stewart
Marten Terpstra marten@ripe.net
Kamlesh Tewani ktt@arch2.att.com
Richard Thomas rjthomas@bnr.ca
Paul Traina pst@cisco.com
Rene van der Hauw rene@geveke.nl
Rachel Willmer rachelw@spider.co.uk
Jessica Yu jyy@merit.edu
Romeo Zwart romeo@sara.nl