|
|
ICC Home / Members / Meetings / Peer Support / Documentation / Projects
Minutes of November 12th, 2009 ITAC-NI Meeting: |
Link to ACTION ITEMS from meeting AGENDA: CALL TO ORDER: This meeting was scheduled in CSE E507 at 1:30 pm on Thursday, November 12th and was made available via videoconference with live-streaming and recording for future playback. Prior announcement was made the morning of the meeting via the Net-Managers-L list. The meeting was called to order by ITAC-NI chairman, Dan Miller, Network Coordinator of CNS Network Services. ATTENDEES: Eighteen people attended this meeting locally. There were two attendees via Polycom videoconference and no records of how many may have listened into the stream via a web browser using the web interface. Ten members were present: Charles Benjamin, Dan Cromer, Craig Gorme, Tim Fitzpatrick, Stephen Kostewicz (via Polycom), Shawn Lander, Steve Lasley, Chris Leopold, Tom Livoti, and Dan Miller. Four members were absent: Clint Collins, Erik Deumens, Margaret Fields, and Handsford (Ty) Tyler. Ten visitors participated as well: Avi Baumstein, Dennis Brown (via Polycom), Jeff Capehart, Chris Griffin, Todd Hester, T. J. Logan, John Madey, Marcus Morgan, Tim Nance, and Jan van der Aa. Viewing the recording You may view the recording via the web at http://128.227.156.84:7734. Currently, you will need to click on the "Top-level folder" link, then the "watch" link next to the "ITAC-NI Meeting_12Nov09_14.15" item. This will likely be moved into the ITAC-NI folder shortly. Cross-platform access may not be available; on the Windows platform you will have to install the Codian codec. Audio archive An archive of audio from the meeting is available. 1) Approve prior minutesNo corrections or additions were offered and the minutes were approved without further comment. 2) Membership changeDan Miller announced that Ron Cigna will be replacing Stephen Kostewicz as the College of Dentistry's representative to the ITAC-NI committee. This is pending expected approval by Dr. Chuck Frazier. 3) Review and comment on a revised Telecommunicatins Construction StandardsJohn Madey handed out several copies of a revised draft of the Telecommunications Construction Standards. He gave a brief description of the ongoing review process via a PowerPoint presentation. 3-1) BackgroundJohn explained that the current version dates back to May 2005 and has served UF fairly well. These standards are used as a starting point for new construction design / major renovations. This document is used by consulting engineers as a foundation for addressing the details of physical infrastructure, structured cabling systems, and information transport systems within new projects. 3-2) OverviewThe standards document consists of various sections covering major components: Labeling and documentation is very important for CNS because they enter much of this information into their telecom management system and also into UF Space Tracking & Reporting System (UF STARS). There are eighteen sections which cover the above mentioned parts and appendices providing additional details. Variance requests have been tracked over the years as a means of keeping up with industry trends. Internal review is also done in order to consider changes our own IT folks are recommending. These are used as input for modifying the document to keep it current. 3-3) HighlightsJohn then covered some of the main points which the standards address. 3-3-1) Access to all Telecom Spaces John said that the section below from page 8 describes a practice which they have implemented for a couple of years but which they are going to get much stricter with on new construction in the future:
Then intend to specify LENEL card key systems be installed on all new telecom spaces on the UF campus proper. 3-3-2) Entrance Facility / Main Telecommunications Room/ Telecom Room Backboard Another minor but important issue, also from page 8, has been the backboards installed in all the telecom spaces:
ReadySpec was specified, but they also had allowed the installation of AC3 backed plywood painted on both sides. The problem with the latter is that it looks sloppy when installed and often has seams which interfere with mounting equipment. In the future they intend to enforce the use of ReadySpec. 3-3-3) Section 4.0 Telecom Room Size John said that there is always a fight for space, but they do have design specs, listed on page 12, which they try to hold to:
3-3-4) Section 6.0 Horizontal Pathways John stated that cable trays rather than J-hooks are the standard. They do not like the use of J-hooks due to the sloppy installations they encourage and because trays provide better cable support and easier maintenance. The specifications include conduit from the WAOs stubbed out to the cable tray.
3-3-5) Section 7.0 WAO (Work Area Outlet) This next item does represent a change in the standard. They used to require three cables per WAO: two for data and one for voice. With our move to VoIP, only two cables (both data) will be required (or just one if supporting a WAP). Tom Livoti noted that HealthNet still specifies dual drops for WAPs; John responded that they originally had that as well, but their infrastructure crew decided that one would suffice.
3-3-6) Section 8.0 Backbone cabling Although single-mode fiber connections have been implemented for some time, it was not in the old standard. This section rectifies that to bring things up-to-date. Tom Livoti said that it was his feeling that 12-strand is too small because it has been their experience that they never have enough fiber installed. Since it is a lot cheaper to run the extra capacity initially, they specify double what CNS is suggesting. John responded that their internal debate had actually been to perhaps reduce the minimum, however they decided to stick with 12-strand. John emphasized that these are minimum standards. More fiber can be utilized as deemed appropriate in any particular case and he agrees that more is generally better.
3-3-7) Section 9.0 Horizontal Cabling Standards relating to horizontal cabling have been beefed-up a little bit to emphasize that other low voltage systems should be bound to telecom standards and will be inspected by OIT for compliance. They have been seeing building automation systems "slapped-in" without consideration to standards. Fixing this will involve coordination with Facilities Planning as will be discussed later in this meeting.
3-3-8) Section 11.0 Deliverables John noted that some level of network connectivity is often requested prior to project completion. CNS wants to specify that they require a complete air-conditioned telecom room prior to activating any ports and that the horizontal cabling must be tested prior as well. This is intended to assure that the contractor and Facilities Planning are aware of what must happen prior to network commissioning.
Tom Livoti realized that this matter was up for later discussion, but he wanted to emphasize that the current building automation standards lead contractors to believe they can implement their own network solutions. What we need to do is remove those portions from those standards and replace them with cross-references to the Telecom standards. 3-3-9) Section 17.0 Blue Light Phones -- NEW Although Blue Light Phones were in the Telecom Standards prior, there were always questions regarding what kind of phones were acceptable, etc. Consequently, section 17 was added which specifies Talk-A-Phone products and an appendix now details installation. 3-3-10) Section 18.0 Mass Notification System -- NEW A new section was also added to address details of our mass notification system which is being instituted in conjunction with EHS and UFPD. IP Paging will be implemented via InformaCast software (recently acquired by Singelwire). Indoor/outdoor IP speakers and outdoor loudspeakers are supported in addition to standard VoIP phones. Currently UF has about 150 classroom phones, 100 IP speakers and 3 outdoor loudspeaker paging areas within that system. Tim Fitzpatrick asked if the standard required the deployment of this and John responded that it only specifies the details of what is needed should EHS or UFPD require it. The standard does not specify that this system must accompany all new construction and major renovations. John added that this is similar to the situation with Blue Light Phones. UFPD decides where those will be required; that is not a role of these standards. 3-4) Next steps3-4-1) Review and incorporate feedback John is currently looking for feedback from the network community. He has also sent the draft over to some people in Facilities Planning & Construction and some Consulting Engineers. He hopes to get that feedback over the next couple of weeks. 3-4-2) Send out and present After that feedback is received and incorporated, John plans to have overview meetings with FP&C, PPD and contractors to apprise them of the highlights involved in this standards revision. This is meant to inform them what new details they may expect to be enforced regarding telecom standards. 3-5) QuestionsWill there be any attempts to cross-reference standards among related standards documents? (Tom Livoti) Tom pointed out that their standards currently include concrete strength specifications, for example. He feels it would be better to cross reference such sections out to the applicable standard document. That would help keep the entire standards system up-to-date; if an outside standard changed it wouldn't have to be specifically amended across multiple standards documents. Is the focus of this standards document strictly for on-campus facilities? (Chris Leopold) Chris Leopold wanted to know if these standards would be applied at IFAS Research Centers and County Extension Offices, for example. John replied that he understood IFAS wanting to have standards for those locations and was willing to work off-line with IFAS on developing those. Dan Cromer added that he had forwarded this telecom standards draft on to Kevin Heinicka, who is the Director of IFAS Facilities Planning and Operations, to get his input. Dan realizes that reality will necessitate exceptions due to the broad array of facilities IFAS supports across the state, but stated his interested in having IFAS comply wherever possible. 4) Discuss building design standards for Building Automation Systems (BAS)Dan Miller introduced this topic which was placed on the agenda because the current standard provided by PPD has references to how the systems are installed and attached to the Campus Data network. This, in turn, may relate to the Telecommunications Construction Standards just discussed. 4-1) ConcernsDavid Gagne was unable to attend, but Avi Baumstein reported that he had been involved with this topic recently with regards to a couple of buildings. He is concerned with how processing of the specifications for building automation is currently handled. In short, putting all that stuff on the network has created a tremendous problem. 4-2) RecommendationsAvi presented a number of recommendations which he feels could help this entire process. 4-2-1) Building automation systems should be included in the original building drawings As building automation equipment advances have come to require network connectivity, a different skill-set is required for implementation. IT networking skills are required in addition to the traditional building systems skills. Operations Analysis has been asked to deal with these issues because they provide IT support for Physical Plant. While Avi feels they have stepped up and done a good job with that, they could really use some better standards support for their efforts. One of the biggest problems is the building automation systems are not included in the original building drawings. It has been Avi's experience that contractors have been having their vendors design things almost on-the-fly. Consequently, there is no opportunity for someone to notice what "stuff" is even going into a building. Getting such things into the original design document would help with coordination a great deal. 4-2-2) Clarify networking standards for automation equipment Avi said that the current Building Automation System Guide Specification is worded in a way which leads vendors to believe they can implement their own network. It is important to correct that situation and clearly reference the appropriate Telecommunication Standards, making it clear that the existing building network must be utilized. Properly cross-referencing Telecom standards is especially needed in regard to wiring standards. Avi has noticed that, left to their own devices, vendors often implement some especially poor practices. He has seen wiring zip-tied to the fire sprinkler system, for example; that had to be torn out and all redone. Tom noted that vendors also like to run wiring along the shortest rather than the preferred path; that practice leads to problems down-the-road. 4-2-3) Involve all pertinent groups early in the process Avi noted that building automation vendors tend to come in one month prior to completion and a mad scramble ensues with the vendor complaining about the lack of network support, etc. Again, the primary reason that these vendor needs are not being addressed prior is that these systems were not included in the drawings. 4-2-4) Ownership and responsibility for equipment maintenance and operation must be clearly documented at the beginning of the project Building automation involves implementing things such as gateways, video recorders, access control panels, etc. The vendors generally plan on just sticking those in the building and walking away. We need to identify the parties who will be responsible for those devices over the long-term and have that clearly understood from the start. 4-2-5) The responsible IT unit should be the one to specify the IT-related components utilized in any system The next step is to have the IT group responsible for that equipment to actually specify the IT-related portion of the equipment. What we have currently is vendors bringing in computers of widely varying specifications which the entire operation of the building relies on, without any input from those who might have to maintain them. We need to get the requirements to the IT folks who will be operating the equipment so they can be involved in the specifications and can do the purchasing off the project's budget. 4-2-6) Incorporate the IT/network portions into the project manager's timeline We need to get all parties entered into the project timeline so that the necessary steps can be properly sequenced out. 4-2-7) Wiring and networking must be done by qualified individuals Getting back to the Telecom Standards, Avi said that it is important to have all wiring installed by competent licensed wiring contractors who understand and will respect our published standards. Avi said that it is just as important that the network connections be made by trained individuals. Currently we have wire-pullers lacking the necessary expertise trying to connect equipment to the network. That aspect should be left to network specialists who understand how to configure the network settings for equipment. 4-3) Questions and discussionDid David Gagne act as IT lead for Physical Plant on these projects? (John Madey) Avi responded that David was dragged in after a lot of things had already been done--basically to clean up the mess. John countered that Physical Plant may already be taking some of these steps where they hadn't in the past, but he agreed that we need to reinforce these points. The security impact of these systems needs to be considered (Jan van der Aa) Jan stressed that security implications must be investigated in conjunction as well. An insecure implementation of a particular piece of networked equipment could have implications for the security posture of UF as a whole. There are real concerns and Jan stated that something must be inserted to indicate that any networked equipment must comply with UF security standards and policies as well. Such equipment may be billed as "building automation" equipment, but may in fact involve (for example) an IIS server which is left un-patched and vulnerable. Issues such as vendors requiring public IPs to support equipment remotely become involved as well. The impact of such things on our security policy must be considered. Avi added that this is the very reason they want to insist that local IT staff be involved. The vendors and Physical Plant are just trying to get their job done and move on. We need continuing local IT support directly involved with such things. The feasibility of allowing vendors to implement temporary portable networks (Tom Livoti) Tom wanted to consider whether we might specify some portable solution, un-connected to the main network, which vendors might use for testing and configuration. That is something which is often needed prior to the main network infrastructure being in-place and ready. Tom has been working with one of his vendors to see if they can develop some package which suited this need. Avi suggested that this need might be better met perhaps through proper sequencing of project sub-tasks in order to make sure equipment wasn't being installed prior to its necessary support. Involving these issues into discussions with Facilities Planning (John Madey) John Madey offered that perhaps the next step would be for him to involve Avi, Tom and other interested parties in discussions with Facilities Planning. They are the major key player in all this and are the ones who would need to implement much of what has been discussed here. Standards for other equipment (Stephen Kostewicz) Stephen pointed out that perhaps we need a more general "equipment" standard as well. Research labs and clinics bring in all sorts of equipment that require similar coordination to what has been just discussed regarding building automation. He wasn't sure if that should involve yet another standards document, but felt that such things should be covered somewhere. Avi responded that the particular issue of building automation arose in an attempt to get those aspects compliant as well. Vendors have been able to refer to the current Building Automation System Guide Specification and use that as an excuse to duck responsibility. Avi felt that, at least in the Health Science Center, they already have the issues involving equipment in labs and clinics pretty well covered. Should building automation have its own space separate from Telecom? (Jeff Capehart) Avi responded that equipment needs to be in a room controlled and accessible to the person who is responsible for it. The LENEL systems are a great example: the LENEL DVRs are on PCs running Windows. Physical Plant hangs one in a Telecom closet, nobody knows it's there, and a year later the thing gets compromised. When the system is finally located and the responsible party is tracked down it turns out they don't even have access to the room to fix things. Tom stated that they prefer to limit the number of people having access to a Telecom room. It is not a good situation to provide vendors, etc. access because then you cannot easily track who has been in there. Dan Miller added that it comes down to security; if you have physical access you can subvert many network security mechanisms. John Madey said that a variance is typically requested to place LENEL equipment in the Telecom room. It is difficult to refuse that with a straight face by insisting you can't place security equipment in a Telecom room because of security. Rather, they accept the variance but specify where the equipment goes in the room. Tom Livoti replied that they have accommodated that with the control panels as well, but not with DVR equipment. Some discussion ensued on the feasibility of supplying separately securable space within a Telecom room for certain kinds of equipment. A distinction should be made between the wiring for a system and the software for that system (Dan Cromer) Dan Cromer feels it important for our standards to distinguish between the wiring aspects of such systems (which should conform to Telecom Standards) and the software aspects of such systems (which need to conform to Network Security Standards). Dan feels that this matter should be clarified so that there is an understanding by the vendors and others involved as to which standards apply to each aspect. 5) Discuss IPv6 deployment options and the formation of an IPv6 Work Group; review the IPv6 Address Plan, and options for additional IPv6 spaceThis topic was last discussed at our October meeting. 5-1) IPv6 deployment optionsCNS has now developed a four-page IPv6 deployment plan which Dan Miller read through for the committee. The sections following represent discussion which took place during the read-through. 5-1-1) There are really three phases of IPv6 deployment Tim Fitzpatrick summarized the three phases outlined within the proposed deployment plan. The next 6-7 months of this fiscal year is a "trail-blazing" phase during which CNS will selectively partner with a few IT groups on campus. The goal of this phase is to locate and solve problems which might arise. Next fiscal year (2010-2011) is basically a call for volunteers wishing to opt-in; such groups will be brought in as fast as CNS can support them. That portion is what this document terms "Phase One". Phase Two is intended to be no longer voluntary, rather those servers not active on IPv6 by that time would be scheduled for IPv6 deployment over fiscal year 2011-2012. 5-1-2) What groups should be involved in the IPv6 Working Group? Tim Livoti asked if Shands should be on the proposed workgroup. Tim Nance replied that he wasn't sure what the benefit to Shands might be; he indicated that it seemed like a lot of work and effort for minimal return. When Dan Miller said he was certainly hoping for at least one representative from the Health Science Center, Tom Livoti shared his view that Shands needs to be on this. The Health Science Center, Shands, and Jacksonville constitute probably 60% of the IP space which will be affected by this. The consensus was that Chris Stowe and Gary Bennett should both be involved, but Tom suggested that Dan Miller send an e-mail to Al Amirin and Dr. van der Aa asking them who they would like to have involved with this IPv6 Working Group. 5-1-3) FLR IPv6 allocation capabilities While FLR has now reserved a /40 chunk for UF against any future needs, the originally planned /44 assignment remains in effect. This means that any additional address space which might come into UF in the future would come in the form of a mask routing separate /48s off the core; no re-addressing would be necessary. 5-1-4) Building automation equipment concerns relative to IPv6 Jan van der Aa suggested that we may want to look closely at how networked building automation equipment might fit into this plan as he suspects that such equipment is among the most likely to have difficulties with making a transition to IPv6. Dan Miller followed-up by saying that even if someone from Dave Gagne's area is not on the Working Group, they should at least be aware and following progress. Consequently, Dan Miller plans to contact him about this matter. 5-1-5) The need for general training/familiarization with IPv6 Avi pointed out that many IT folks across campus could likely use training on various aspects of IPv6 pertinent to making this transition. Dan Miller suggested that this could be worked in around February 2010 when a targeted PR campaign is planned. Marcus Morgan suggested providing a set of instructions and Avi added that a tutorial on IPv6 basics would be worthwhile as well prior to providing specifics of how to make it work. 5-1-6) Will wireless be involved in this as well? Someone asked about implementing IPv6 over wireless. Dan Miller responded that he assumed this would be a subset of the host development work; DHCP should work there as well. By that time Dan expects we will have Network Access Control (NAC) working on the UF side so we can enforce some patch level standards. Most modern operating systems are capable of running dual IPv4 and IPv6 dual stacks now. Windows XP was raised as an issue; IPv6 would have to be installed on that platform as it apparently is not configured by default. 5-1-7) Will IPv4 eventually be disabled? Tom Livoti asked if the eventual disabling of IPv4 was envisioned. Chris Griffin responded that this would only occur via attrition which may eventually happen, but would certainly be over a very long timeframe. 5-1-8) Who is the lead on UF's future NAC implementation? When Charles Benjamin asked this, Dan Miller responded that Matt Grover is working on that currently with the wireless team and CNS. 5-2) IPv6 address planCNS has also developed a three-page IPv6 Address Allocation Plan. Dan Miller believed this to be very similar to what he had shown the committee previously. On the UF-side of the network they plan to allocate three general blocks. The first two of those are a "Globally Available Networks Block" and a "Private Networks Block" which are aggregated by core router. We will also have a "Centrally Provided Services Block" which is aggregated by service in order to facilitate the application of ACLs and security rules. 5-2-1) How many devices can fit in a /52 allocation? Craig Gorme asked about the size of this space. Marcus Morgan responded that a /52 provides 256 /64s, with /64 being the typical unit allocation. A great deal of space is involved, especially noting that, of the 16 /52s available, only three will be defined initially. Most of our space will remain in reserve. 5-2-2) Would changing providers require readdressing? Jeff Capehart asked what would happen if UF changed providers down-the-road. Chris Griffin responded that it is unlikely that UF will leave FLR since we enjoy partial ownership. Should that happen, however, it would appear that readdressing would be necessary. Chris pointed out that this matter is a major concern with the various IPv6 working groups. The multi-homing issue still hasn't really been solved and may not be solved. There are two main competing solutions proposed regarding multi-homing with several subsets, and all have issues. After years of investigation there still isn't a clear winning solution and we can't afford to wait any longer. Rather we are going to go with our best guess and adapt to whatever transpires. Most things, other than public facing servers, are dynamically addressed; that will help should changes be required later. 5-2-3) Is there such a thing as private IPv6 IP? Chris Griffin responded that the allocation plan includes a range of addresses which will be filtered in the same manner that private IPv4 is now. If you are in that /52 allocation you will be behind a stateful firewall and your traffic will be treated identically to how private IP is today. 6) Other discussion6-1) Introduction of T. J. LoganBefore we adjourned, Charles Benjamin wanted to introduce T. J. Logan who was with him today. T. J. is the Assistant Director of Housing for Administrative Services and has been with them about six months. Action Items
Next MeetingDecember 10, 2009 |
last edited 16 November 2009 by Steve Lasley