CURRENT_MEETING_REPORT_
Reported by David Conrad/Internet Initiative Japan
Minutes of the Joint Session of the BGP and IPIDRP Working Groups
BGP4 Unresolved Issues - Dennis Ferguson
The following issues were discussed:
o Decisions have to be made regarding choosing a next hop forwarding
address
o What should be done when there is no IGP route to the forwarding
address
It was observed that the tie breaking rules can be directly derived from
these two decisions.
With respect to choosing the next hop forwarding address, there are two
options: using NEXT_HOP and using neighbor address.
The advantages to using NEXT_HOP for the forwarding address:
o Better routing when there are alternative paths to the DMZ
o Allows use of IBGP route servers
o If you don't care about third party NEXT_HOP, it is cheaper to not
set the NEXT_HOP to a local address (not permitted by current spec)
A disadvantage of using NEXT_HOP is that the DMZ address must be
propagated into the IGP before a third party NEXT_HOP can be advertised.
Advantages to the use of neighbor's address for the forwarding address
are that there is less confusion about whether the DMZ needs to be
propagated into the IGP or not, and that cisco BGP3 did it this way.
It was discussed that NEXT_HOP means an unstable IGP may result in
retracted routes, and that the handling of IGP instability should be
addressed in the specification. Other points presented are that
Europeans have NEXT_HOP as a requirement and that NEXT_HOP gives better
routing decisions.
There was discussion on what to do when there is no IGP route to the
forwarding address. The option of not selecting a route for which you
don't have an IGP route was examined as well as the option of
blackholing traffic when there is no IGP route.
The advantages of not selecting a route are that an IGP cost for
tie-breaking always exists, fallback routes can be used, and black holes
are not readvertised. The advantage of blackholing is that it is easy.
Comments made with respect to the options available include the
observation that either is interoperable and that there is sympathy for
people blackholing as an easy solution when trying to get other things
working.
The attendees decided to use NEXT_HOP as next hop forwarding address and
not to select a route for which you don't have an IGP route.
Enhancements to AGGREGATOR - Paul Traina
Currently the AGGREGATOR path attribute contains the AS of aggregator.
The attendees had decided to add an ASCII string, but subsequent
discussions on the BGP mailing list reversed this decision.
The final decision on the AGGREGATOR path attribute is to add an IP
address (in addition to the AS number), and indicate in the protocol
specifications that this attribute is ``highly recommended'' for
implementation.
LOCAL_PREF - Dimitry Haskin
It was pointed out that there are inconsistencies between the various
BGP documents with respect to treating LOCAL_PREF. In the BGP4 Protocol
specification higher value --> higher preference, while in the BGP4 Usage
document lower value --> higher preference.
It was observed that BGP4 is unlike all other protocols (except BGP3) on
the issue of preference. This could cause transition problems.
Yakov Rekhter volunteered to check the BGP/OSPF interaction document and
insure higher value means higher preference (the protocol document is
correct). The BGP4 documents will be clarified on this issue as well.
Erroneous NEXT_HOP - Tony Li
The subject of the discussion is how to handle the case when the
NEXT_HOP value is wrong. It can be ignored but logged, or a non-fatal
notification can be sent to the host generating the bad NEXT_HOP. It was
decided that it would be ignored but logged since the other option would
result in too much change to the specification. The notification option
will wait until the next version.
BGP4 MIB - Andrew Partan
Possible improvements to the BGP4 MIB were discussed. More variables
should be added that would be useful from an operational standpoint.
The meeting participants reached the following decisions:
o Define a MIB variable that contains elapsed time since the last BGP
peering session establishment/termination. This variable is
defined on a per peer basis. If the session was never established,
this variable contains the elapsed time since the peer was
configured.
o Define a MIB variable that contains elapsed time since the last
UPDATE received. This variable is defined on a per peer basis.
o Combine internal and external BGP neighbors MIB tables together.
IDRP Status - Yakov Rekhter
IDRP reached full International Standard in October 1993. The document
is available via anonymous FTP from merit.edu in PostScript
(/pub/iso/iso10747.ps[.Z]) or ASCII (/pub/iso/idrprfc.txt).
It is expected that the document will be issued as an RFC as well.
IDRP Implementation - David Jacobson
Yakov Rekhter, Rob Coltun and David Jacobson participated in the
implementation. It is a standalone IDRP that supports integrated IP and
ISO routing. It can run over IP or CLNP, and is loosely coupled to
GateD.
The implementation supports the following functions:
o Basic Transport
o Empty RIB-Att
o Confederations
o Policy
o Aggregation
It is expected that by the end of 1993,, the code will be completed and
some testing will be performed. More internal system tests on the code
will take place in early 1994. In late winter or early spring the code
will be available for interoperability testing. The code will be given
to NSF, and NSF will decide on the distribution of the code.
Domain Partition Repair - Dennis Ferguson
BGP does not currently handle partition healing like EGP does.
Two types of routing loops were defined:
o Permanent - routing protocol not required to send updates to
terminate the loop
o Transient - routing protocol will send update which terminates loop
BGP routing loops were discussed. It was observed that BGP routing
loops are always transient, and that the BGP specification chooses
1-cycle loop termination in all cases. If BGP allowed n-cycle loop
termination with n > 1, partitions may be healable. The cost of setting
n > 1 is that it can lead to transient loops that require a large number
of updates to terminate.
The following changes to the document are needed to support Domain
partition repair:
o In section 6.3 remove the check that an AS appears in the AS path
only
o In section 9.3 remove the constraint against using a route with the
local AS in the path
o Modify the aggregation procedures such that multiple occurences of
an AS in the path of a route being aggregated are reflected in the
aggregate path
o Modify the constraint in section 5.1.3 on advertising your
neighbor's address as the next hop
The following comments were made during the discussion:
o Implementing domain partition repair could impose some addressing
constraints (e.g. class As)
o Implementing domain partition repair requires removal of the
AS-PATH check in section 6.3; however, removal of this check has no
negative impact on the protocol
o Implementing domain partition repair will work only in presence of
contiguous sequence of BGP-4 speakers. Passing routes that went
through a partition repair to BGP-3 would result in terminating BGP
peering with a BGP-3 speaker
o Implementing domain partition repair by removing ASs from the AS
path is very dangerous
It was decided that the check in section 6.3 will be removed and that it
should be verified that ATOMIC_AGGREGATE reduces the number of bits.
Advancing BGP4 to a Proposed Standard - Yakov Rekhter
Yakov Rekhter will cleanup LOCAL_PREF issues in usage documentation,
changes to the BGP4 specifications will be done by Yakov Rekhter and
Tony Li by Thanksgiving, and the BGP4 MIB will be updated by John Chu by
Thanksgiving.
Selecting an Indirect Provider - Yakov Rekhter
The scheme is described in the Internet-Draft,
draft-rekhter-select-provider-00.txt. It was discussed that with
tunneling, even experienced users can run into trouble. It was also
noted that more manageable mechanisms than tunnels are needed.
Route Server - Tony Li
Currently IBGP must be fully meshed. An alternative is to have an IBGP
route server. Route servers would be fully meshed. An IBGP route
server would constrain the amount of configuration and IBGP connections.
The upper bound would be the number of border routers. Route server
traffic would get all changes. Packet routing would be decoupled from
data flow. To implement an IBGP router server would require an
algorithm and protocol to elect designated route server.
Attendees
William Barns barns@gateway.mitre.org
Stephen Batsell batsell@itd.nrl.navy.mil
Rebecca Bostwick bostwick@es.net
Al Broscius broscius@bellcore.com
Randy Bush randy@psg.com
Enke Chen enke@merit.edu
Henry Clark henryc@oar.net
Rob Coltun rcoltun@ni.umd.edu
Christopher Dorsey dorsey@es.net
Dennis Ferguson dennis@ans.net
Carlos Fernandez carlos@plk.af.mil
Vince Fuller vaf@barrnet.net
Vincent Gebes vgebes@sys.attjens.co.jp
Herluf Hansen hha@tbit.dk
Susan Hares skh@merit.edu
Dimitry Haskin dhaskin@wellfleet.com
Denise Heagerty denise@dxcoms.cern.ch
Robert Hinden hinden@eng.sun.com
David Jacobson dnjake@vnet.ibm.com
Dale Johnson dsj@merit.edu
Akira Kato kato@wide.ad.jp
Hiroshi Kawazoe kawazoe@trl.ibm.co.jp
Sean Kennedy liam@nic.near.net
John Krawczyk jkrawczy@wellfleet.com
Charles Kunzinger kunzinger@vnet.ibm.com
Tony Li tli@cisco.com
Robin Littlefield robin@wellfleet.com
Kim Long klong@sura.net
Peter Lothberg roll@stupi.se
Thang Lu tlu@mcimail.com
Doug Montgomery dougm@osi.ncsl.nist.gov
Robert Moose rmoose@gateway.mitre.org
Dennis Morris morris@altair.disa.mil
Sandra Murphy murphy@tis.com
Vijayaragavan Pandian vjp@proteon.com
Andrew Partan asp@uunet.uu.net
Alex Reijnierse a.a.l.reijnierse@research.ptt.nl
Yakov Rekhter yakov@watson.ibm.com
Steven Richardson sjr@merit.edu
Greg Ruth gruth@gte.com
Dallas Scott scott@fluky.mitre.org
Paul Serice serice@cos.com
Erik Sherk sherk@sura.net
Bernhard Stockman boss@ebone.net
Marten Terpstra marten@ripe.net
Paul Traina pst@cisco.com
Chris Wheeler cwheeler@cac.washington.edu
Cathy Wittbrodt cjw@barrnet.net
Jessica Yu jyy@merit.edu
Mary Jo Zukoski maryjo@gateway.mitre.org