PSARC Questions Version 1.18 Approved Oct. 2008 (PSARC/2008/625) The 20 questions outline serves several purposes. One is to present to the ARC in a uniform manner pertinent information about any case. Many of the answers to these questions can be direct and specific references to other case materials (although care must be taken to keep the references current). A second purpose is to allow an ARC member to get a concise overview of the case in an efficient manner. Another purpose is that the 20 questions should provoke thought and questions for project teams unfamiliar with the ARC process, by asking questions about aspects of the project that need be considered. Lastly, the 20 questions serves as a vehicle between the case owner and the project team as an indicator of preparedness. The 20 questions, as do other ARC materials, remain as documentation of the case plan of record. 1. What is the proposal being presented for review? * Give an overview of the project and its phase(s). This project provides Ethernet datalink-layer (IEEE 802.1D) bridge functionality for Solaris and OpenSolaris. There is currently one delivery planned, and the delivery includes both basic bridging functionality (this project) and RBridges (a separate project to be introduced later that builds on this project). The project being reviewed here is basic bridging alone. * Describe the exposure (OpenSolaris), scope and type of review desired (overview, full case, etc.) This is a full case with open exposure. All development related to it is open. The scope for this case is limited to standard bridging alone. A future case will address the additions for RBridges, and the project team is planning for both. * Indicate the release binding requested by the project team. See: http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ No incompatible changes are needed, but due to the reliance on Crossbow's MAC changes and the complexity of the project, the project team requests Minor release binding. No back-port is intended or expected. * What are the project's deliverables? These are a private bridging daemon (bridged), a kernel "bridge" component (with kstats), a private library implementing RSTP and STP, SMF service URIs for bridges, DLPI observability nodes for snoop/ wireshark, and new dladm command line options. * How does this project align with existing or proposed ARC cases? This builds on the changes Crossbow made to the MAC layer and will be an especially useful feature in conjunction with the L2 filtering project. It also can be used for complex network testing scenarios, particular with IPMP and NWAM. 2. Describe user interactions. * Are new user interfaces being proposed, or existing interfaces being changed? New subcommands and columns are added to dladm. * Explain the similarities in proposed interfaces with existing OS user interfaces (Solaris, Linux, Windows, etc.). Linux uses a separate "brctl" command to control bridges. Their bridging implementation doesn't appear to support VLANs per the standard, has the STP control path buried in the kernel (STP only, no RSTP), and has no persistent configuration. NetBSD has bridging built partly into "ifconfig" (the Swiss Army knife of BSD configuration), and partly into a separate "brconfig" utility. It has STP only (no RSTP), and also does not appear to support the standard for VLANs. * Are there any install time changes? No. 3. What are the exported (defined by your project) and imported (defined by another project that your project then references) interfaces or protocols and their respective stability levels? See: http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ Exported Interface Stability Comments --------- --------- -------- dladm *-bridge Committed new subcommands field names Committed dladm show-bridge -o link properties Committed show-link BRIDGE Committed new field kstats Volatile Should be raised later /dev/bridge/ Committed Observability node control ioctls Project Private /usr/lib/bridged Project Private svc:/network/bridge Committed SMF URI config/* Project Private SMF properties bridge module Project Private Kernel bridging module /var/run/bridge_door/ Project Private Doors interface to daemons librstp.so.1 Project Private RSTP implementation Imported Interface Stability Comments --------- --------- -------- mac, dls, dld Consolidation Private Kernel APIs 4. Describe any dependencies on hardware (e.g. SPARC exclusive), and on other projects within Solaris. N/A 5. Projects need to be aware of the overall security of the system and how their components affect it. Which parts of this project are critical to the security of the system to avoid such unintended consequences such as unauthorized system entry, unauthorized access to or modification of data, elevation of privilege, denial of service, ...? Does this project require elevated privilege? The existing dladm and svcadm interfaces provide the required security, and the existing administrative profiles suffice for bridging. A number of specific policies and practices address various aspects of the security of the system. They are found in appendix 1. Which of these are applicable to this project, and how are they addressed? See bridging-security.txt. 6. Describe means of observing project functionality and performance, by an end user or by a system administrator. Most information is available via "dladm show-bridge" and kstats. The daemon also includes a debug option that writes to syslog (intended only for use with support). The user can also snoop on the bridge itself, in addition to snooping individual links. 7. How does the project deal with faults and interruptions? Initialization and restarting? These are governed by the IEEE standards. In short: - updated BPDUs are sent when an interface goes up or down. - the kernel module halts forwarding if the daemon is terminated for any reason. - the daemon will flush the forwarding tables when the protocol determines that a restart of learned information is needed. - learned forwarding entries are aged away. 8. How does the project interact with Solaris virtualization technologies (xVM, LDOMs, zones, SunCluster, etc.)? In principle, this technology should work from within xVM and LDOMs, however the nature of virtualized interfaces there may require users to disable the P2P detection scheme; there's effectively a repeater underneath the DomU. This can be used on systems with non-global zones installed, but it is not expected to be used within non-global zones themselves. This is datalink administration, which is a global zone issue, just as is (for example) IEEE link aggregation. There are no known impediments to use within a SunCluster environment. 9. Does this project require administration (i.e., configuration or management)? If so, * How is the project administered, and what sort of review process has this user interface undergone? The existing dladm and svcadm commands are used. * Is there a means of aggregating management and/or configuration with other related projects? There's no relationship yet between dladm and L2 filtering, though that's at least possible. The big issue here is that dladm doesn't yet store all its data in SMF. That's an underlying issue, and not something new or changed with this project. * Does this project deliver its own administration along with the other components, or is this project an administration interface for other projects? Neither? This project delivers additional subcommands to an existing administrative interface. * Are there any external (to Solaris) management interfaces to consider, or being consumed? None. (Remote bridge management is not supported in this initial implementation.) Projects that require or deliver administrative interfaces are often by their nature security components of the system and should likely address the security question (#5 above, with attention to RBAC and Audit). (See also appendix 2). 10. Have you reviewed the Policies and Best Practices? Are there any exceptions this project needs? See http://www.opensolaris.org/os/community/arc/policies/ http://www.opensolaris.org/os/community/arc/bestpractices/ Yes; policies and best practices reviewed. No exceptions.