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