Interconnectivity Working Group Chairperson: Guy Almes/Rice CURRENT MEETING REPORT Reported by Guy Almes AGENDA o Tuesday afternoon: Open meeting to do a review of concept with other IETFers and obtain feedback on the appropriateness of our objectives. o Tuesday evening: Work on MIRA Architecture. o Wednesday morning: Work on BGP Usage. ATTENDEES 1. Almes, Guy/almes@rice.edu 2. Breslau, Lee/breslau@jerico.usc.edu 3. Brim, Scott/swb@devvax.tn.cornell.edu 4. Burgan, Jeffrey/jeff@nsipo.nasa.gov 5. Carter, Glen/gcarter@ddn1.dca.mil 6. Choy, Joe/choy@ncar.ucar.edu 7. Crocker, Dave/dcrocker@ahwahnee.stanford.edu 8. Deboo, Farokh/fjd@bridge2.esd.3com.com 9. Denny, Barbara/denny@sri.com 10. Doo, Way-Chi/wcd@bridge2.esd.3com.com 11. Edwards, David/dle@cisco.com 12. Enger, Robert/enger@sccgate.scc.com 13. Estrin, Deborah/estrin@usc.edu 14. Fair, Erik/fair@apple.com 15. Farinacci, Dino/dino@bridge2.3com.com 16. Fedor, Mark/fedor@nisc.nyser.net 17. Fuller, Vince/vaf@jessica.stanford.edu 2 18. Gerich, Elise/epg@merit.edu 19. Grossman, Stu/grossman@score.stanford.edu 20. Hastings, Gene/hastings@morgul.psc.edu 21. Hedrick, Charles/hedrick@aramis.rutgers.edu 22. Honig, Jeffrey/jch@sonne.tn.cornell.edu 23. Ilnicki, Ski/ski 24. Jones, Bill/jones@nsipo.arc.nasa.gov 25. Jordt, Dan/danj@cac.washington.edu 26. Katz, Dave/dkatz@merit.edu 27. Kaufman, David/dek@proteon.com 28. Lepp, Marianne/mlepp@bbn.com 29. Lougheed, Kirk/lougheed@cisco.com 30. Mathis, Matt/mathis@fornax.ece.cmu.edu 31. Medin, Milo/medin@nsipo.nasa.gov 32. Mundy, Russ/mundy@tis.com 33. Nitzan, Rebecca/nitzan@ccc.nmfecc.llnl.gov 34. Rekhter, Yakov/yakov@ibm.com 35. Replogle, Joel/replogle@ncsa.uiuc.edu 36. Roberts, Ron/roberts@jessica.stanford.edu 37. Satz, Greg/satz@cisco.com 38. Schoffstall, Martin/schoff@nisc.nyser.net 39. St. Johns, Mike/stjohns@beast.ddn.mil 40. Steinberg, Lou/louiss@ibm.com 41. Tsuchiya, Paul/tsuchiya@gateway.mitre.org 42. Veach, Ross/rrv@seka.cso.uiuc.edu 43. Volk, Ruediger/rv@germany.eu.net 44. Wintringham, Dan/danw@osc.edu MINUTES Tuesday afternoon we had an open meeting to review MIRA and BGP concepts. The notion of Route Server, the structure of MIRA, and the notion of Full-AS-Path were all discussed in detail, and comments were solicited. Was this doable? Would it advance the state of connectivity and 3 quality/stability of Inter-AS routing? In all these cases, we heard no substantive negative remarks. This enabled us to proceed with our more technical sessions, confident that MIRA and BGP would be useful if properly designed and implemented. Tuesday evening we met to discuss detailed questions related to the implementability of MIRA. In the general MIRA case, the Route Servers and Border Gateways are not the same machine and are not even co-located. This makes the tasks of what EGP calls Neighbor Reachability difficult. We agreed to focus on the case in which each Route Server shares a network, typically an Ethernet, with one or more Border Gateways of its AS. Another technical problem relates to the transient situation in which a transit AS's Inter-AS route to a destination changes. The AS must stop advertising its old route, then its new route must be usable and used and propagated through the Interior Gateways of its AS, and then it can advertise its new route to other ASes. Flash updates with the AS's IGP and engineering of non-huge diameters will be key. We returned to this issue on Wednesday. Another issue was the determination of up/down status of the link between adjacent ASes. In many protocols, such as RIP, there is no up/down protocol other than the receipt of routing packets; this leads to grave problems when diode situations arise. Even in modern protocols, such as the IS-IS protocol used within the NSFnet Backbone, up/down protocols may fail. A recent case was discussed in which a non-trivial bit-error rate existed on a serial line of the Backbone. The rate was low enough to allow most of the (very small) packets used in the up/down protocol to get through. The rate was large enough, however, to corrupt most large data packets, so the link was essentially useless, even though the IS-IS up/down protocol had determined the link was up. Some of the group have concluded that the only reliable up/down protocol approach will be to use monitoring protocols such as SNMP, with careful implementations adapted to the particular kind of physical/link layers used. During the near term, however, when such monitoring implementations are not available, a conservative approach would be to insist on colocating Route Servers on an Ethernet. We concluded the session with a discussion of the pros and cons of separating the role of Route Server from the role of Border Gateway. We noted that MIRA *allows* the two to be implemented within the same machine. Doing so in fact simplifies various RS-to-BG communications. It is crucial, however, to also allow the two to be separated: 4 o This will allow network engineers to continue to use existing Border Gateways and still move to MIRA with separate RSes. o It will reduce the computational burden on the Border Gateways by doing Inter-AS routing functions in another computer. o It will allow network engineers to choose among vendors for RS implementations. (In the current environment, users are `captive' to gateway vendors; we should try to reduce the extent of this.) o A vendor can add RS functionality to its gateway product on a schedule of the vendor's choosing; its customers can use separate RSes during the meantime. o All network engineers could support MIRA/BGP with separate RSes during a period of time in which integrated RS/BG implementations were being built. Wednesday morning we focused on the dynamics of changing Inter-AS routes. A near-worst-case occurs when AS1 functions as a transit AS for a given destination N. AS1 uses AS2 as its next AS in routing to N, and advertises this path to AS3. AS3, however, uses a path via AS5, and AS1 sees AS3 advertising this path. Now, due to a break in the direct AS1-to-AS2 link, AS1 wants to use AS3 as its next hop. Before it can do so, two things must happen: o AS1's neighbors must learn that AS1's old path is no longer valid. (Otherwise a loop can form.) o The Interior Gateways of AS1 must learn that a Border Gateway to AS3 is its path to N rather than the Border Gateway to AS2. During the time when these two things are happening, routing to N will be very difficult, and dropped packets may occur. Careful sequencing of actions must take place in these and similar cases. A second issue was to decide on Shortest-AS-Path-Length and Static Preferences as the methods of deciding which of several alternate AS Paths to use. MIRA/BGP allows for future more sophisticated techniques, but we will wait a while to push these techniques.