idnits 2.17.1 draft-ietf-isis-opexp-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-isis-opexp-01.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-isis-opexp-01.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-isis-opexp-01.txt)', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-isis-opexp-01.txt)', but the file name used is 'draft-ietf-isis-opexp-01' ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Abstract' ) ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Introduction' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 163 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 12 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document obsoletes RFC1195, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 45 has weird spacing: '...fts are worki...' == Line 47 has weird spacing: '...t other group...' == Line 88 has weird spacing: '...t forth by th...' == Line 128 has weird spacing: '... In the case ...' == Line 159 has weird spacing: '...and the bound...' == (4 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 1994) is 10878 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 1102 looks like a reference -- Missing reference section? '4' on line 223 looks like a reference -- Missing reference section? '3' on line 827 looks like a reference -- Missing reference section? '9' on line 550 looks like a reference -- Missing reference section? '5' on line 895 looks like a reference -- Missing reference section? '6' on line 985 looks like a reference Summary: 19 errors (**), 1 flaw (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ISIS Working Group Chris Gunner 2 Internet-draft Digital Equipment Corp. 4 Doug Montgomery 5 National Institute of Standards 6 and Technology (NIST) 8 July 1994 10 Experience with the Integrated ISIS Protocol 11 (draft-ietf-isis-opexp-01.txt) 13 Table of Contents 15 1. Status of this Memo 2 16 2. Abstract 2 17 3. Introduction 2 18 3.1. General Requirements 3 19 3.2. Specific Requirements for Draft Standard 4 20 4. Documentation 5 21 5. MIB 6 22 6. Security architecture 7 23 7. Implementations 7 24 8. Operational Experience 8 25 8.1. Case A 9 26 8.2. Case B 10 27 8.3. Case C 11 28 8.4. Case D 12 29 9. Interoperability Testing 12 30 9.1. Interoperability Testing Methodology 12 31 9.1.1. Protocol Functions Tested 13 32 9.1.2. Evaluation of Interoperability 14 33 9.2. Testing Sessions 14 34 9.2.1. August 1991 DIS-level Implementation Testing 15 35 9.2.2. February 1992 IS-level Implementation Testing 18 36 9.2.3. Spring 1992 Interop Demonstration 21 37 9.2.4. Fall 1992 Interop Demonstration Hot Stage 22 38 10. References 23 39 11. Acknowledgements 24 40 12. Working Group Information 24 41 13. Author's Addresses 25 43 1. Status of this Memo 45 This document is an Internet-Draft. Internet-Drafts are working 46 documents of the Internet Engineering Task Force (IETF), its 47 areas, and its working groups. Note that other groups may also 48 distribute working documents as Internet-Drafts. 50 Internet-Drafts are draft documents valid for a maximum of six 51 months. Internet-Drafts may be updated, replaced, or obsoleted 52 by other documents at any time. It is not appropriate to use 53 Internet-Drafts as reference material or to cite them other 54 than as a "working draft" or "work in progress." 56 To learn the current status of any Internet-Draft, please check 57 the 1id-abstracts.txt listing contained in the Internet-Drafts 58 Shadow Directories on ds.internic.net, nic.nordu.net, 59 ftp.nisc.sri.com, or munnari.oz.au. 61 2. Abstract 63 This document is one of two reports on the Integrated ISIS 64 protocol. The other report documents an analysis of the 65 protocol. These two reports are required by the IAB/IESG in 66 order for an Internet routing protocol to advance to Draft 67 Standard Status. Integrated ISIS is an Interior Gateway Protocol 68 and is designed to carry both IP and ISO CLNP routing 69 information. 71 Integrated ISIS is currently designated as a Proposed Standard. 72 The protocol was first published in RFC 1195. Internet Draft [2] 73 was published subsequently to RFC 1195 and documents the current 74 version of the protocol. 76 This report documents experience with Integrated ISIS. This 77 includes reports on interoperability testing, field experience 78 and the current state of Integrated ISIS implementations. It 79 also presents a summary of the Integrated ISIS Management 80 Information Base (MIB), and a summary of the Integrated ISIS 81 authentication mechanism. 83 Please send comments to isis@merit.edu. 85 3. Introduction 87 This document addresses, for Integrated ISIS, the requirements 88 set forth by the IAB/IESG for an Internet routing protocol to 89 advance to Draft Standard state. These requirements are 90 summarized below. The remaining sections of this report document 91 how Integrated ISIS satisfies these requirements. 93 3.1. General Requirements 95 1. Documents specifying the Protocol and its Usage. This may 96 be one or more documents. The specifications for the 97 routing protocol must be well written such that 98 independent, interoperable implementations can be developed 99 solely based on the specification. For example, it should 100 be possible to develop an interoperable implementation 101 without consulting the original developers of the routing 102 protocol. 104 2. A Management Information Base (MIB) must be written for the 105 protocol. Routing protocols, like all other Internet 106 protocols, need a MIB defined so they can be remotely 107 managed. 109 3. A security architecture of the protocol must be defined. 110 The security architecture must include mechanisms for 111 authenticating routing messages and may include other 112 forms of protection. 114 4. Generally, a number of interoperable implementations must 115 exist. At least two must be written independently. 117 5. There must be evidence that all features of the protocol 118 have been tested, running between at least two 119 implementations. This must include that all of the security 120 features have been demonstrated to operate, and that the 121 mechanisms defined in the protocol actually provide the 122 intended protection. 124 6. There must be operational experience with the routing 125 protocol. The level of operational experience required is 126 dependent on which level of standardization is requested. 127 All significant features of the protocol must be exercised. 128 In the case of an Interior Gateway Protocol (IGP), both 129 interior and exterior routes must be carried (unless 130 another mechanism is provided for the exterior routes). In 131 the case of a Exterior Gateway Protocol (EGP), it must 132 carry the full complement of exterior routes. 134 7. Two reports must be submitted to the IESG via the Routing 135 Area Director. The first report must document how 136 requirements 1) through 6) of this document have been 137 satisfied. It must include: 139 a. Implementation experience. 141 b. Reference to the MIB for the protocol. 143 c. Description of the authentication mechanisms in the 144 protocol. 146 d. List of implementations including origin of code. 148 e. Test scenarios and test results showing that all 149 features of the protocols have been tested. 151 f. Description of operational experience. This must 152 include topology, environment, time and duration, 153 implementations involved, and overall results and 154 conclusions gained from the operational experience. 156 The second report must summarize the key features of the 157 protocol and analyze how the protocol will perform and 158 scale in the Internet. The intent of this requirement is 159 to understand the boundary conditions of the routing 160 protocol. The new routing protocol must be compared with 161 the existing routing protocols (e.g., RIP, EGP, etc.) as 162 appropriate. The report should answer several questions: 164 g. What are the key features and algorithms of the 165 protocol? 167 h. How much link bandwidth, router memory and router CPU 168 cycles does the protocol consume under normal 169 conditions? 171 i. For these metrics, how does the usage scale as the 172 routing environment grows? This should include 173 topologies at least an order of magnitude larger than 174 the current environment. 176 j. What are the limits of the protocol for these metrics? 177 (I.e., when will the routing protocol break?) 179 k. For what environments is the protocol well suited, and 180 for what is it not suitable? 182 The IESG will forward to the IAB its recommendation for advancement 183 of the new routing protocol based on its evaluation of protocol 184 specifications and these reports. 186 3.2. Specific Requirements for Draft Standard 188 1. Revisions to the Protocol and Usage documents showing 189 changes and clarifications made based on experience gained 190 in the time between when the protocol was made a Proposed 191 Standard and it being submitted for Draft Standard. The 192 revised documents should include a section summarizing the 193 changes made. 195 2. The Management Information Base (MIB) must be at the 196 Proposed Standard level of standardization. 198 3. There must be significant operational experience. This must 199 include running in a moderate number of routers configured 200 in a moderately complex topology, and must be part of the 201 operational Internet. All significant features of the 202 protocol must be exercised. In the case of an Interior 203 Gateway Protocol (IGP), both interior and exterior routes 204 must be carried (unless another mechanism is provided for 205 the exterior routes). In the case of a Exterior Gateway 206 Protocol (EGP), it must carry the full complement of 207 exterior routes. 209 4. Documentation 211 The Integrated ISIS protocol is an extension of the ISIS 212 protocol defined by ISO 10589. The first definition of 213 Integrated ISIS which was documented in RFC 1195 was based on 214 the DP version of the ISO standard. In developing Integrated 215 ISIS some revisions to the ISO standard were suggested and 216 defined in RFC 1195. These were incorporated into ISO 10589 with 217 the result that the definitions in RFC 1195 were no longer 218 necessary. Hence an Internet Draft exists for Integrated ISIS 219 which defines the protocol as derived from the ISO 10589 version 220 of ISIS. 222 The details of what changed between RFC 1195 and the Internet 223 Draft are described in [4]. The implementations and testing 224 described in this document were all based on the RFC 1195 225 definition of the Integrated additions to the base protocol. 226 They were initially based on the DIS 10589 definition of the 227 base ISIS protocol. Subsequent implementations and testing were 228 based on the standard ISO 10589 definition of the base protocol 229 (see section 9.1 for details). 231 The Integrated ISIS protocol was developed by the ISIS Working 232 Group of the Internet Engineering Task Force (IETF). This 233 Working Group has a mailing list, isis@merit.edu, where 234 discussions of protocol features and operation are held. The 235 ISIS Working Group also meets during the quarterly Internet 236 Engineering Task Force conferences. Reports of these meetings 237 are published in the IETF's Proceedings. 239 A Management Information Base (MIB) for the protocol has been 240 developed and published as an Internet Draft [3]. There have 241 been 4 revisions of this MIB. For more information see section 5 242 of this document. 244 There is a public-domain implementation of Integrated ISIS 245 available from the University of Wisconsin. This implementation 246 has been incorporated into the public-domain gated program. 248 5. MIB 250 A Management Information Base for Integrated ISIS has been 251 published as an Internet Draft [3]. The latest draft is the 252 fourth version of the MIB. 254 The MIB is based on the managed object definitions defined in 255 ISO's GDMO and contained in ISO 10589 and parts of ISO 10733. A 256 design goal of the MIB was that it provide equivalent 257 functionality as that in the ISO standards. This results in a 258 large MIB since the ISO standards provide richer functionality 259 than that traditionally found in MIBs, for example, the ability 260 to dynamically create and delete table rows and generally 261 provide full configuration control. The MIB provides complete 262 management for both the base ISIS protocol and the Integrated 263 ISIS protocol 265 A partial implementation of the MIB has been developed by Novell 266 (level 1 and OSI only). A second implementation has been 267 developed by Interactive Systems Corp. 269 The MIB provides full configuration and monitoring control for 270 the protocol. It supports multiple instances of the protocol 271 running on the same system. 273 The MIB consists of 17 groups and 214 objects of which: 275 - 4 groups (106 objects ) are mandatory 277 - 13 are optional depending on the functions supported by the 278 instance of the protocol: 280  5 groups (29 objects) must be supported if the instance 281 supports IP 283  2 groups (14 objects) must be supported if the instance 284 supports OSI at level 1 286  1 group (8 objects) must be supported if the instance 287 supports OSI at level 2 289  2 groups (10 objects) must be supported if the instance 290 supports the authentication functions 292  1 group (10 objects) must be supported if the instance 293 supports the partition repair function 295  2 groups (37 objects) may be supported if the instance 296 wishes to support static route configuration 298 6. Security architecture 300 Integrated ISIS provides the option of carrying authentication 301 information in all the protocol's packets. The encoding is 302 extensible to multiple authentication mechanisms. However, 303 currently the only defined mechanism is a simple password, 304 transmitted without encryption. This use of a simple password 305 does not provide useful protection against intentional 306 misbehaviour. Rather, this should be thought of as a weak 307 protection against accidental errors such as misconfiguration. 309 The protocol and MIB permit separate passwords for each circuit, 310 each area and the domain. Also, although only a single password 311 can be configured for inclusion in transmitted packets, a set of 312 passwords can be configured for reception. This makes migration 313 from one password to another simple. The process is to add the 314 new password to the reception set on each router in turn, then 315 change the transmission password on each router in turn and 316 finally to remove the old password from the reception set on 317 each router. During this process no change in the routing 318 topology need occur. 320 Since the encoding of the authentication option is extensible to 321 other mechanisms, the protocol can be enhanced in a backwards 322 compatible fashion to support stronger authentication should 323 that be required. 325 7. Implementations 327 There are multiple interoperable implementations of Integrated 328 ISIS currently available. This section gives a brief overview of 329 the six implementations that are known to have taken part in 330 interoperability testing. Other implementations also exist or 331 are in development. 333 The six implementations that are known to have undergone 334 interoperability testing are (listed in alphabetical order): 336 - 3com. This implementation was wholly developed by 3com. It 337 has participated in the Interop fall '92 demonstration and 338 NIST interoperability testing. 340 - Cisco. This implementation was wholly developed by Cisco. 341 It has participated in the Interop fall '92 demonstration 342 and NIST interoperability testing. 344 - Digital. This implementation was wholly developed by 345 Digital. It has participated in the Interop fall '92 346 demonstration and NIST interoperability testing. 348 - Phase 2 Networks. This implementation was wholly developed 349 by Phase 2 Networks. It has participated in the Interop 350 Fall '92 demonstration and NIST interoperability testing. 352 - Proteon. This implementation was wholly developed by 353 Proteon. It has participated in the Interop Fall '92 354 demonstration and NIST interoperability testing. 356 - University of Wisconsin. This implementation was developed 357 wholly by the University of Wisconsin. It has participated 358 in the early ISIS testing conducted by NIST. This version 359 is in the public domain and has been incorporated into 360 gated. 362 In addition to these there are implementations of the base ISIS 363 protocol which have participated in interoperability testing at 364 NIST. These are: 366 - Wellfleet 368 - Fibercom 370 - Retix 372 - Novell 374 Note that, as required by the IAB/IESG for Draft standard 375 status, there are multiple interoperable independent 376 implementations of Integrated ISIS, namely those from 3com, 377 Cisco, Digital, Phase 2 Networks, Proteon and the University of 378 Wisconsin. 380 8. Operational Experience 382 This section describes some examples of significant operational 383 experience with the protocol. Since Integrated ISIS is a 384 derivation of the ISIS protocol, most of the core algorithms and 385 protocol are common to both ISIS and Integrated ISIS. However, 386 the operational experience reported here is restricted to 387 deployments using Integrated ISIS (those using ISIS are not 388 considered). The interoperability testing includes both ISIS and 389 Integrated ISIS testing since most aspects of the ISIS testing 390 are relevant to showing that Integrated ISIS is interoperable. 392 As can be seen from the sections below, the protocol has been in 393 use in some reasonable size networks for a significant time. In 394 no case has there been a significant problem with the protocol. 396 8.1. Case A 398 This deployment in a large research network has been following a 399 migration plan from DECnet Phase IV and IP to DECnet Phase V and 400 IP over the last few years. Currently I ISIS is in use only on 401 Digital routers of which there are approximately 38 split into 402 12 level 2 routers and 26 level 1 routers. These are in two 403 different areas with 6 level 2 and 5 level 1 routers in one area 404 and 6 level 2 and 21 level 1 routers in the other area. Note 405 that all level 2 routers are also level 1 routers. 407 A small number of the level 1 routers are currently running ISIS 408 (i.e. not Integrated ISIS) even though they are in the same area 409 as the I ISIS routers. This is technically in violation of the 410 topology restriction defined in RFC 1195 which state that all 411 routers in an area of all the level 2 routers must be either 412 ISIS only or be I ISIS only. The reason for this restriction is 413 that an ISIS only router that was on the path between two I ISIS 414 routers would not be able to forward IP packets sent to it 415 consistently with the I ISIS routers (if at all). In this 416 network the ISIS only routers are only at stubs of the area 417 where there is no IP traffic to be routed and this has proved to 418 work correctly. 420 There are approximately 600 endnodes in each of the two areas. 421 Most of these run DECnet Phase IV and IP and some run DECnet 422 Phase V and IP. 424 The network migration is currently in the stage of migrating a 425 larger number of Cisco routers to also run I ISIS so that at the 426 end of this stage there will be approximately 130 routers 427 running I ISIS. 429 The current network topology for the Digital I ISIS routers is a 430 partial mesh of Ethernet and point to point links (at various 431 speeds: 19.2kbps, 64kbps, 128kbps, 256kbps, 512 kbps). 433 In some cases the routers running I ISIS are configured to not 434 announce reachability to any IP Addresses. This was done to 435 avoid the subnets to which the router attached being announced 436 into the I ISIS domain. These subnets were being announced by 437 other routers using other IP routing protocols already. In these 438 cases these routers forwarded IP traffic as expected. 440 The network also currently has a larger number (70 or so) 441 routers (mostly Ciscos) which are doing IP routing using Cisco's 442 IGRP. Exchange of IP routes between the IGRP and I ISIS routers 443 is done either using RIP, since that is a protocol common to 444 both, or using static routes. In the RIP case the I ISIS domain 445 propagates all its routes into RIP while the IGRP domain 446 propagates just a default route into the I ISIS domain. The IGRP 447 domain is connected to the Internet. 449 One problem that this network had was in managing the default 450 route within an area. A restriction of the Digital routers meant 451 that a default route originated on a level 2 router was always 452 at level 2, while on a level 1 router it was always at level 1. 453 Because of the precedence of routes in I ISIS this meant that 454 for that area, the default route at level 1 was always 455 preferred, regardless of metric, over the default route at level 456 2. This is the opposite of what would normally be required. This 457 is not really a problem with the I ISIS protocol but indicates 458 the flexibility that is required in the configuration controls 459 for the routers. In this case implementations should make sure 460 they permit the configuration of which level routes are 461 announced into on a level 2 router. 463 The use of I ISIS in this network has been operational for 464 approximately 6 months. 466 8.2. Case B 468 This commercial deployment has 21 Digital routers all running 469 Integrated ISIS. All routers are configured as level 2. Note 470 that all level 2 routers are also level 1 routers. A main 471 Ethernet LAN has eight I ISIS routers attached together with 10 472 other IP-only routers (from various vendors: Cisco, 3Com, Sun) 473 which exchange RIP with most of the Digital I ISIS routers. The 474 other routers are connected through a mix of 56kbps and 384kbps 475 point to point links in a partial mesh such that no single link 476 failure will partition the network. At each of the 13 branch 477 sites there is an Ethernet LAN. All the point-to-point links use 478 the DDCMP data link protocol over which I ISIS uses the same 479 point-to-point subnetwork convergence functions as over an HDLC 480 link. Throughout the network there are approximately 900 481 endnodes of various types: 15 OSI, 200 DECnet Phase IV, 500 IP, 482 200 IPX (whose traffic is tunnelled through IP). 484 The network has 14 sites, each of which has a separate OSI Area 485 Address and a separate IP subnet address (using a single 486 subnetted class B network address with a single network-wide 487 subnet mask). 489 The I ISIS routers that exchange RIP with the IP-only routers 490 operate RIP in send and receive mode and propagate routes from I 491 ISIS to RIP and from RIP to I ISIS. They are configured to 492 accept the default route from RIP but not to announce it in RIP. 494 The network has a single connection to the Internet via an 495 endnode. Therefore there is no route propagation to or from the 496 Internet. 498 The average traffic load over the network (including all network 499 protocols) is approximately 300Mbytes per day. 501 The overall network uptime has been over 99%. Link failures have 502 averaged one per month. These failures have not caused any 503 problems with the applications. 505 There have been a few designated router changeovers (caused by 506 manual intervention rather than failure). During a changeover 507 there has been no problem with the applications. The changeover 508 process completes within a few seconds. 510 This network has now been operational for two years. 512 8.3. Case C 514 This commercial deployment includes Digital routers running 515 Integrated ISIS and routers from Cisco, Wellfleet and NSC 516 running IP only. The network is a partial mesh of Ethernet, FDDI 517 and point to point links (at 256kbps and 512kbps). There are 518 over 2000 endnodes in the network mostly running IP and/or 519 DECnet Phase IV with 5 OSI endsystems. 521 All the I ISIS routers are configured as level 2. Note that all 522 level 2 routers are also level 1 routers. Static IP routes are 523 used between some I ISIS routers and some IP-only routers. In 524 some cases the circuit metrics were changed from their default 525 values to create the desired traffic patterns. Convergence of 526 the protocol after link failures has not been a problem. 528 There are approximately 28 IP subnets with varying subnet masks 529 in use. 531 This network is not connected to the Internet. 533 This network has now been operational for over 1 year 535 8.4. Case D 537 This commercial deployment has 15 Digital routers. These are 538 interconnected via a mix of 64kbps and 2Mbps WAN links. All 539 routers are running Integrated ISIS. The network has been 540 operational for over 8 months. 542 9. Interoperability Testing 544 There have been four testing sessions of the protocol hosted by 545 NIST. These are described in detail in the sections below. For 546 the first three sessions, only the base ISIS protocol was 547 tested. The fourth session was conducted prior to the Fall '92 548 Interop demonstration and included testing I ISIS. 550 The information in this section is derived from reference [9]. 552 The following provides a broad summary of the scope of the 553 interoperability testing activities: 555 - NIST testing has involved 21 distinct ISs, representing 16 556 distinct models/products from 11 distinct 557 vendors/implementors (3Com, Cisco, Digital, Fibercom, IBM, 558 Novell, Phase2 Networks, Retix, Proteon, University of 559 Wisconsin, Wellfleet). The range of products tested has 560 spanned the spectrum from PC-based LAN routers to FDDI 561 capable backbone routers. 563 - IS-IS routers have been connected using LANs (802.3, 802.5, 564 and FDDI), point-to-point links (PPP, LAPB, and 565 proprietary) and X.25. To date, only the various LAN 566 technologies have been thoroughly tested with significant 567 multi-vendor interconnections. 569 - The testing environment has employed ESs from 7 vendors 570 (3Com, Apple, Digital, Hewlett-Packard, NCR, Novell, Sun 571 Microsystems). These ESs have been used to test the 572 interaction between host protocols (ES-IS, CLNP, IP, ICMP) 573 and the IS-IS routing protocol. 575 9.1. Interoperability Testing Methodology 577 NIST ISIS interoperability testing has been conducted on an 578 informal basis. The primary objectives of the testing has been 579 to foster mature commercial implementations of OSI-based routing 580 technology. No notions of official NIST certification or 581 endorsement are associated with this activity. 583 While the primary focus of the testing has been IS-IS 584 functionality, the testing also addresses aspects of the 585 operation of the corresponding data (i.e., CLNP and IP) and 586 supporting protocols (i.e., ES-IS, ICMP, ARP). 588 The interoperability testing sessions consist of several test 589 scenarios that focus on subsets of the protocol functionality. 590 Within each scenario, individual tests are executed by manually 591 altering: the physical configuration of the testbed, the logical 592 configuration of ISs, and/or the flow of data traffic across the 593 testbed. 595 9.1.1. Protocol Functions Tested 597 Individual interoperability tests are selected to exercise 598 specific protocol functions. The functions addressed by NIST 599 testing include: 601 - IS Adjacencies - L1/L2 IS adjacency acquisition. Primarily 602 tested on LANs, issues tested include: area boundaries, 603 area address computation, protocols supported, 604 authentication. Configurations of 10, or more, ISs 605 adjacencies on a single lan have been tested at L1 and L2. 607 - Designated IS (DIS) Election - L1/L2 LAN DIS functions. 608 Issues tested include: DIS priority election, resignation, 609 crash, pseudo node generation and sequence number 610 processing. 612 - Link State Data Base Maintenance - L1/L2 update process 613 functions. Issues tested included: event driven and 614 periodic LSP generation, sequence number LSP processing, 615 LSP propagation, LSP lifetime control. 617 - ES Adjacencies - L1/ES-IS functions. Issues tested 618 include: dynamic ES adjacencies, area boundaries, manual ES 619 adjacencies, ES poll. Configurations with approximately 30 620 multi-vendor ES neighbors have been tested at L1. 622 - L1 Route Computation - L1 decision process functions. 623 Issues addressed include: minimum cost paths, routing to 624 dynamic and manual ES neighbors, computation of nearest L2 625 IS, equal cost multipaths, path pruning, overloaded ISs, 626 multiple metrics. Configurations with 10, or more, equal 627 cost paths have been tested. 629 - Reachable Address Prefix (RAP)s - L2 RAP configuration and 630 processing. Issues addressed include: internal and 631 external metrics, RAP reporting in LSPs, default routes. 633 - L2 Route Computation - L2 decision process functions. 634 Issues addressed include: area routes, prefix routes, path 635 preference, attached flag, partition detection. 636 Configurations with 10, or more, areas within a domain have 637 been tested. 639 - CLNP/IP Forwarding and other protocol Interactions - Issues 640 addressed include: route switching, error notifications, ES 641 redirection. 643 9.1.2. Evaluation of Interoperability 645 Evaluations of the results of interoperability tests are made 646 using various techniques. First order observation of the 647 protocols under test are usually made using the 648 console/management capabilities of individual ISs and protocol 649 analyzers attached to appropriate subnets. Second order 650 observations are made using data streams between ESs positioned 651 throughout the testbed. Observations of the following attributes 652 are typically made during testing: 654 - Reachability - Examination of individual IS forwarding 655 tables using console/management interface. Observations of 656 duplex data streams between ESs (e.g. ECHO/PING, remote 657 login, file transfer). 659 - Convergence Time - Maintenance of Transport level 660 connections during routing convergence. Observations of 661 rate controlled ECHO/PING sessions. 663 - Protocol Stability - Observations of protocol analyzers 664 during reconfigurations and stable periods. 666 - Protocol Efficiency - No serious attempt has been made to 667 assess protocol efficiency. Casual observations are made 668 using statistics maintained by individual ISs and 669 utilization measurements on protocol analyzers. 671 9.2. Testing Sessions 673 Participation in NIST interoperability testing has varied over 674 time. Likewise, the maturity of the implementations tested has 675 varied as new participants joined later sessions. In the 676 sections that follow the results and observations of various 677 sessions are documented. These results document the 678 implementations and specification errors/issues that were found 679 during the session. In many instances, implementation errors 680 were corrected and retested during a single session. In 681 instances in which an issue was raised in multiple sessions, it 682 is typically only documented once. 684 9.2.1. August 1991 DIS-level Implementation Testing 686 The first open lab was conducted August 12-16 1991 for the 687 purpose of testing early implementations of the Draft 688 International Standard (DIS) for IS-IS. The participants in this 689 session were: 3Com, Digital, Proteon, Wellfleet, and University 690 of Wisconsin (WISIS in GATED, running on a BSD 4.4 microvax). 691 For most of the participants the implementations under test were 692 relatively immature. 694 Testing primarily focused upon 802.3 LAN tests. Hardware 695 interface problems prevented successful testing on the FDDI LAN. 696 The testing covered the basic LAN capabilities, level 1 and 697 level 2 routing test scenarios. 699 The following implementation issues/errors were found during 700 testing: 702 - Multiple LSPs - Some implementations did not process 703 multiple LSPs from the same system correctly. Once systems 704 began generating non-zero numbered LSPs these systems 705 displayed various problems in LSDB synchronization. 707 - Unexpected PDU Encodings - Several simple PDU parsing 708 errors were found. Implementations that made novel use of 709 the PDU encoding rules (e.g., that place IS neighbors one 710 per TLV option, use non contiguous LSP numbers) revealed 711 some less than general parsing assumptions in 712 implementations. 714 - DIS/Pseudo Node Operation - Several implementation issues 715 were discovered with DIS/pseudo Node procedures, including: 717  Non DIS systems generating CSNs and responding to PSNs. 719  Systems not generating Pseudo Node PDUs correctly. 721  Systems not adjusting IIH Hello timers when DIS. 723  Few systems implement the ES poll function. 725 - Area Address Computation - Errors were found in the 726 computation of area addresses. Some implementations only 727 reported the set of manual area addresses. 729 - LSDB Synchronization - Several implementations had errors 730 in synchronizing LSP sequence numbers after a restart 731 (e.g., either ignored previous sequence number in old LSPs, 732 or counted by 1 up to the correct number). 734 - L1 Routing L2 IS - Several implementation errors were noted 735 related to the use of L2 attached bit and computation of 736 the nearest L2 IS. Some implementations did not correctly 737 set the attached bit, some set the attached bit when 738 configured L1-only, others did not recognize changes in 739 attached status of remote ISs during L1 SPF. Some systems 740 did not perform background SPF computations. 742 - L2 Routing - Some errors were found in implementation of 743 path precedence rules and Reachable Address Prefix (RAP) 744 processing of interesting prefixes (e.g., use of odd RAP 745 lengths, use of RAPs with IDI padding rules). 747 - ES-IS Redirection - Some errors were found in the ES-IS 748 redirect function (e.g., redirecting ISs, improper RD PDU 749 encodings). 751 The following specification issues/errors were found during 752 testing: 754 - Precedence of Routing Protocols - Questions arose relating 755 to the relative precedence of IS-IS and ES-IS derived 756 routing information. Some implementations assign routes 757 derived from ES-IS a higher precedence than those computed 758 by IS-IS. That is, CLNP PDUs are delivered to ESs over the 759 subnets to which they are directly attached while other 760 IS-IS paths with lesser cost exist. 762 The intention of the ISIS protocol specification is that 763 only routes computed by the protocol are used for 764 forwarding to end systems. Adjacencies to end systems 765 derived from ESIS are reported in the router's LSPs. Since 766 a router includes its own LSPs in its forwarding database 767 computation, routes to its adjacent end systems will be 768 computed. The shortest path from a router to an end system 769 will depend only on the metrics assigned to the circuits. 770 The relative preference of circuits can be controlled by 771 adjusting their metric through management parameters. This 772 has been clarified in the Integrated ISIS specification [2]. 773 This clarification is intended for submission as a defect 774 report to the base ISIS standard [5]. 776 - Redirection Based Upon RAPs - It was noted that issuing a 777 redirect as the result of forwarding based upon a RAP may 778 require the Network Entity Title (NET) of the next hop. 779 This information is not specified as part of the RAP 780 configuration information. It was also noted that if an NET 781 was specified, the SNPA and the "liveness" of the RAP next 782 hop could be determined using the ES-IS protocol. 784 The next hop's NET must be included in a Redirect if the 785 next hop is a router. This requires that the base ISIS 786 standard have an additional attribute in the Reachable 787 Address managed object which is set to the NET of the next 788 hop. A new attribute (nextHopNET) for the Reachable Address 789 managed object which can be set to the next hop NET is 790 defined in the Integrated ISIS specification [2]. An 791 equivalent object (isisRANextHopNET) has been added to the 792 Integrated ISIS MIB [3]. The default value of both of these 793 is an octetstring of length 1 with octet value zero. This 794 default means that Redirect PDUs will be encoded with a NET 795 field even though the NET value is not that of any system. 796 Some End systems use the presence or absence of the NET 797 field in the Redirect PDU to determine how to originate 798 packets for that destination, for example, the maximum PDU 799 size to use. This addition is intended for submission as a 800 defect report to the base ISIS standard [5]. 802 - ES Poll - Some implementors that did not implement the ES 803 poll function did so intentionally noting that few ESs 804 support the ESCT option upon which the function is based. 805 It was noted that for the ES poll function to be effective 806 ESCT processing must be supported by ESs. 808 The problem with ESs not supporting the option is that 809 during a poll the router will adjust the timer for ES 810 adjacencies on the assumption that ESs will respond to the 811 poll. If they do not process the ESCT option then their 812 adjacencies will be timed out by the router and then 813 reformed later when the ESs send out their normal frequency 814 ES Hellos. Before being reformed those end systems will be 815 unreachable. The polling process is triggered when there 816 has been a routing topology change, since this may have 817 occurred when an extended LAN becomes partitioned on 818 failure of a bridge. In this case the router wants to 819 determine as quickly as possible the circuits through which 820 the end systems are reachable. To avoid the problem of end 821 systems that do not implement the option, a management 822 attribute has been added to each circuit which controls 823 whether existing end system adjacencies are timed out more 824 quickly (as defined by the poll function) or left to time 825 out with their current holding time. The new attribute is 826 useESConfigurationPolling in the base ISIS standard [5] and 827 is isisCircESPolling in the MIB [3]. The default value for 828 these is to not do polling. This addition is intended for 829 submission as a defect report to the base ISIS standard [5]. 831 9.2.2. February 1992 IS-level Implementation Testing 833 The second open lab was conducted February 24-28 1992 for the 834 purpose of testing implementations of the recently finalized 835 International Standard (IS) version IS-IS. The participants in 836 this session were: 3Com, Digital, Fibercom, Proteon, Wellfleet, 837 Cisco, Retix, Novell. 839 Testing primarily focused upon 802.3, and FDDI LAN tests. The 840 testing covered the basic LAN capabilities, level 1 and level 2 841 routing test scenarios. The maturity level of the 842 implementations, including those participating for the first 843 time, was significantly higher than in the previous open lab. 844 This allowed more time for testing additional, secondary 845 features of the protocol, including: 847 - Authentication features. 849 - Overloaded ISs. 851 - Partition Repair. 853 During this open-lab session, the NIST IS-IS Multiparty 854 Conformance Test Systems was demonstrated operating upon vendor 855 implementations. Experimental conformance test suites for the 856 subnetwork and update processes were executed. 858 The following implementation issues/errors were found during 859 testing: 861 - Circuit State Changes - Some implementations were unable to 862 determine the status of circuits in some situations (e.g., 863 serial circuits marked external). Some implementations 864 failed to reflect changes in circuit states in their LSPs 865 (e.g., failure of event driven LSP to drop IS neighbors or 866 RAPs lost due to circuit state changes). 868 - Multi-pathing - Configurations with up to 10 equal cost 869 multipaths revealed some SPF implementation/scaling errors. 871 - Overloaded ISs - Some implementations completely ignore 872 LSDB overload state in ISs. In those that recognized the 873 state, there were differences in implementation of this 874 feature (see specification issues below). 876 The following specification issues/errors were found during 877 testing: 879 - IIH Padding - Discrepancies in configured data link block 880 sizes on FDDI initially prevented IS adjacency acquisition. 881 The IS with the smaller configured data link block size was 882 capable of receiving larger IIHs, but the other IS would 883 reject IIHs that were padded to a smaller block size than 884 its own. Questions arose regarding whether PAD length 885 checks are required upon receipt of IIHs. 887 The Integrated ISIS specification [2] has been clarified to 888 state that no check is made on the padded length of 889 received IIHs. The purpose of the padding is to ensure that 890 ISIS protocol packets of maximum size can traverse the 891 transmission path between the neighbors (which may be an 892 extended LAN made up of different media). It is not 893 necessary that neighbors have the same data link block 894 size. This clarification is intended for submission as a 895 defect report to the base ISIS standard [5]. 897 In addition a new management attribute has been defined in 898 the Integrated ISIS specification [2] and the GDMO in ISO 899 10589 and to the I ISIS MIB which controls whether ISIS 900 Hellos transmitted on a broadcast circuit are padded. The 901 use of padding can cause significant overhead, for example, 902 over remote bridging using low bandwidth WAN links. 904 - Area Addresses - Questions arose as to the use of computed 905 area addresses in uses other than IS-IS PDUs. In 906 particular questions arose as to: 908  If dynamic ES adjacencies should be rejected if they 909 match a manual area address that has been dropped. 911 If a manual area address is dropped from the area this 912 indicates a configuration error since the result will 913 be that reachability to some systems may be lost, since 914 that area address will not be announced at level 2. The 915 Integrated ISIS specification [2] has been clarified to 916 describe what is the effect of dropping a manual area 917 address on the parameter manualAreaAddresses (there is 918 no effect). 920  For the purposes of forwarding and lowest NET 921 computation some interpretations varied, with different 922 implementations using: the manual area addresses, the 923 computed area addresses, the union of both. 925 The Integrated ISIS specification [2] has been 926 clarified to make it clearer in the forwarding 927 description which area addresses are used (the set 928 defined by the areaAddresses parameter). 930 - Routing Through an Overloaded IS - There were some 931 questions regarding the description of SPF computation in 932 the presence of an overloaded IS. While the text implies 933 that one should consider ES adjacencies on the other side 934 of an overloaded IS, some implementations will not compute 935 the SPF through the overloaded IS to the pseudo node (which 936 contains the LSP for the dynamic ES adjacencies). Such 937 implementations will only compute routes to the the manual 938 ES adjacencies of an overloaded IS. 940 The purpose of including ES adjacencies of an overloaded 941 router in the SPF computation is really just to maintain a 942 path to the overloaded router itself, since a router 943 announces its own ID as reachable in its level 1 LSP ES 944 neighbor options. This path is needed so that management 945 traffic can reach the overloaded router. During overload, 946 reachability to other systems in the area or domain is 947 affected and it doesn't seem worthwhile adding extra 948 complexity to the SPF computation to try and keep 949 reachability to end systems through an overloaded router. 950 The SPF algorithm in the base standard is not very clear 951 about this and so some clarifying text has been added to 952 explain the behaviour. What happens is that the LAN end 953 systems will be reachable through non-overloaded routers on 954 the LAN, but will not be reachable through any overloaded 955 routers including the designated router itself (if it is 956 overloaded). If the designated router is overloaded it sets 957 the "infinite hippity cost" bit in its pseudonode LSPs and 958 its own LSPs. Therefore a path through the designated 959 router is not computed because its reachability to the 960 pseudonode is blocked. 962 - Partition Repair - In attempting to test the partition 963 repair function it became obvious that the description of 964 partition repair forwarding had the real potential for 965 routing loops. In the two sets of modifications to the 966 standard to add descriptions of precedence of routes and 967 make partition repair optional the standard created a 968 potential looping condition in areas in which only some ISs 969 implement partition repair. 971 This problem has been clarified in the base ISIS standard 972 through the submission of defect reports which have been 973 agreed as part of Technical Corrigenda 1 and 2 [6 and 7]. 975 - Attached Bit in Single Area Domains - In testing inter-area 976 routing and computation of the nearest L2 IS discussion 977 arose as to the inability to support single area domains 978 with external RAPs. In particular, an L2 IS with RAPs 979 (e.g., default prefix) but no area routes will not identify 980 itself as attached. It was felt that this was a deficiency 981 in the protocol. 983 This has been clarified in the base ISIS standard through 984 the submission of a Defect Report which has been agreed as 985 part of Technical Corrigendum 1 [6]. The presence of any 986 Reachable Address Prefix causes the level 2 router to 987 consider itself as "attached". 989 9.2.3. Spring 1992 Interop Demonstration 991 The participants in NIST interoperability testing activities 992 demonstrated multi-vendor IS-IS interoperability at the spring 993 1992 Interop conference. The demonstration was conducted within 994 the NIST booth, with periodic (i.e., after hours) 995 interoperability testing with the shownet routers. The 996 participants in this demonstration were: 3Com, Digital, Cisco, 997 Proteon, and Phase 2 Networks. 999 The demonstration consisted primarily of L1/L2 route switching 1000 demonstrations across 802.3, and FDDI LAN tests. 1002 During the course of this demonstration one specification issue 1003 was raised: 1005 - DIS TOS Support - Questions arose as to whether the DIS 1006 should report support for all metrics in its pseudo node 1007 LSPs. Failure to do so causes some SPF implementations to 1008 abandon TOS paths that actually are contiguous. 1010 The problem here is that the designated router announces 1011 reachability to systems on the LAN on behalf of other 1012 routers on the same LAN, but the TOS supported by the 1013 routers may be different. Since all routers must support 1014 the default TOS, there will always be a default TOS path. 1015 However, if there were a path at a non-default TOS that 1016 were contiguous except for the pseudonode hop then that 1017 non-default TOS path could not be used - the default TOS 1018 path would be used. 1020 The solution is to have the designated router announce 1021 reachability at all TOS to LAN systems in its pseudonode 1022 LSPs even if that router is not configured to support one 1023 or more of those TOS. Since the announced cost in these 1024 LSPs is always zero, there is no problem of choosing the 1025 cost to use when doing this. This permits fully contiguous 1026 TOS paths to be computed through the pseudonode. This 1027 change has been added to the Integrated ISIS specification 1028 [2]. 1030 9.2.4. Fall 1992 Interop Demonstration Hot Stage 1032 An open lab was conducted in October 1992 for the purpose of hot 1033 staging the fall 1992 Interop integrated IS-IS multi-vendor 1034 demonstration. The direct participants in this session were: 1035 3Com, Digital, Cisco, Proteon, and Phase 2 Networks. Most of 1036 the participants in this session had recently added Integrated 1037 support to their existing IS-IS implementations. 1039 Testing primarily focused upon 802.3, and FDDI LAN tests. 1041 The testing scenarios covered the basic LAN capabilities, level 1042 1 level 2 routing test scenarios. Given maturity level of the 1043 OSI capabilities of the implementations under test, most effort 1044 was directed at testing those IP capabilities required for the 1045 upcoming Interop demonstration. 1047 The following implementation issues/errors were found during 1048 testing: 1050 - L2 Reachability Summarization - Some implementations 1051 reported configured address summaries when there was no 1052 corresponding internal reachability. 1054 - Nearest L2 IS and L1 Default Routes - Some implementations 1055 did not correctly establish a default route to the nearest 1056 L2 IS. Also, some implementations did not replace the route 1057 to the nearest L2 IS with announced L1 default routes. 1059 The following specification issues/errors were found during 1060 testing: 1062 - Precedence of Routes - There were some questions regarding 1063 the relative precedence of I-IS-IS derived routes and 1064 directly attached interfaces. In particular, some 1065 implementations chose to treat local direct interfaces at a 1066 higher priority than I-IS-IS derived routes. Thus, 1067 longer-match or lesser cost I-IS-IS derived routes are 1068 ignored when the destination appears to be on the locally 1069 attached subnet. 1071 As with end system adjacencies, routes derived from the 1072 router's local interfaces are reported in the router's LSPs 1073 and will be included in the shortest paths computation. 1075 There is no need to have preference controls for local 1076 routes versus Integrated ISIS derived routes. Text has been 1077 added to the Integrated ISIS specification [2] to make this 1078 clear. 1080 - Reporting Interfaces on Which I-IS-IS is disabled - 1081 Questions arose as to whether an interface over which 1082 I-IS-IS is not operating should be reported as reachable? 1084 There are two ways that the IP reachability information 1085 attached to an interface get announced in LSPs. First, some 1086 or all of the addresses of the router on its interfaces are 1087 announced in the "IP Interface Address" options in LSPs so 1088 that other routers learn one or more addresses for the 1089 router. Second, the subnet addresses (IP address and mask) 1090 associated with each interface are announced in the 1091 router's "IP internal Reachability Information" options. In 1092 both cases, IP reachability information can be included 1093 even if the interface it is attached to does not have I 1094 ISIS enabled. A router may provide configuration controls 1095 to determine which information is announced in LSPs. For 1096 interface addresses, this must default to announcing at 1097 least one address from any of the router's interface 1098 regardless of the state of I ISIS on that interface. For 1099 subnet addresses this must default to announcing all subnet 1100 addresses from all the router's interfaces regardless of 1101 the state of I ISIS on that interface. Clarifying text has 1102 been added to the Integrated ISIS specification [2]. 1104 10. References 1106 [1]Callon, R.W., "Use of OSI IS-IS for Routing in TCP/IP and 1107 dual environments", RFC 1195, December 1990. 1109 [2]Callon, R.W., "Use of OSI IS-IS for Routing in TCP/IP and 1110 dual environments", Internet-draft 1111 draft-ietf-isis-tcpip-01.txt, July, 1994 (obsoletes RFC 1112 1195) 1114 [3]Gunner, C.W., "Integrated IS-IS Management Information Base", 1115 Internet-draft draft-ietf-isis-mib-04.txt, July, 1994. 1117 [4]Gunner, C.W., "Integrated IS-IS Protocol Analysis", 1118 Internet-draft draft-ietf-isis-prot-anal-00.txt, March, 1119 1994. 1121 [5]"Information Technology - Telecommunications and information 1122 exchange between systems - Intermediate system to 1123 Intermediate system Intra-Domain routeing exchange protocol 1124 for use in Conjunction with the Protocol for providing the 1125 Connectionless-mode Network Service (ISO 8473)", 1126 International Standard 10589 (ISO submission copy), October 1127 1991. 1129 [6]International Standard 10589 - Technical Corrigendum 1 1131 [7]International Standard 10589 - Technical Corrigendum 2 1133 [8]"Information Technology - Telocommunications and information 1134 exchange between systems - Elements of Management 1135 Information Related to OSI Network Layer Standards", 1136 International Standard 10733 (ISO submission copy), 1137 September 1992. 1139 [9]Montgomery, D. "IS-IS Interoperability Testing at NIST", 1140 Draft, October 1993. 1142 11. Acknowledgements 1144 Thanks are due to members of the ISIS working group of the 1145 Internet Engineering Task Force (IETF) for their input to this 1146 document. Thanks are due especially to Ross Callon and Mike 1147 Shand for technical review. Doug Montgomery acknowledges support 1148 for the NIST interoperability testing work from the National 1149 Science Foundation (Contract No. NCR-9120054). 1151 12. Working Group Information 1153 The current co-chairs of the ISIS working group are: 1155 Ross Callon 1156 Wellfleet Communications Inc. 1157 2 Federal Street 1158 Billerica 1159 MA 01821 1160 USA 1162 Phone: (508) 436 3936 1163 Email: rcallon@wellfleet.com 1165 Chris Gunner 1166 Digital Equipment Corp. 1167 550 King Street 1168 Littleton 1169 MA 01460-1289 1170 USA 1171 Phone: (508) 486 7792 1172 Fax: (508) 486 5279 1173 Email: gunner@dsmail.enet.dec.com 1175 The working group mailing list is: 1177 isis@merit.edu 1179 Subscription requests should be sent to: 1181 isis-request@merit.edu 1183 13. Author's Addresses 1185 Chris Gunner 1186 (see co-chair information above for mail, etc.) 1188 Doug Montgomery 1189 National Institute of Standards and Technology (NIST) 1191 Phone: (301) 975 3630 1192 Fax: (301) 590 0932 1193 Email: dougm@osi.ncsl.nist.gov