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.