From isis-wg-admin@spider.juniper.net Mon Sep 4 06:07:01 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01686 for ; Mon, 4 Sep 2000 06:07:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA06280; Mon, 4 Sep 2000 03:13:35 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA06251 for ; Mon, 4 Sep 2000 03:13:33 -0700 (PDT) Received: from cbin2-mail.cisco.com (cbin2-mail.cisco.com [192.135.246.72]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id DAA98976 for ; Mon, 4 Sep 2000 03:00:18 -0700 (PDT) (envelope-from rathi@cisco.com) Received: from cisco.com ([192.135.247.154]) by cbin2-mail.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA25248 for ; Mon, 4 Sep 2000 15:30:16 +0530 (IST) Message-ID: <39B37254.4DF728D2@cisco.com> Date: Mon, 04 Sep 2000 15:28:44 +0530 From: Ravindra Rathi X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net References: <200008211844.UAA12725@net4u.net4u.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Doubts in draft-ietf-isis-wg-mib-03.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hello all, I have few doubts as well as suggestions for the current version of this draft. Please go through them and let me know your comments. 1. Following object identifiers have "null" description clause in the draft a. isisSystem b. isisCirc c. isisIsAdj d isisReachAddr e. isisIPReachAddr f. isisIPDest Normally description clauses are not null. So either descriptions can be added to them. (The descriptions are already there in the draft before the start of the mib module.) or we can have just something like this. e.g isisSystem OBJECT IDENTIFIER ::= {isis 1 } isisCirc OBJECT IDENTIFIER ::= { isis 2 } etc. 2. At present, type TOS is defined as follows. TOS ::= INTEGER { default(1), delay(2), expense(3), error(4) } This could also have been a TEXTUAL-CONVENTION instead INTEGER. The same thing applies to type 'PathCost.' Am I missing something ? 3. For all of the following tables in the MIB, one of the indices of the table identifies the instance of Integrated IS-IS to which the particular row corresponds. Tables of interest are a. isisSysTable b. isis isisManAreaAddrTable c. isisAreaAddrTable d. isisSysProtSuppTable e. isisSummAddrTable Instead of each of these tables defining one object which acts as an index to identify the same thing (i.e instance of Integrated IS-IS), only one table can (say isisSysTable) define the object to identify the instance of the integrated IS-IS. Presently the object which identifies the instance of Integrated IS-IS in "isisSysTable" is "isisSysInstance". All other tables can use this object as an index(external indexing ) instead of defining their own object to serve the same purpose. Also by using the same object for indexing for all the tables consistency is maintained across the tables to identify the instance of Integrated IS-IS. 4. ResettingTimer behaviour definition The description there applies to objects who follow ResettingTimer behaviour. Defining TEXTUAL-CONVENTION can be better way of documenting the behaviour provided it is possible. I suppose this is not possible here. Same thing applies to "OperationalState behaviour definition". Also definition of these behaviours use the phrase "This object". I feel it would have been more appropriate to use the phrase "objects following this behaviour". 5. The description clause of many objects refer to "replaceOnlyWhile Disabled behaviour". But I was not able to find documentation for this behaviour in the draft. 6. Description clause of few objects is not very clear. e.g for "isisSysPartChanges" it is DESCRIPTION "partition changes". The above description not really indicates what aspect of "partition changes" is being managed by this object ? I might me missing something in above doubts. So please enlighten me with the same. Thanks Rathi -- Ravindra Rathi Cisco Systems "Waterford", #9, Brunton Road Bangalore-560 001 Tel: +91-80-532 1300 - 1306 x: 6315 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Sep 4 23:22:16 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11542 for ; Mon, 4 Sep 2000 23:22:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA07197; Mon, 4 Sep 2000 20:29:50 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA07122 for ; Mon, 4 Sep 2000 20:29:46 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.9.3) with ESMTP id UAA10199 for ; Mon, 4 Sep 2000 20:16:25 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id FAA00892 for isis-wg@external.juniper.net; Tue, 5 Sep 2000 05:17:39 +0200 Message-Id: <200009050317.FAA00892@kraak.procket.com> To: isis-wg@spider.juniper.net Date: Tue, 5 Sep 2000 05:17:39 +0200 (MEST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] FYI: just submitted draft-ietf-isis-traffic-03.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Submitted to internet-drafts@ietf.org, I guess it will show up in the drafts repository soon. Just a few minor changes to the previous version. Anyway, here it is for you already. Henk. ---- Network Working Group Tony Li INTERNET DRAFT Procket Networks Henk Smit Procket Networks September 2000 IS-IS extensions for Traffic Engineering Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1.0 Abstract This document describes extensions to the IS-IS protocol to support Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. 2.0 Introduction An IS-IS LSP is composed of a fixed header and a number of tuples, each consisting of a Type, a Length, and a Value. Such tuples are commonly known as TLVs, and are a good way of encoding information in a flexible and extensible format. The changes in this document include the design of new TLVs to replace the existing IS Neighbor TLV, IP Reachability TLV and add additional information. Mechanisms and procedures to migrate to the new TLVs are not discussed in this document. The primary goal of these extensions is to add more information about the characteristics of a particular link to an IS-IS's LSP. Secondary goals include increasing the dynamic range of the IS-IS metric and improving the encoding of IP prefixes. The router id is useful for traffic engineering purposes because it describes a single address that can always be used to reference a particular router. This document is a publication of the IS-IS Working Group within the IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual inclusion with ISO 10589. 3.0 The Traffic Engineering router ID TLV The Traffic Engineering router ID TLV is TLV type 134. The router ID TLV contains the 4-octet router ID of the router originating the LSP. This is useful in several regards: For traffic engineering, it guarantees that we have a single stable address that can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces. If OSPF is also active in the domain, traffic engineering can compute the mapping between the OSPF and IS-IS topologies. If a router advertises the Traffic Engineering router ID TLV in its LSP, and if it advertises BGP routes with the BGP next hop attribute set to the BGP router ID, in that case the Traffic Engineering router ID should be the same as the BGP router ID. Implementations MUST NOT inject a /32 prefix for the router ID into their forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this TLV. 4.0 The extended IP reachability TLV The extended IP reachability TLV is TLV type 135. The existing IP reachability TLV is a single TLV that carries IP prefixes in a format that is analogous to the IS neighbor TLV. It carries four metrics, of which only the default metric is commonly used. Of this, the default metric has a possible range of 0-63. This limitation is one of the restrictions that we would like to lift. In addition, route redistribution (a.k.a. route leaking) is a key problem that is not addressed by the existing IP reachability TLV. This problem occurs when an IP prefix is injected into a level one area, redistributed into level 2, subsequently redistributed into a second level one area, and then redistributed from the second level one area back into level two. This problem occurs because the path that the information can take forms a loop. The likely result is a forwarding loop. To address these issues, the proposed extended IP reachability TLV provides for a 32 bit metric and adds one bit to indicate that a prefix has been redistributed 'down' in the hierarchy. The proposed extended IP reachability TLV contains a new data structure, consisting of: 4 bytes of metric information 1 byte of control information, consisting of 1 bit of up/down information 1 bit indicating the existence of sub-TLVs 6 bits of prefix length 0-4 bytes of IPv4 prefix 0-250 optional octets of sub-TVLs, if present consisting of 1 octet of length of sub-TLVs 0-249 octets of sub-TLVs This data structure can be replicated within the TLV, not to exceed the maximum length of the TLV. The up/down bit shall be set to 0 when a prefix is first injected into IS-IS. If a prefix is redistributed from a higher level to a lower level (e.g. level two to level one), the bit shall be set to 1, to indicate that the prefix has travelled down the hierarchy. Prefixes that have the up/down bit set to 1 must not be redistributed. If a prefix is redistributed from an area to another area at the same level, then the up/down bit shall be set to 1. These semantics apply even if IS-IS is extended in the future to have additional levels. By insuring that prefixes follow only the IS-IS hierarchy, we have insured that the information does not loop, thereby insuring that there are no persistent forwarding loops. If there are no sub-TLVs associated with this IP prefix, the bit indicating the presence of sub-TVLs shall be set to 0. If this bit is set to 1, the first octet after the prefix will be interpreted as the length of sub-TLVs. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall extended IP reachability TLV. The practical maximum is 255 octets minus the 5-9 octets described above, or 250 octets. No sub- TLVs for the extended IP reachability TLV have been defined yet. The 6 bits of prefix length can have the values 0-32 and indicate the number of significant bits in the prefix. The prefix is encoded in the minimal number of bytes for the given number of significant bits. This implies: Significant bits Bytes 0 0 1-8 1 9-16 2 17-24 3 25-32 4 The remaining bits of prefix are transmitted as zero and ignored upon receipt. If an IP prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see below), this IP prefix should not be considered during the normal SPF computation. This will allow advertisment of an IP prefix for other purposes than building the normal IP routing table. 5.0 The extended IS reachability TLV The extended IS reachability TLV is TLV type 22. The existing IS reachability TLV is a single TLV that contains information about a series of IS neighbors. For each neighbor, there is a structure that contains the default metric, the delay, the monetary cost, the reliability, and the 7-octet ID of the adjacent neighbor. Of this information, the default metric is commonly used. The default metric is currently one octet, with one bit used to indicate that the metric is present and one bit used to indicate whether the metric is internal or external. The remaining 6 bits are used to store the actual metric, resulting a possible metric range of 0-63. This limitation is one of the restrictions that we would like to lift. The remaining three metrics (delay, monetary cost, and reliability) are not commonly implemented and reflect unused overhead in the TLV. The neighbor is identified by its system Id (typically 6-octets), plus one octet to indicate the pseudonode number if the neighbor is on a LAN interface. Thus, the existing TLV consumes 11 octets per neighbor, with 4 octets for metric and 7 octets for neighbor identification. To indicate multiple adjacencies, this structure is repeated within the IS reachability TLV. Because the TLV is limited to 255 octets of content, a single TLV can describe up to 23 neighbors. The IS reachability TLV can be repeated within the LSP fragments to describe further neighbors. The proposed extended IS reachability TLV contains a new data structure, consisting of 7 octets of system Id and pseudonode number 3 octets of default metric 1 octet of length of sub-TLVs 0-244 octets of sub-TLVs Thus, if no sub-TLVs are used, the new encoding requires 11 octets and can contain up to 23 neighbors. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall IS reachability TLV. The practical maximum is 255 octets minus the 11 octets described above, or 244 octets. Further, there is no defined mechanism for extending the sub-TLV space for a particular neighbor. Thus, wasting sub-TLV space is discouraged. The metric octets are encoded as a 24-bit unsigned integer. Note that the metric field in the new extended IP reachability TLV is encoded as a 32-bit unsigned integer. These different sizes were chosen so that it is very unlikely that the cost of an intra-area route has to be chopped off to fit in the metric field of an inter-area route. To preclude overflow within an SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC shall be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25). If a link is advertised with the maximum link metric (2^24 - 1), this link should not be considered during the normal SPF computation. This will allow advertisment of a link for other purposes than building the normal Shortest Path Tree. An example is a link that is available for traffic engineering, but not for hop-by-hop routing. Certain sub-TLVs are proposed here: Sub-TLV type Length (octets) Name 3 4 Administrative group (color) 6 4 IPv4 interface address 8 4 IPv4 neighbor address 11 32 Unreserved bandwidth 18 3 TE Default metric Each of these sub-TLVs is described below. Unless stated otherwise, multiple occurrences of the information are supported by multiple inclusions of the sub-TLV. 5.1 Sub-TLV 3: Administrative group (color, resource class) The administrative group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. By convention the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'. 5.2 Sub-TLV 6: IPv4 interface address This sub-TLV contains a 4-octet IPv4 address for the interface described by the (main) TLV. This sub-TLV can occur multiple times. If the interface being advertised for Traffic Engineering purposes is unnumbered, the IPv4 interface address sub-TLV is set to the router ID of the advertising router. In combination with the IPv4 neighbor address sub-TLV this identifies the unnumbered link over which the advertised adjacency has been established. Implementations MUST NOT inject a /32 prefix for the interface address into their routing or forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV. If a router implements the basic TLV extensions in this document, it is free to add or omit this sub-TLV to the description of an adjacency. If a router implements traffic engineering, it must include this sub-TLV. 5.3 Sub-TLV 8: IPv4 neighbor address This sub-TLV contains a single IPv4 address for a neighboring router on this link. This sub-TLV can occur multiple times. If the interface being advertised for Traffic Engineering purposes is unnumbered, the first two octets of the IPv4 neighbor address sub-TLV are set to zero and the next two octets are set to the interface ID of the unnumbered interface. In combination with the IPv4 interface address sub-TLV this identifies the unnumbered link over which the advertised adjacency has been established. Implementations MUST NOT inject a /32 prefix for the neighbor address into their routing or forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV. If a router implements the basic TLV extensions in this document, it is free to add or omit this sub-TLV to the description of an adjacency. If a router implements traffic engineering, it must include this sub-TLV on point-to-point adjacencies. 5.4 Sub-TLV 11: Unreserved bandwidth This sub-TLV contains the amount of bandwidth reservable on this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link. Because of the need for priority and preemption, each head end needs to know the amount of reserved bandwidth at each priority level. Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. The units are bytes (not bits!) per second. The values correspond to the bandwidth that can be reserved with a holding of priority 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub-TLV, and priority 7 at the end of the sub-TLV. For stability reasons, rapid changes in the values in this sub-TLV should not cause rapid generation of LSPs. 5.5 Sub-TLV 18: Traffic Engineering Default metric This sub-TLV contains a 24-bit unsigned integer. This metric is administratively assigned and can be used to present a differently weighted topology to traffic engineering SPF calculations. To preclude overflow within an SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC shall be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25). If a link is advertised without this sub-TLV, traffic engineering SPF calculations must use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV. 6.0 Security Considerations This document raises no new security issues for IS-IS. 7.0 Acknowledgments The authors would like to thank Yakov Rekhter and Dave Katz for their comments on this work. 8.0 References [1] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September 1999. [2] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)" [Also republished as RFC 1142] [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R.W. Callon, Dec. 1990 9.0 Authors' Addresses Tony Li Procket Networks, Inc. 3850 North First Street San Jose, CA 95134 Email: tli@procket.com Voice: +1 408 9547900 Fax: +1 408 9876166 Henk Smit Procket Networks, Inc. 3850 North First Street San Jose, CA 95134 Email: henk@procket.com Voice: +1 408 9547900 Fax: +1 408 9876166 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Sep 6 06:49:23 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07124 for ; Wed, 6 Sep 2000 06:49:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA09126; Wed, 6 Sep 2000 03:58:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA09094 for ; Wed, 6 Sep 2000 03:58:12 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id DAA35508 for ; Wed, 6 Sep 2000 03:44:43 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06876; Wed, 6 Sep 2000 06:44:40 -0400 (EDT) Message-Id: <200009061044.GAA06876@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mpls@uu.net, te-wg@uu.net, ospf@discuss.microsoft.com, isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Sep 2000 06:44:37 -0400 Subject: [Isis-wg] I-D ACTION:draft-dharanikota-interarea-mpls-te-ext-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF, IS-IS, RSVP, CR-LDP Extensions to Support Inter-Area Traffic Engineering Using MPLS TE Author(s) : S. Dharanikota, S. Venkatachalam Filename : draft-dharanikota-interarea-mpls-te-ext-00.txt Pages : 20 Date : 05-Sep-00 In this draft, we propose the extensions required to the routing protocols, signaling protocols, and the MIB to support the idea of inter-area LSPs. A companion document [INTER_AREA_FWK] provides the architectural requirements for such a concept. This document also provides the signaling extensions to support the crankback as defined in the architecture document [INTER_AREA_FWK]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dharanikota-interarea-mpls-te-ext-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dharanikota-interarea-mpls-te-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dharanikota-interarea-mpls-te-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000905135234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dharanikota-interarea-mpls-te-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-dharanikota-interarea-mpls-te-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000905135234.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Sep 6 06:49:24 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07125 for ; Wed, 6 Sep 2000 06:49:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA09064; Wed, 6 Sep 2000 03:57:37 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA09036 for ; Wed, 6 Sep 2000 03:57:36 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id DAA35502 for ; Wed, 6 Sep 2000 03:44:07 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06820; Wed, 6 Sep 2000 06:44:06 -0400 (EDT) Message-Id: <200009061044.GAA06820@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Sep 2000 06:44:06 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-traffic-02.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS extensions for Traffic Engineering Author(s) : T. Li, H. Smit Filename : draft-ietf-isis-traffic-02.txt Pages : 9 Date : 05-Sep-00 This document describes extensions to the IS-IS protocol to support Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-traffic-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-traffic-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000905135154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-traffic-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-traffic-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000905135154.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 7 11:53:02 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19380 for ; Thu, 7 Sep 2000 11:53:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA10786; Thu, 7 Sep 2000 08:58:01 -0700 (PDT) Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA10756 for ; Thu, 7 Sep 2000 08:57:59 -0700 (PDT) Received: from ORANLT (oran-home-isdn.cisco.com [171.69.210.10]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id IAA06295; Thu, 7 Sep 2000 08:44:20 -0700 (PDT) From: "David Oran" To: Date: Thu, 7 Sep 2000 11:44:20 -0400 Message-ID: <019101c018e2$7d3896b0$0ad245ab@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018E_01C018C0.F5C6AE40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This is a multi-part message in MIME format. ------=_NextPart_000_018E_01C018C0.F5C6AE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit For those of you who hate MSWORD, I append the text at the end of the message text as well. Are there other drafts they should fold it? If so, please craft a response and I'll get it to them. -----Original Message----- From: Matthew Deane [mailto:mdeane@ANSI.org] Sent: Thursday, September 07, 2000 11:35 AM To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; 'mankin@east.isi.edu' Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' Subject: JTC 1/SC 6 Liaison Statement on Routeing > Dear IETF Directors, > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the following > document is forwarded to IETF Routeing and Transport Area Directors for > consideration: > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) > > > Please do not hesitate to contact me should you have any questions. > > Sincerely, > > Matt Deane > JTC 1/SC 6 Secretariat > > <<06n1618.rtf>> SC 6 N 11618 Title: Liaison Report to the IETF Routing Area Director on 2nd CD for ISO/IEC 10589 (IS-IS Routing) Source: ISO/IEC JTC1/SC6 ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for ISO10589. SC6 intends to use this new version 2 as the base for adding the enhancements which have been requested by the IETF to optimise the use of ISO 10589 for Internet routing solutions. The IETF IS-IS WG convenor originally identified Internet Drafts: and as the source documents which specify these enhancements. SC6 invites the IETF to confirm that the above Internet Drafts are the correct references and to inform SC6 if there are additional IETF documents which refer to any other requirements for IS-IS Routing enhancements. SC6 would like to interact with the IETF on clarifying the detailed requirements in the hope that it may be possible to introduce them during the editing cycle for version 2 of the standard. To this end, we would like the Routing Area Directors to arrange an IS-IS BOF at the San Diego IETF meeting to discuss these requirements and how they can be incorporated into the new version of ISO 10586. SC6 will post an initial draft version of the new base document as an Internet Draft in August 2000 but this will not contain the changes requested by the IETF. A ballot closure date of February 2001 has been set for the 2nd CD Ballot to allow incorporation of final input on the Internet requirements if they can be agreed at the December 2000 IETF meeting. For information, the current instructions to the editor are that he should use ISO/IEC 10589:1992 as a base for editing, and shall apply the minimum textual changes mandated by the following TCs and DRs: ISO/IEC 10589:1992/Cor.1:1993 ISO/IEC 10589:1992/Cor.2:1996 ISO/IEC 10589:1992/Cor.3:1996 ISO/IEC 10589:1992/Amd 1:1996 6N10323 - Defect Reports 7-26 6N10659 - Defect Reports 27-34 6N10733 - Technical Corrigendum 4 The editor will also apply the minimal changes necessary to resolve additional Defect Reports 35-44. If SC6 and the IETF are unable to resolve the required changes, the Editor will add a temporary note to the cover page and the scope clause stating that: “ ISO 10589 does not currently include the extensions originally requested by the IETF in Internet Drafts: and . National Body and Liaison organization comments are invited to comment on the best way to progress these extensions.” ------=_NextPart_000_018E_01C018C0.F5C6AE40 Content-Type: application/msword; name="06n1618.rtf" Content-Disposition: attachment; filename="06n1618.rtf" Content-Transfer-Encoding: quoted-printable {\rtf1\ansi\ansicpg1252\uc1 = \deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\p= anose 02020603050405020304}Times New Roman{\*\falt CG = Times};}{\f2\fmodern\fcharset0\fprq1{\*\panose = 02070309020205020404}Courier New;}} {\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue255= ;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red255= \green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\green= 128\blue128;\red0\green128\blue0; \red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red12= 8\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar\adju= stright \fs20\cgrid \snext0 Normal;}{\*\cs10 \additive Default Paragraph = Font;}{\s15\nowidctlpar \tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7672\tx8631\tx9590= \adjustright \f2\fs20 \sbasedon0 \snext15 Preformatted;}}{\info{\title = Ethan Frome}{\author EW/LN/CB}{\keywords Ethan}{\operator Matthew = Deane}{\creatim\yr2000\mo6\dy9\hr18\min52} {\revtim\yr2000\mo6\dy16\hr14\min3}{\version3}{\edmins1}{\nofpages2}{\nof= words533}{\nofchars3040}{\*\company Lucent = Technologies}{\nofcharsws3733}{\vern89}} \widowctrl\ftnbj\aenddoc\noxlattoyen\expshrtn\noultrlspc\dntblnsbdb\nospa= ceforul\hyphcaps0\formshade\viewkind4\viewscale100\pgbrdrhead\pgbrdrfoot = \fet0\sectd \linex0\endnhere\sectdefaultcl = {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}} {\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta = .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta = .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta = )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}} {\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}}{\*\pnseclvl9 \pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain = \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx76= 72\tx8631\adjustright \f2\fs20 {\tab \tab \tab }{ Telecommunications and Information =20 \par Exchange Between Systems = =20 \par=20 \par=20 \par ISO/IEC JTC 1/SC06 N 11618 =20 \par=20 \par DATE: 2000-06-16 =20 \par=20 \par REPLACES =20 \par=20 \par DOC TYPE: \par Outgoing Liaison Statement =20 \par=20 \par TITLE: \par Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) = =20 \par=20 \par SOURCE: \par SC 6/WG 7 Convener = =20 \par=20 \par PROJECT: =20 \par=20 \par STATUS: \par Per SC 6 Prague Resolution 6.7.7, this document is forwarded to = IETF =20 \par for consideration. = =20 \par=20 \par ACTION ID: ACT=20 \par=20 \par DUE DATE: =20 \par=20 \par DISTRIBUTION: P & L Members; SC Chair; WG Conveners and = Secretaries =20 \par=20 \par=20 \par MEDIUM: =20 \par=20 \par DISKETTE NO.: =20 \par=20 \par NO. OF PAGES: 1 =20 \par=20 \par=20 \par ISO/IEC JTC 1/SC 6 Secretariat = =20 \par ANSI, 11 W. 42nd Street, New York, NY 10036, USA = =20 \par }\pard = \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx76= 72\tx8631\adjustright {Tel: +1 212 642 4992; Fax: +1 212 84}{0 2298; = E-mail: }{mdeane@ansi.org}{\tab \tab \tab \tab \tab \tab = \tab }{\b\fs28=20 \par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\b\fs28 \page=20 \par \tab \tab \tab \tab \tab \tab \tab \tab \tab SC 6 N 11618 \par }{ \par }{\b Title: Liaison Report to the IETF Routing Area Director on = 2}{\b\super nd}{\b CD for ISO/IEC 10589 (IS-IS Routing) \par=20 \par Source: ISO/IEC JTC1/SC6 \par }{ \par ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for = ISO10589. SC6 intends to use this new version 2 as the base for adding = the enhancements which have been requested by the IETF=20 to optimise the use of ISO 10589 for Internet routing solutions. The = IETF IS-IS WG convenor originally identified Internet Drafts: = and as = the source documents which specify these enhanceme nts. SC6 invites the IETF to confirm that the above Internet Drafts = are the correct references and to inform SC6 if there are additional = IETF documents which refer to any other requirements for IS-IS Routing = enhancements. \par=20 \par SC6 would like to interact wit h the IETF on clarifying the detailed requirements in the hope that it = may be possible to introduce them during the editing cycle for version = 2 of the standard. To this end, we would like the Routing Area = Directors to arrange an IS-IS BOF at the San Di ego IETF meeting to discuss these requirements and how they can be = incorporated into the new version of ISO 10586. \par=20 \par SC6 will post an initial draft version of the new base document as = an Internet Draft in August 2000 but this will not contain the changes r equested by the IETF. A ballot closure date of February 2001 has been = set for the 2nd CD Ballot to allow incorporation of final input on the = Internet requirements if they can be agreed at the December 2000 IETF = meeting.=20 \par=20 \par For information, the current instructions to the editor are that he = should use ISO/IEC 10589:1992 as a base for editing, and shall apply the = minimum textual changes mandated by the following TCs and DRs: \par=20 \par ISO/IEC 10589:1992/Cor.1:1993 \par ISO/IEC 10589:1992/Cor.2:1996 \par ISO/IEC 10589:1992/Cor.3:1996 \par ISO/IEC 10589:1992/Amd 1:1996 \par 6N10323 - Defect Reports 7-26 \par 6N10659 - Defect Reports 27-34 \par 6N10733 - Technical Corrigendum 4 \par The editor will also apply the minimal changes necessary to = resolve additional Defect Reports 35-44. \par=20 \par If SC6 and the IETF are unable to resolve the required changes, the = Editor will add a temporary note to the cover page and the scope clause = stating that: \ldblquote=20 ISO 10589 does not currently include the extensions originally = requested by the IETF in Internet D rafts: and = . National Body and Liaison = organization comments are invited to comment on the best way to progress = these extensions.\rdblquote=20 \par=20 \par=20 \par }} ------=_NextPart_000_018E_01C018C0.F5C6AE40-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 7 16:26:20 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26398 for ; Thu, 7 Sep 2000 16:26:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA11111; Thu, 7 Sep 2000 13:36:45 -0700 (PDT) Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA11081 for ; Thu, 7 Sep 2000 13:36:43 -0700 (PDT) Received: from ORANLT (oran-home-isdn.cisco.com [171.69.210.10]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id NAA26100 for ; Thu, 7 Sep 2000 13:23:03 -0700 (PDT) From: "David Oran" To: "ISIS WG" Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing Date: Thu, 7 Sep 2000 16:23:02 -0400 Message-ID: <01ca01c01909$6c57fe40$0ad245ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net X-MIME-Autoconverted: from 8bit to quoted-printable by external.juniper.net id NAA11111 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA26398 Copying the WG... -----Original Message----- From: Henk Smit [mailto:henk@Procket.com] Sent: Thursday, September 07, 2000 3:50 PM To: David Oran Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > For those of you who hate MSWORD, I append the text at the end of the > message text as well. Thank you, I appreciate it ! Pretty weird that a standards body like ISO is using a proprietary files format. ;-) > Are there other drafts they should fold it? If so, please craft a > response and I'll get it to them. draft-ietf-isis-dyname-02.txt is not a draft anymore. It is now an RFC: RFC2763. I have just submitted a new version of draft-ietf-isis-traffic-01.txt, draft-ietf-isis-traffic-02.txt. It might be a while before it becomes an RFC. And what about RFC1195 itself ? There is no mention that this RFC will be incorporated ? If RFC1195 is incorporated, there is one more ISIS draft that I would like to see added. Tony Li, Tony Prziegynda and myself are also authors of a draft that is related. draft-ietf-isis-domain-wide-02.txt. It is slated to be an RFC pretty soon, just waiting for the RFC editor to process it. If 10589 is including IP specific stuff, I think this one should be incorporated too. Henk. > -----Original Message----- > From: Matthew Deane [mailto:mdeane@ANSI.org] > Sent: Thursday, September 07, 2000 11:35 AM > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > 'mankin@east.isi.edu' > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > Dear IETF Directors, > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the following > > document is forwarded to IETF Routeing and Transport Area Directors > for > > consideration: > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > version) > > > > > > Please do not hesitate to contact me should you have any questions. > > > > Sincerely, > > > > Matt Deane > > JTC 1/SC 6 Secretariat > > > > <<06n1618.rtf>> > > > SC 6 N 11618 > > Title: Liaison Report to the IETF Routing Area Director on 2nd CD for > ISO/IEC 10589 (IS-IS Routing) > > Source: ISO/IEC JTC1/SC6 > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for ISO10589. > SC6 intends to use this new version 2 as the base for adding the > enhancements which have been requested by the IETF to optimise the use > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG convenor > originally identified Internet Drafts: > and as the source documents which > specify these enhancements. SC6 invites the IETF to confirm that the > above Internet Drafts are the correct references and to inform SC6 if > there are additional IETF documents which refer to any other > requirements for IS-IS Routing enhancements. > > SC6 would like to interact with the IETF on clarifying the detailed > requirements in the hope that it may be possible to introduce them > during the editing cycle for version 2 of the standard. To this end, > we would like the Routing Area Directors to arrange an IS-IS BOF at the > San Diego IETF meeting to discuss these requirements and how they can be > incorporated into the new version of ISO 10586. > > SC6 will post an initial draft version of the new base document as an > Internet Draft in August 2000 but this will not contain the changes > requested by the IETF. A ballot closure date of February 2001 has been > set for the 2nd CD Ballot to allow incorporation of final input on the > Internet requirements if they can be agreed at the December 2000 IETF > meeting. > > For information, the current instructions to the editor are that he > should use ISO/IEC 10589:1992 as a base for editing, and shall apply the > minimum textual changes mandated by the following TCs and DRs: > > ISO/IEC 10589:1992/Cor.1:1993 > ISO/IEC 10589:1992/Cor.2:1996 > ISO/IEC 10589:1992/Cor.3:1996 > ISO/IEC 10589:1992/Amd 1:1996 > 6N10323 - Defect Reports 7-26 > 6N10659 - Defect Reports 27-34 > 6N10733 - Technical Corrigendum 4 > The editor will also apply the minimal changes necessary to resolve > additional Defect Reports 35-44. > > If SC6 and the IETF are unable to resolve the required changes, the > Editor will add a temporary note to the cover page and the scope clause > stating that: “ ISO 10589 does not currently include the extensions > originally requested by the IETF in Internet Drafts: > and . > National Body and Liaison organization comments are invited to comment > on the best way to progress these extensions.” > > ------=_NextPart_000_018E_01C018C0.F5C6AE40 > Content-Type: application/msword; > name="06n1618.rtf" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: attachment; > filename="06n1618.rtf" > > {\rtf1\ansi\ansicpg1252\uc1 = > \deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\ p= > anose 02020603050405020304}Times New Roman{\*\falt CG = > Times};}{\f2\fmodern\fcharset0\fprq1{\*\panose = > 02070309020205020404}Courier New;}} > {\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue25 5= > ;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red25 5= > \green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\gree n= > 128\blue128;\red0\green128\blue0; > \red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red1 2= > 8\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar\adj u= > stright \fs20\cgrid \snext0 Normal;}{\*\cs10 \additive Default Paragraph = > Font;}{\s15\nowidctlpar > \tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7672\tx8631\tx959 0= > \adjustright \f2\fs20 \sbasedon0 \snext15 Preformatted;}}{\info{\title = > Ethan Frome}{\author EW/LN/CB}{\keywords Ethan}{\operator Matthew = > Deane}{\creatim\yr2000\mo6\dy9\hr18\min52} > {\revtim\yr2000\mo6\dy16\hr14\min3}{\version3}{\edmins1}{\nofpages2}{\no f= > words533}{\nofchars3040}{\*\company Lucent = > Technologies}{\nofcharsws3733}{\vern89}} > \widowctrl\ftnbj\aenddoc\noxlattoyen\expshrtn\noultrlspc\dntblnsbdb\nosp a= > ceforul\hyphcaps0\formshade\viewkind4\viewscale100\pgbrdrhead\pgbrdrfoot = > \fet0\sectd \linex0\endnhere\sectdefaultcl = > {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}} > {\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta = > .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta = > .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta = > )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}} > {\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}}{\*\pnseclvl9 > \pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain = > \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 6= > 72\tx8631\adjustright \f2\fs20 {\tab \tab \tab }{ > Telecommunications and Information =20 > \par Exchange Between Systems = > =20 > \par=20 > \par=20 > \par ISO/IEC JTC 1/SC06 N 11618 =20 > \par=20 > \par DATE: 2000-06-16 =20 > \par=20 > \par REPLACES =20 > \par=20 > \par DOC TYPE: > \par Outgoing Liaison Statement =20 > \par=20 > \par TITLE: > \par Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) = > =20 > \par=20 > \par SOURCE: > \par SC 6/WG 7 Convener = > =20 > \par=20 > \par PROJECT: =20 > \par=20 > \par STATUS: > \par Per SC 6 Prague Resolution 6.7.7, this document is forwarded to = > IETF =20 > \par for consideration. = > =20 > \par=20 > \par ACTION ID: ACT=20 > \par=20 > \par DUE DATE: =20 > \par=20 > \par DISTRIBUTION: P & L Members; SC Chair; WG Conveners and = > Secretaries =20 > \par=20 > \par=20 > \par MEDIUM: =20 > \par=20 > \par DISKETTE NO.: =20 > \par=20 > \par NO. OF PAGES: 1 =20 > \par=20 > \par=20 > \par ISO/IEC JTC 1/SC 6 Secretariat = > =20 > \par ANSI, 11 W. 42nd Street, New York, NY 10036, USA = > =20 > \par }\pard = > \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 6= > 72\tx8631\adjustright {Tel: +1 212 642 4992; Fax: +1 212 84}{0 2298; = > E-mail: }{mdeane@ansi.org}{\tab \tab \tab \tab \tab \tab = > \tab }{\b\fs28=20 > \par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\b\fs28 \page=20 > \par \tab \tab \tab \tab \tab \tab \tab \tab \tab SC 6 N 11618 > \par }{ > \par }{\b Title: Liaison Report to the IETF Routing Area Director on = > 2}{\b\super nd}{\b CD for ISO/IEC 10589 (IS-IS Routing) > \par=20 > \par Source: ISO/IEC JTC1/SC6 > \par }{ > \par ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for = > ISO10589. SC6 intends to use this new version 2 as the base for adding = > the enhancements which have been requested by the IETF=20 > to optimise the use of ISO 10589 for Internet routing solutions. The = > IETF IS-IS WG convenor originally identified Internet Drafts: = > and as = > the source documents which specify these enhanceme > nts. SC6 invites the IETF to confirm that the above Internet Drafts = > are the correct references and to inform SC6 if there are additional = > IETF documents which refer to any other requirements for IS-IS Routing = > enhancements. > \par=20 > \par SC6 would like to interact wit > h the IETF on clarifying the detailed requirements in the hope that it = > may be possible to introduce them during the editing cycle for version = > 2 of the standard. To this end, we would like the Routing Area = > Directors to arrange an IS-IS BOF at the San Di > ego IETF meeting to discuss these requirements and how they can be = > incorporated into the new version of ISO 10586. > \par=20 > \par SC6 will post an initial draft version of the new base document as = > an Internet Draft in August 2000 but this will not contain the changes r > equested by the IETF. A ballot closure date of February 2001 has been = > set for the 2nd CD Ballot to allow incorporation of final input on the = > Internet requirements if they can be agreed at the December 2000 IETF = > meeting.=20 > \par=20 > \par For information, the current instructions to the editor are that he = > should use ISO/IEC 10589:1992 as a base for editing, and shall apply the = > minimum textual changes mandated by the following TCs and DRs: > \par=20 > \par ISO/IEC 10589:1992/Cor.1:1993 > \par ISO/IEC 10589:1992/Cor.2:1996 > \par ISO/IEC 10589:1992/Cor.3:1996 > \par ISO/IEC 10589:1992/Amd 1:1996 > \par 6N10323 - Defect Reports 7-26 > \par 6N10659 - Defect Reports 27-34 > \par 6N10733 - Technical Corrigendum 4 > \par The editor will also apply the minimal changes necessary to = > resolve additional Defect Reports 35-44. > \par=20 > \par If SC6 and the IETF are unable to resolve the required changes, the = > Editor will add a temporary note to the cover page and the scope clause = > stating that: \ldblquote=20 > ISO 10589 does not currently include the extensions originally = > requested by the IETF in Internet D > rafts: and = > . National Body and Liaison = > organization comments are invited to comment on the best way to progress = > these extensions.\rdblquote=20 > \par=20 > \par=20 > \par }} > ------=_NextPart_000_018E_01C018C0.F5C6AE40-- > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 7 17:59:42 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28111 for ; Thu, 7 Sep 2000 17:59:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA11381; Thu, 7 Sep 2000 15:08:49 -0700 (PDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA11306 for ; Thu, 7 Sep 2000 15:08:45 -0700 (PDT) Received: from emailid-pc.cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA09579; Thu, 7 Sep 2000 14:55:02 -0700 (PDT) Message-Id: <4.2.0.58.20000907163021.00d0b980@127.0.0.1> X-Sender: mbartell@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 07 Sep 2000 16:57:25 -0500 To: "David Oran" , "ISIS WG" From: Micah Bartell Subject: Re: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing In-Reply-To: <01ca01c01909$6c57fe40$0ad245ab@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net X-MIME-Autoconverted: from 8bit to quoted-printable by external.juniper.net id PAA11381 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA28111 Folks, I will say that the only documents that I integrated into the ISO 10589 2nd edition were those specified in the "Instructions" from the ISO meeting in Prague. The changes consist of the following documents: ISO/IEC 10589:1992/Cor.1:1993 ISO/IEC 10589:1992/Cor.2:1996 ISO/IEC 10589:1992/Cor.3:1996 ISO/IEC 10589:1992/Amd 1:1996 6N10323 - Defect Reports 7-26 6N10659 - Defect Reports 27-34 6N10733 - Technical Corrigendum 4 The editor will also apply the minimal changes necessary to resolve additional Defect Reports 35-44. Regarding the changes proposed for DR 35-44, the SIF recommendation was used in place of these DRs. Nothing IP specific was added to ISO 10589. The question that the ISO is presenting here to the IETF as I understand it is: What does the IETF recommend as the best method moving forward to handle changes to the ISO spec by the IETF and how best should the IP specific information be handled? The ISO world does not seem intent upon making great sweeping changes to the spec, to the best of my knowledge and most new work is being handled within the IETF. I think it would be wise to develop a method for dealing with all IETF changes before setting the precedent of integrating ANY of the IETF ID's or RFC's directly into the spec. That document is already getting unwieldly in Word and if it is going to be accepting another 100 pages of material, it will very likely need to be restructured. The question of whether the ISO wishes to continue to maintain this spec also needs to be asked. If not, it may be possible to publish the ISO 10589 as a standards track RFC. This would likely require some modification to the structure of the document. ( Does an RFC really need 30 pages of complex conformance tables? ) Also the ISO 10589 spec is not friendly to a purely text based representation. These are just some of my thoughts on the matter. While, I am the current editor for the document, I am not presenting these suggestions as a "representative" of the ISO, or stating this to be their official position. I will investigate further making available the PDF version that I have of the 2nd Edition. This is pending a response from ANSI. /mpb At 04:23 PM 9/7/2000 -0400, David Oran wrote: >Copying the WG... > >-----Original Message----- >From: Henk Smit [mailto:henk@Procket.com] >Sent: Thursday, September 07, 2000 3:50 PM >To: David Oran >Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > > > > > For those of you who hate MSWORD, I append the text at the end of the > > message text as well. > > Thank you, I appreciate it ! > Pretty weird that a standards body like ISO is using a proprietary > files format. ;-) > > > Are there other drafts they should fold it? If so, please craft a > > response and I'll get it to them. > > draft-ietf-isis-dyname-02.txt is not a draft anymore. > It is now an RFC: RFC2763. > > I have just submitted a new version of draft-ietf-isis-traffic-01.txt, > draft-ietf-isis-traffic-02.txt. It might be a while before it becomes > an RFC. > > And what about RFC1195 itself ? There is no mention that this RFC > will be incorporated ? > > If RFC1195 is incorporated, there is one more ISIS draft that I would > like to see added. Tony Li, Tony Prziegynda and myself are also authors > of a draft that is related. draft-ietf-isis-domain-wide-02.txt. It is > slated to be an RFC pretty soon, just waiting for the RFC editor to > process it. If 10589 is including IP specific stuff, I think this one > should be incorporated too. > > Henk. > > > > > -----Original Message----- > > From: Matthew Deane [mailto:mdeane@ANSI.org] > > Sent: Thursday, September 07, 2000 11:35 AM > > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > > 'mankin@east.isi.edu' > > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > Dear IETF Directors, > > > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the >following > > > document is forwarded to IETF Routeing and Transport Area Directors > > for > > > consideration: > > > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > > version) > > > > > > > > > Please do not hesitate to contact me should you have any questions. > > > > > > Sincerely, > > > > > > Matt Deane > > > JTC 1/SC 6 Secretariat > > > > > > <<06n1618.rtf>> > > > > > > SC 6 N 11618 > > > > Title: Liaison Report to the IETF Routing Area Director on 2nd CD for > > ISO/IEC 10589 (IS-IS Routing) > > > > Source: ISO/IEC JTC1/SC6 > > > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for >ISO10589. > > SC6 intends to use this new version 2 as the base for adding the > > enhancements which have been requested by the IETF to optimise the use > > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG >convenor > > originally identified Internet Drafts: > > > and as the source documents which > > specify these enhancements. SC6 invites the IETF to confirm that the > > above Internet Drafts are the correct references and to inform SC6 if > > there are additional IETF documents which refer to any other > > requirements for IS-IS Routing enhancements. > > > > SC6 would like to interact with the IETF on clarifying the detailed > > requirements in the hope that it may be possible to introduce them > > during the editing cycle for version 2 of the standard. To this end, > > we would like the Routing Area Directors to arrange an IS-IS BOF at >the > > San Diego IETF meeting to discuss these requirements and how they can >be > > incorporated into the new version of ISO 10586. > > > > SC6 will post an initial draft version of the new base document as an > > Internet Draft in August 2000 but this will not contain the changes > > requested by the IETF. A ballot closure date of February 2001 has >been > > set for the 2nd CD Ballot to allow incorporation of final input on the > > Internet requirements if they can be agreed at the December 2000 IETF > > meeting. > > > > For information, the current instructions to the editor are that he > > should use ISO/IEC 10589:1992 as a base for editing, and shall apply >the > > minimum textual changes mandated by the following TCs and DRs: > > > > ISO/IEC 10589:1992/Cor.1:1993 > > ISO/IEC 10589:1992/Cor.2:1996 > > ISO/IEC 10589:1992/Cor.3:1996 > > ISO/IEC 10589:1992/Amd 1:1996 > > 6N10323 - Defect Reports 7-26 > > 6N10659 - Defect Reports 27-34 > > 6N10733 - Technical Corrigendum 4 > > The editor will also apply the minimal changes necessary to resolve > > additional Defect Reports 35-44. > > > > If SC6 and the IETF are unable to resolve the required changes, the > > Editor will add a temporary note to the cover page and the scope >clause > > stating that: “ ISO 10589 does not currently include the extensions > > originally requested by the IETF in Internet Drafts: > > and . > > National Body and Liaison organization comments are invited to comment > > on the best way to progress these extensions.” > > > > ------=_NextPart_000_018E_01C018C0.F5C6AE40 > > Content-Type: application/msword; > > name="06n1618.rtf" > > Content-Transfer-Encoding: quoted-printable > > Content-Disposition: attachment; > > filename="06n1618.rtf" > > > > {\rtf1\ansi\ansicpg1252\uc1 = > > >\deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\ >p= > > anose 02020603050405020304}Times New Roman{\*\falt CG = > > Times};}{\f2\fmodern\fcharset0\fprq1{\*\panose = > > 02070309020205020404}Courier New;}} > > >{\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue25 >5= > > >;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red25 >5= > > >\green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\gree >n= > > 128\blue128;\red0\green128\blue0; > > >\red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red1 >2= > > >8\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar\adj >u= > > stright \fs20\cgrid \snext0 Normal;}{\*\cs10 \additive Default >Paragraph = > > Font;}{\s15\nowidctlpar > > >\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7672\tx8631\tx959 >0= > > \adjustright \f2\fs20 \sbasedon0 \snext15 Preformatted;}}{\info{\title >= > > Ethan Frome}{\author EW/LN/CB}{\keywords Ethan}{\operator Matthew = > > Deane}{\creatim\yr2000\mo6\dy9\hr18\min52} > > >{\revtim\yr2000\mo6\dy16\hr14\min3}{\version3}{\edmins1}{\nofpages2}{\no >f= > > words533}{\nofchars3040}{\*\company Lucent = > > Technologies}{\nofcharsws3733}{\vern89}} > > >\widowctrl\ftnbj\aenddoc\noxlattoyen\expshrtn\noultrlspc\dntblnsbdb\nosp >a= > > >ceforul\hyphcaps0\formshade\viewkind4\viewscale100\pgbrdrhead\pgbrdrfoot >= > > \fet0\sectd \linex0\endnhere\sectdefaultcl = > > {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}} > > {\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta = > > .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta = > > .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta = > > )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta >= > > )}} > > {\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > > )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta >= > > )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb >(}{\pntxta = > > )}}{\*\pnseclvl9 > > \pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain >= > > >\s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 >6= > > 72\tx8631\adjustright \f2\fs20 {\tab \tab \tab }{ > > Telecommunications and Information >=20 > > \par Exchange Between Systems >= > > =20 > > \par=20 > > \par=20 > > \par ISO/IEC JTC 1/SC06 N 11618 =20 > > \par=20 > > \par DATE: 2000-06-16 =20 > > \par=20 > > \par REPLACES =20 > > \par=20 > > \par DOC TYPE: > > \par Outgoing Liaison Statement >=20 > > \par=20 > > \par TITLE: > > \par Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) >= > > =20 > > \par=20 > > \par SOURCE: > > \par SC 6/WG 7 Convener >= > > =20 > > \par=20 > > \par PROJECT: =20 > > \par=20 > > \par STATUS: > > \par Per SC 6 Prague Resolution 6.7.7, this document is forwarded to = > > IETF =20 > > \par for consideration. >= > > =20 > > \par=20 > > \par ACTION ID: ACT=20 > > \par=20 > > \par DUE DATE: =20 > > \par=20 > > \par DISTRIBUTION: P & L Members; SC Chair; WG Conveners and = > > Secretaries =20 > > \par=20 > > \par=20 > > \par MEDIUM: =20 > > \par=20 > > \par DISKETTE NO.: =20 > > \par=20 > > \par NO. OF PAGES: 1 =20 > > \par=20 > > \par=20 > > \par ISO/IEC JTC 1/SC 6 Secretariat >= > > =20 > > \par ANSI, 11 W. 42nd Street, New York, NY 10036, USA >= > > =20 > > \par }\pard = > > >\s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 >6= > > 72\tx8631\adjustright {Tel: +1 212 642 4992; Fax: +1 212 84}{0 >2298; = > > E-mail: }{mdeane@ansi.org}{\tab \tab \tab \tab \tab \tab >= > > \tab }{\b\fs28=20 > > \par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\b\fs28 \page=20 > > \par \tab \tab \tab \tab \tab \tab \tab \tab \tab SC 6 N 11618 > > \par }{ > > \par }{\b Title: Liaison Report to the IETF Routing Area Director on = > > 2}{\b\super nd}{\b CD for ISO/IEC 10589 (IS-IS Routing) > > \par=20 > > \par Source: ISO/IEC JTC1/SC6 > > \par }{ > > \par ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for = > > ISO10589. SC6 intends to use this new version 2 as the base for >adding = > > the enhancements which have been requested by the IETF=20 > > to optimise the use of ISO 10589 for Internet routing solutions. The >= > > IETF IS-IS WG convenor originally identified Internet Drafts: = > > and >as = > > the source documents which specify these enhanceme > > nts. SC6 invites the IETF to confirm that the above Internet Drafts >= > > are the correct references and to inform SC6 if there are additional = > > IETF documents which refer to any other requirements for IS-IS >Routing = > > enhancements. > > \par=20 > > \par SC6 would like to interact wit > > h the IETF on clarifying the detailed requirements in the hope that it >= > > may be possible to introduce them during the editing cycle for >version = > > 2 of the standard. To this end, we would like the Routing Area = > > Directors to arrange an IS-IS BOF at the San Di > > ego IETF meeting to discuss these requirements and how they can be = > > incorporated into the new version of ISO 10586. > > \par=20 > > \par SC6 will post an initial draft version of the new base document >as = > > an Internet Draft in August 2000 but this will not contain the changes >r > > equested by the IETF. A ballot closure date of February 2001 has been >= > > set for the 2nd CD Ballot to allow incorporation of final input on the >= > > Internet requirements if they can be agreed at the December 2000 IETF >= > > meeting.=20 > > \par=20 > > \par For information, the current instructions to the editor are that >he = > > should use ISO/IEC 10589:1992 as a base for editing, and shall apply >the = > > minimum textual changes mandated by the following TCs and DRs: > > \par=20 > > \par ISO/IEC 10589:1992/Cor.1:1993 > > \par ISO/IEC 10589:1992/Cor.2:1996 > > \par ISO/IEC 10589:1992/Cor.3:1996 > > \par ISO/IEC 10589:1992/Amd 1:1996 > > \par 6N10323 - Defect Reports 7-26 > > \par 6N10659 - Defect Reports 27-34 > > \par 6N10733 - Technical Corrigendum 4 > > \par The editor will also apply the minimal changes necessary to = > > resolve additional Defect Reports 35-44. > > \par=20 > > \par If SC6 and the IETF are unable to resolve the required changes, >the = > > Editor will add a temporary note to the cover page and the scope >clause = > > stating that: \ldblquote=20 > > ISO 10589 does not currently include the extensions originally = > > requested by the IETF in Internet D > > rafts: and = > > . National Body and Liaison = > > organization comments are invited to comment on the best way to >progress = > > these extensions.\rdblquote=20 > > \par=20 > > \par=20 > > \par }} > > ------=_NextPart_000_018E_01C018C0.F5C6AE40-- > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 7 18:26:47 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28387 for ; Thu, 7 Sep 2000 18:26:47 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA11548; Thu, 7 Sep 2000 15:36:07 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA11518 for ; Thu, 7 Sep 2000 15:36:05 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.9.3) with ESMTP id PAA27113; Thu, 7 Sep 2000 15:22:20 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id AAA01051; Fri, 8 Sep 2000 00:23:44 +0200 Message-Id: <200009072223.AAA01051@kraak.procket.com> Subject: Re: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing To: mbartell@cisco.com (Micah Bartell) Date: Fri, 8 Sep 2000 00:23:44 +0200 (MEST) Cc: oran@cisco.com (David Oran), isis-wg@spider.juniper.net (ISIS WG) In-Reply-To: <4.2.0.58.20000907163021.00d0b980@127.0.0.1> from "Micah Bartell" at Sep 07, 2000 04:57:25 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > What does the IETF recommend as the best method moving forward to > handle changes to the ISO spec by the IETF and how best should the IP > specific information be handled? Personally I would be in favor of combining all ISO documents and IETF RFCs into one, and then splitting it up in three separate documents. *) one document that specifies the core of ISIS. How to set up adjacencies, what an LSP looks like, what TLVs are, what areas are to ISIS, how to run the SPF itself, etc. *) one document that specifies all TLVs and algorithms related to routing of iso8473 (aka CLNP) *) one document that specifies all TLVs and algorithms related to routing of IP I think especially splitting the core of IS-IS from iso8473 related details will make the protocol much more understandable. Just my 2 cents, I guess it will never happen ... :-( Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 7 18:43:19 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28625 for ; Thu, 7 Sep 2000 18:43:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA11686; Thu, 7 Sep 2000 15:52:28 -0700 (PDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA11660 for ; Thu, 7 Sep 2000 15:52:26 -0700 (PDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id PAA08644; Thu, 7 Sep 2000 15:38:31 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 15:38:31 -0700 Message-ID: From: Les Ginsberg To: "'Micah Bartell'" , David Oran , ISIS WG Subject: RE: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing Date: Thu, 7 Sep 2000 15:38:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net The original intent of the workplan submitted to ISO was a two step process: 1)To provide a revised version of the base ISO 10589 spec that incorporates the known DRs etc. This is the work that Micah has taken on - for which he deserves much applause as it involved considerable effort and I am sure not all of it was fun. 2)Moving forward from the output of Step #1, to incorporate the IP related extensions so that there was a unified document/set of documents which accurately reflected the current usage of the protocol given its deployment in both OSI and IP environments. The need for this is driven by the evolution of the usage of the protocol in the IP environment and the (potential) use of IS-IS in dual environments. Also, there is the feeling of some (myself included) that the current fragmented definition is less than optimal. How best to implement Step #2 is a question yet to be answered. Whether to try to put everything into a single document or provide a set of documents? How to manage these documents (within IETF, within ISO, liason)? There are obviously very different approaches to both organizations as far as document formats, approval processes, participation in the process etc. The fact that the IETF has been invited into this process is a very good thing for it means that all the interested parties can easily have a voice in defining at least the content of what should go into the document(s). How such documents are to be maintained, while an important issue, I think should be separated from the more immediate questions of: o What set of inputs should be used to create the document(s)? o What form should the document(s) take? I certainly think that RFC 1195, appropriately revised, should be part of the input set. as well as those extensions that are agreed upon. In addition to those extensions mentioned by others I would also add the "3-way handshake" draft as an essential. Les > -----Original Message----- > From: Micah Bartell [mailto:mbartell@cisco.com] > Sent: Thursday, September 07, 2000 2:57 PM > To: David Oran; ISIS WG > Subject: Re: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement > on Routeing > > > Folks, > > I will say that the only documents that I integrated into the > ISO 10589 2nd edition were those specified in the > "Instructions" from the ISO meeting in Prague. The changes > consist of the following documents: > > ISO/IEC 10589:1992/Cor.1:1993 > ISO/IEC 10589:1992/Cor.2:1996 > ISO/IEC 10589:1992/Cor.3:1996 > ISO/IEC 10589:1992/Amd 1:1996 > 6N10323 - Defect Reports 7-26 > 6N10659 - Defect Reports 27-34 > 6N10733 - Technical Corrigendum 4 > The editor will also apply the minimal changes necessary to resolve > additional Defect Reports 35-44. > > Regarding the changes proposed for DR 35-44, the SIF > recommendation was used in place of these DRs. > > Nothing IP specific was added to ISO 10589. The question > that the ISO is presenting here to the IETF as I understand it is: > > What does the IETF recommend as the best method moving > forward to handle changes to the ISO spec by the IETF and how > best should the IP specific information be handled? > > > The ISO world does not seem intent upon making great sweeping > changes to the spec, to the best of my knowledge and most new > work is being handled within the IETF. > > I think it would be wise to develop a method for dealing with > all IETF changes before setting the precedent of integrating > ANY of the IETF ID's or RFC's directly into the spec. That > document is already getting unwieldly in Word and if it is > going to be accepting another 100 pages of material, it will > very likely need to be restructured. > > The question of whether the ISO wishes to continue to > maintain this spec also needs to be asked. If not, it may be > possible to publish the ISO 10589 as a standards track RFC. > This would likely require some modification to the structure > of the document. ( Does an RFC really need 30 pages of > complex conformance tables? ) Also the ISO 10589 spec is not > friendly to a purely text based representation. > > These are just some of my thoughts on the matter. While, I > am the current editor for the document, I am not presenting > these suggestions as a "representative" of the ISO, or > stating this to be their official position. > > I will investigate further making available the PDF version > that I have of the 2nd Edition. This is pending a response from ANSI. > > /mpb > > > At 04:23 PM 9/7/2000 -0400, David Oran wrote: > >Copying the WG... > > > >-----Original Message----- > >From: Henk Smit [mailto:henk@Procket.com] > >Sent: Thursday, September 07, 2000 3:50 PM > >To: David Oran > >Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > For those of you who hate MSWORD, I append the text at > the end of the > > > message text as well. > > > > Thank you, I appreciate it ! > > Pretty weird that a standards body like ISO is using a proprietary > > files format. ;-) > > > > > Are there other drafts they should fold it? If so, please craft a > > > response and I'll get it to them. > > > > draft-ietf-isis-dyname-02.txt is not a draft anymore. > > It is now an RFC: RFC2763. > > > > I have just submitted a new version of > draft-ietf-isis-traffic-01.txt, > > draft-ietf-isis-traffic-02.txt. It might be a while before > it becomes > > an RFC. > > > > And what about RFC1195 itself ? There is no mention that this RFC > > will be incorporated ? > > > > If RFC1195 is incorporated, there is one more ISIS draft > that I would > > like to see added. Tony Li, Tony Prziegynda and myself are > also authors > > of a draft that is related. > draft-ietf-isis-domain-wide-02.txt. It is > > slated to be an RFC pretty soon, just waiting for the RFC editor to > > process it. If 10589 is including IP specific stuff, I > think this one > > should be incorporated too. > > > > Henk. > > > > > > > > > -----Original Message----- > > > From: Matthew Deane [mailto:mdeane@ANSI.org] > > > Sent: Thursday, September 07, 2000 11:35 AM > > > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > > > 'mankin@east.isi.edu' > > > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > > > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > > Dear IETF Directors, > > > > > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the > >following > > > > document is forwarded to IETF Routeing and Transport > Area Directors > > > for > > > > consideration: > > > > > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > > > version) > > > > > > > > > > > > Please do not hesitate to contact me should you have > any questions. > > > > > > > > Sincerely, > > > > > > > > Matt Deane > > > > JTC 1/SC 6 Secretariat > > > > > > > > <<06n1618.rtf>> > > > > > > > > > > SC 6 N 11618 > > > > > > Title: Liaison Report to the IETF Routing Area Director > on 2nd CD for > > > ISO/IEC 10589 (IS-IS Routing) > > > > > > Source: ISO/IEC JTC1/SC6 > > > > > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for > >ISO10589. > > > SC6 intends to use this new version 2 as the base for adding the > > > enhancements which have been requested by the IETF to > optimise the use > > > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG > >convenor > > > originally identified Internet Drafts: > > > > > and as the source documents which > > > specify these enhancements. SC6 invites the IETF to > confirm that the > > > above Internet Drafts are the correct references and to > inform SC6 if > > > there are additional IETF documents which refer to any other > > > requirements for IS-IS Routing enhancements. > > > > > > SC6 would like to interact with the IETF on clarifying > the detailed > > > requirements in the hope that it may be possible to > introduce them > > > during the editing cycle for version 2 of the standard. > To this end, > > > we would like the Routing Area Directors to arrange an > IS-IS BOF at > >the > > > San Diego IETF meeting to discuss these requirements and > how they can > >be > > > incorporated into the new version of ISO 10586. > > > > > > SC6 will post an initial draft version of the new base > document as an > > > Internet Draft in August 2000 but this will not contain > the changes > > > requested by the IETF. A ballot closure date of February 2001 has > >been > > > set for the 2nd CD Ballot to allow incorporation of final > input on the > > > Internet requirements if they can be agreed at the > December 2000 IETF > > > meeting. > > > > > > For information, the current instructions to the editor > are that he > > > should use ISO/IEC 10589:1992 as a base for editing, and > shall apply > >the > > > minimum textual changes mandated by the following TCs and DRs: > > > > > > ISO/IEC 10589:1992/Cor.1:1993 > > > ISO/IEC 10589:1992/Cor.2:1996 > > > ISO/IEC 10589:1992/Cor.3:1996 > > > ISO/IEC 10589:1992/Amd 1:1996 > > > 6N10323 - Defect Reports 7-26 > > > 6N10659 - Defect Reports 27-34 > > > 6N10733 - Technical Corrigendum 4 > > > The editor will also apply the minimal changes > necessary to resolve > > > additional Defect Reports 35-44. > > > > > > If SC6 and the IETF are unable to resolve the required > changes, the > > > Editor will add a temporary note to the cover page and the scope > >clause > > > stating that: " ISO 10589 does not currently include the > extensions > > > originally requested by the IETF in Internet Drafts: > > > and > . > > > National Body and Liaison organization comments are > invited to comment > > > on the best way to progress these extensions." > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Sep 9 21:20:19 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24330 for ; Sat, 9 Sep 2000 21:20:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA16509; Sat, 9 Sep 2000 18:31:03 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA16104 for ; Sat, 9 Sep 2000 11:27:47 -0700 (PDT) Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id LAA10854; Sat, 9 Sep 2000 11:13:55 -0700 (PDT) (envelope-from tony1@home.net) Received: from home.net ([24.5.203.21]) by mail.rdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000909181355.DGAQ15470.mail.rdc1.sfba.home.com@home.net>; Sat, 9 Sep 2000 11:13:55 -0700 Message-ID: <39BA7E3B.B89F2831@home.net> Date: Sat, 09 Sep 2000 11:15:23 -0700 From: Tony Li Organization: Li Consulting X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: isis-wg@juniper.net, prz@net4u.ch, kireeti@juniper.net References: <200009041720.KAA23170@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Re: draft-kompella-isis-ompls-extensions-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > Kireeti and myself would like to ask the ISIS working group > to accept draft-kompella-isis-ompls-extensions-00.txt as the > ISIS WG document. I've seen no comments or objections. Please consider this a WG document. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Sep 9 21:20:48 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24340 for ; Sat, 9 Sep 2000 21:20:47 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA16484; Sat, 9 Sep 2000 18:31:01 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA06686 for ; Mon, 4 Sep 2000 10:33:11 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id KAA02557; Mon, 4 Sep 2000 10:19:55 -0700 (PDT) (envelope-from yakov@cisco.com) Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA23170; Mon, 4 Sep 2000 10:20:01 -0700 (PDT) Message-Id: <200009041720.KAA23170@omega.cisco.com> To: isis-wg@juniper.net, tony1@home.net, prz@net4u.ch cc: yakov@cisco.com, kireeti@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23167.968088001.1@cisco.com> Date: Mon, 04 Sep 2000 10:20:01 -0700 From: Yakov Rekhter Subject: [Isis-wg] draft-kompella-isis-ompls-extensions-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Tony and Tony, Kireeti and myself would like to ask the ISIS working group to accept draft-kompella-isis-ompls-extensions-00.txt as the ISIS WG document. Yakov. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Sep 9 21:22:02 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24351 for ; Sat, 9 Sep 2000 21:22:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA16458; Sat, 9 Sep 2000 18:31:00 -0700 (PDT) Received: from tcb.net (tcb.net [205.168.100.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA13382 for ; Fri, 8 Sep 2000 20:20:06 -0700 (PDT) Received: from sofos.tcb.net (sofos.tcb.net [205.168.100.1] (may be forged)) by tcb.net (8.9.3/8.9.3) with ESMTP id VAA14759 for ; Fri, 8 Sep 2000 21:06:38 -0600 Date: Fri, 8 Sep 2000 21:06:38 -0600 (MDT) From: "Jude V. Ballard" To: ISIS WG Subject: RE: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Speaking as someone who is in the early stages of experience with this protocol, I would love to see this as a set of documents managed by the IETF. If for no other reason than to have a unified source, and format for the information. (I find the ISO format to be a bit unwieldy, but that is an opinion and not very relevant) It may also lead to development of protocol analysis, and "experience with" docs (additional benifits to the internet community.) I would be more than willing to volunteer my time in order to help complete this work. (Although the majority of you are probably more qualified.) -Jude On Thu, 7 Sep 2000, Les Ginsberg wrote: > The original intent of the workplan submitted to ISO was a two step process: > > 1)To provide a revised version of the base ISO 10589 spec that incorporates > the known DRs etc. This is the work that Micah has taken on - for which he > deserves much applause as it involved considerable effort and I am sure not > all of it was fun. > > 2)Moving forward from the output of Step #1, to incorporate the IP related > extensions so that there was a unified document/set of documents which > accurately reflected the current usage of the protocol given its deployment > in both OSI and IP environments. The need for this is driven by the > evolution of the usage of the protocol in the IP environment and the > (potential) use of IS-IS in dual environments. Also, there is the feeling of > some (myself included) that the current fragmented definition is less than > optimal. > > How best to implement Step #2 is a question yet to be answered. Whether to > try to put everything into a single document or provide a set of documents? > How to manage these documents (within IETF, within ISO, liason)? > > There are obviously very different approaches to both organizations as far > as document formats, approval processes, participation in the process etc. > > The fact that the IETF has been invited into this process is a very good > thing for it means that all the interested parties can easily have a voice > in defining at least the content of what should go into the document(s). How > such documents are to be maintained, while an important issue, I think > should be separated from the more immediate questions of: > > o What set of inputs should be used to create the document(s)? > o What form should the document(s) take? > > I certainly think that RFC 1195, appropriately revised, should be part of > the input set. as well as those extensions that are agreed upon. In addition > to those extensions mentioned by others I would also add the "3-way > handshake" draft as an essential. > > Les > > > -----Original Message----- > > From: Micah Bartell [mailto:mbartell@cisco.com] > > Sent: Thursday, September 07, 2000 2:57 PM > > To: David Oran; ISIS WG > > Subject: Re: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement > > on Routeing > > > > > > Folks, > > > > I will say that the only documents that I integrated into the > > ISO 10589 2nd edition were those specified in the > > "Instructions" from the ISO meeting in Prague. The changes > > consist of the following documents: > > > > ISO/IEC 10589:1992/Cor.1:1993 > > ISO/IEC 10589:1992/Cor.2:1996 > > ISO/IEC 10589:1992/Cor.3:1996 > > ISO/IEC 10589:1992/Amd 1:1996 > > 6N10323 - Defect Reports 7-26 > > 6N10659 - Defect Reports 27-34 > > 6N10733 - Technical Corrigendum 4 > > The editor will also apply the minimal changes necessary to resolve > > additional Defect Reports 35-44. > > > > Regarding the changes proposed for DR 35-44, the SIF > > recommendation was used in place of these DRs. > > > > Nothing IP specific was added to ISO 10589. The question > > that the ISO is presenting here to the IETF as I understand it is: > > > > What does the IETF recommend as the best method moving > > forward to handle changes to the ISO spec by the IETF and how > > best should the IP specific information be handled? > > > > > > The ISO world does not seem intent upon making great sweeping > > changes to the spec, to the best of my knowledge and most new > > work is being handled within the IETF. > > > > I think it would be wise to develop a method for dealing with > > all IETF changes before setting the precedent of integrating > > ANY of the IETF ID's or RFC's directly into the spec. That > > document is already getting unwieldly in Word and if it is > > going to be accepting another 100 pages of material, it will > > very likely need to be restructured. > > > > The question of whether the ISO wishes to continue to > > maintain this spec also needs to be asked. If not, it may be > > possible to publish the ISO 10589 as a standards track RFC. > > This would likely require some modification to the structure > > of the document. ( Does an RFC really need 30 pages of > > complex conformance tables? ) Also the ISO 10589 spec is not > > friendly to a purely text based representation. > > > > These are just some of my thoughts on the matter. While, I > > am the current editor for the document, I am not presenting > > these suggestions as a "representative" of the ISO, or > > stating this to be their official position. > > > > I will investigate further making available the PDF version > > that I have of the 2nd Edition. This is pending a response from ANSI. > > > > /mpb > > > > > > At 04:23 PM 9/7/2000 -0400, David Oran wrote: > > >Copying the WG... > > > > > >-----Original Message----- > > >From: Henk Smit [mailto:henk@Procket.com] > > >Sent: Thursday, September 07, 2000 3:50 PM > > >To: David Oran > > >Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > > > > > For those of you who hate MSWORD, I append the text at > > the end of the > > > > message text as well. > > > > > > Thank you, I appreciate it ! > > > Pretty weird that a standards body like ISO is using a proprietary > > > files format. ;-) > > > > > > > Are there other drafts they should fold it? If so, please craft a > > > > response and I'll get it to them. > > > > > > draft-ietf-isis-dyname-02.txt is not a draft anymore. > > > It is now an RFC: RFC2763. > > > > > > I have just submitted a new version of > > draft-ietf-isis-traffic-01.txt, > > > draft-ietf-isis-traffic-02.txt. It might be a while before > > it becomes > > > an RFC. > > > > > > And what about RFC1195 itself ? There is no mention that this RFC > > > will be incorporated ? > > > > > > If RFC1195 is incorporated, there is one more ISIS draft > > that I would > > > like to see added. Tony Li, Tony Prziegynda and myself are > > also authors > > > of a draft that is related. > > draft-ietf-isis-domain-wide-02.txt. It is > > > slated to be an RFC pretty soon, just waiting for the RFC editor to > > > process it. If 10589 is including IP specific stuff, I > > think this one > > > should be incorporated too. > > > > > > Henk. > > > > > > > > > > > > > -----Original Message----- > > > > From: Matthew Deane [mailto:mdeane@ANSI.org] > > > > Sent: Thursday, September 07, 2000 11:35 AM > > > > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > > > > 'mankin@east.isi.edu' > > > > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > > > > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > > > > > Dear IETF Directors, > > > > > > > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the > > >following > > > > > document is forwarded to IETF Routeing and Transport > > Area Directors > > > > for > > > > > consideration: > > > > > > > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > > > > version) > > > > > > > > > > > > > > > Please do not hesitate to contact me should you have > > any questions. > > > > > > > > > > Sincerely, > > > > > > > > > > Matt Deane > > > > > JTC 1/SC 6 Secretariat > > > > > > > > > > <<06n1618.rtf>> > > > > > > > > > > > > > > SC 6 N 11618 > > > > > > > > Title: Liaison Report to the IETF Routing Area Director > > on 2nd CD for > > > > ISO/IEC 10589 (IS-IS Routing) > > > > > > > > Source: ISO/IEC JTC1/SC6 > > > > > > > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for > > >ISO10589. > > > > SC6 intends to use this new version 2 as the base for adding the > > > > enhancements which have been requested by the IETF to > > optimise the use > > > > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG > > >convenor > > > > originally identified Internet Drafts: > > > > > > > and as the source documents which > > > > specify these enhancements. SC6 invites the IETF to > > confirm that the > > > > above Internet Drafts are the correct references and to > > inform SC6 if > > > > there are additional IETF documents which refer to any other > > > > requirements for IS-IS Routing enhancements. > > > > > > > > SC6 would like to interact with the IETF on clarifying > > the detailed > > > > requirements in the hope that it may be possible to > > introduce them > > > > during the editing cycle for version 2 of the standard. > > To this end, > > > > we would like the Routing Area Directors to arrange an > > IS-IS BOF at > > >the > > > > San Diego IETF meeting to discuss these requirements and > > how they can > > >be > > > > incorporated into the new version of ISO 10586. > > > > > > > > SC6 will post an initial draft version of the new base > > document as an > > > > Internet Draft in August 2000 but this will not contain > > the changes > > > > requested by the IETF. A ballot closure date of February 2001 has > > >been > > > > set for the 2nd CD Ballot to allow incorporation of final > > input on the > > > > Internet requirements if they can be agreed at the > > December 2000 IETF > > > > meeting. > > > > > > > > For information, the current instructions to the editor > > are that he > > > > should use ISO/IEC 10589:1992 as a base for editing, and > > shall apply > > >the > > > > minimum textual changes mandated by the following TCs and DRs: > > > > > > > > ISO/IEC 10589:1992/Cor.1:1993 > > > > ISO/IEC 10589:1992/Cor.2:1996 > > > > ISO/IEC 10589:1992/Cor.3:1996 > > > > ISO/IEC 10589:1992/Amd 1:1996 > > > > 6N10323 - Defect Reports 7-26 > > > > 6N10659 - Defect Reports 27-34 > > > > 6N10733 - Technical Corrigendum 4 > > > > The editor will also apply the minimal changes > > necessary to resolve > > > > additional Defect Reports 35-44. > > > > > > > > If SC6 and the IETF are unable to resolve the required > > changes, the > > > > Editor will add a temporary note to the cover page and the scope > > >clause > > > > stating that: " ISO 10589 does not currently include the > > extensions > > > > originally requested by the IETF in Internet Drafts: > > > > and > > . > > > > National Body and Liaison organization comments are > > invited to comment > > > > on the best way to progress these extensions." > > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Sep 11 19:20:19 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09942 for ; Mon, 11 Sep 2000 19:20:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA19383; Mon, 11 Sep 2000 16:29:13 -0700 (PDT) Received: from hotmail.com (f126.pav1.hotmail.com [64.4.31.126]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA19353 for ; Mon, 11 Sep 2000 16:29:11 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 11 Sep 2000 16:15:03 -0700 Received: from 209.58.11.227 by pv1fd.pav1.hotmail.msn.com with HTTP; Mon, 11 Sep 2000 23:15:03 GMT X-Originating-IP: [209.58.11.227] From: "vikram isis" To: isis-wg@spider.juniper.net Date: Mon, 11 Sep 2000 23:15:03 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Sep 2000 23:15:03.0760 (UTC) FILETIME=[1DADED00:01C01C46] Subject: [Isis-wg] Hello Intervals Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi, A question on hello interval timers. Cisco implements hellos times as follows: 1> hello interval : 10 2> hello multiplier: 3 does anybody have some suggestions as to where these values have been specified? Any help is appreciated. Vikram _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Sep 11 19:42:37 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10056 for ; Mon, 11 Sep 2000 19:42:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA19531; Mon, 11 Sep 2000 16:53:20 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA19502 for ; Mon, 11 Sep 2000 16:53:18 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11261; Mon, 11 Sep 2000 16:39:04 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA07730; Mon, 11 Sep 2000 19:39:04 -0400 (EDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id TAA18527; Mon, 11 Sep 2000 19:39:03 -0400 (EDT) Message-Id: <200009112339.TAA18527@bcn.East.Sun.COM> Date: Mon, 11 Sep 2000 19:39:03 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] Hello Intervals To: isis-wg@spider.juniper.net, vikram_isis@hotmail.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KVAerEuiNx+1JhezJl4rew== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net >> From: "vikram isis" >> 1> hello interval : 10 >> 2> hello multiplier: 3 >> does anybody have some suggestions as to where these values have been >> specified? I think the Cisco numbers are reasonable. The hello timer must be settable, and perhaps the holding multiplier is as well. So the "hello interval" of 10 is a default, right? By the way, the holding multiplier was something I discovered, to my surprise (and not happiness) that 10589 specified to be a constant, and 10 times the hello timer, which is way too much. I think it was specified as 2+fudge factor, or perhaps 3, in the DECnet Phase 5 routing spec. At any rate, when I asked on the mailing list about how the multiplier got to be specified as 10 (and not settable...an architectural constant), the answer was that everyone was ignoring that, so it wasn't a problem! There's no magic to the numbers, and there was no careful analysis done, but 2 or 3 times for the multiplier seems about right, and 10 times seems definitely wrong. As for the hello timer, I'd think it would have to be a parameter, since if you want to notice a router down within a few seconds, you'll have to send more frequent hellos, and if it were always, say, 1 second, that might be too much overhead in most cases. Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Sep 11 20:05:31 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10149 for ; Mon, 11 Sep 2000 20:05:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA19668; Mon, 11 Sep 2000 17:16:39 -0700 (PDT) Received: from tcb.net (tcb.net [205.168.100.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA19636 for ; Mon, 11 Sep 2000 17:16:37 -0700 (PDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id SAA32262 for ; Mon, 11 Sep 2000 18:02:48 -0600 Message-Id: <200009120002.SAA32262@tcb.net> X-Mailer: exmh version 2.0.3 To: isis-wg@spider.juniper.net From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [Isis-wg] Hello Intervals Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Sep 2000 18:02:48 -0600 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > There's no magic to the numbers, and there was no careful analysis > done, but 2 or 3 times for the multiplier > seems about right, and 10 times seems definitely > wrong. As for the hello timer, I'd think it would have to be > a parameter, since if you want to notice a router down within a few > seconds, you'll have to send more frequent hellos, and if it were > always, say, 1 second, that might be too much overhead in most cases. Several service provider networks I'm familiar with actually increase the multiplier to 4 or 5 and lower the interval to 1-2s. The b/w utilization is negligible (especially on OC-n connections), and even less when implementations stop padding hellos after adjacency establishment. The benefit (i.e. detecting faults nearly an order of magnitude faster) certainly is interesting, especially when comparing to typical default values. Then again, others increase the interval to cut down on chatting (especially w/large NBMA clouds -- where they need it most *8^/). Of course, it goes without saying -- mucking with values without understanding the full impact on the network is a bad idea. -danny _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Sep 11 21:22:32 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10546 for ; Mon, 11 Sep 2000 21:22:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA19831; Mon, 11 Sep 2000 18:31:14 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA19805 for ; Mon, 11 Sep 2000 18:31:12 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA07863; Mon, 11 Sep 2000 18:17:02 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA16890; Mon, 11 Sep 2000 21:17:01 -0400 (EDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id VAA18769; Mon, 11 Sep 2000 21:17:01 -0400 (EDT) Message-Id: <200009120117.VAA18769@bcn.East.Sun.COM> Date: Mon, 11 Sep 2000 21:17:01 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] Hello Intervals To: isis-wg@spider.juniper.net, danny@tcb.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: W8DbHQIIDulU/CZTWv5z2g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net >> From: Danny McPherson >> Several service provider networks I'm familiar with actually increase the >> multiplier to 4 or 5 and lower the interval to 1-2s. What is the value in increasing the multiplier? I understand why you'd want to set the hello interval to be small in order to detect failure quickly. The only reason I could imagine for setting the multiplier higher is if the link is very flaky and it's likely you'll miss several hellos in a row. Are the networks you refer to using very fast and very flaky links? Or are the routers likely to lose a lot of packets without looking at them first, so that most hellos do get lost? Just curious... Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Sep 11 22:19:03 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11731 for ; Mon, 11 Sep 2000 22:19:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA20035; Mon, 11 Sep 2000 19:27:35 -0700 (PDT) Received: from tcb.net (tcb.net [205.168.100.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA19961 for ; Mon, 11 Sep 2000 19:27:31 -0700 (PDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id UAA00463 for ; Mon, 11 Sep 2000 20:13:41 -0600 Message-Id: <200009120213.UAA00463@tcb.net> X-Mailer: exmh version 2.0.3 To: isis-wg@spider.juniper.net From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [Isis-wg] Hello Intervals Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Sep 2000 20:13:41 -0600 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > What is the value in increasing the multiplier? I understand why you'd > want to set the hello interval to be small in order to detect failure > quickly. The only reason I could imagine for setting the multiplier > higher is if the link is very flaky and it's likely you'll miss > several hellos in a row. Are the networks you refer to > using very fast and very flaky links? > Or are the routers likely to lose a lot of packets without looking at > them first, so that most hellos do get lost? There are a number of reasons, actually. A couple of the networks I refer to are indeed very fast and usually very reliable, though the reasoning equally applies to the lower-speed networks as well. Increasing the multiplier seems to provide a sense of security when decreasing the interval, primarily in order to avoid instability or oscillation as a result of bursts of errors (on usually very reliable links, perhaps when switching to protected SONET paths, though applicable to "non-protected" links as well), or dealing with bursty traffic resulting in temporal congestion (perhaps as the result of circuit failures or other anomalies in the network). And, of course, to deal with "platform" issues (e.g. lack or system bandwidth, processor cycles, plain old flakiness, etc..). Similarly, such models have been deployed w/BGP and other routing protocols, as well as link layer keepalives, etc.. -danny _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Sep 12 00:22:33 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13870 for ; Tue, 12 Sep 2000 00:22:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA20274; Mon, 11 Sep 2000 21:33:46 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA20243 for ; Mon, 11 Sep 2000 21:33:42 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 12 Sep 2000 10:03:20 +0530 Received: from selvarajr ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id JAA01589; Tue, 12 Sep 2000 09:37:34 +0530 Received: by localhost with Microsoft MAPI; Tue, 12 Sep 2000 09:40:21 +0530 Message-Id: <01C01C9D.77D40240.selvarajr@future.futsoft.com> From: selvarajR Reply-To: "selvarajr@future.futsoft.com" To: "'ISISWG'" Date: Mon, 11 Sep 2000 20:44:56 +0530 Organization: future softw X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Doubt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hi, My doubt is regarding , having more than one adjacency with same system Id but different SNPA. I hope this is possible when there is any backup link present I assume that, if any Hello PDU be received by an IS with system Id same as the received IS, then it can be discarded. ie Receiving own hello PDU. IS - 1 IS - 2 | | | c1 | c2 ----------------------------------------------------------- c3 | | c4 | | | | IS - 3 For the above broadcast topology let, IS-1, IS-2 & IS-3 be three L1 intermediate systems c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up link for IS-3. Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ystem Id but, different SNPA. But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 and vice versa DOUBTS: 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say c3 as the DR. So the LAN will have more than on DR at a time 2. If the IS won't have two interfaces on the same LAN as in the above topology , then why do we need to check for system ID and SNPA. for creating new adjacency over a circuit. I feel checking for System ID alone sufficient. So we can discard duplicate IIH. Pls correct me , if I'm wrong. Selva. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Sep 12 00:23:42 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13884 for ; Tue, 12 Sep 2000 00:23:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA20303; Mon, 11 Sep 2000 21:33:50 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA20251 for ; Mon, 11 Sep 2000 21:33:45 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 12 Sep 2000 10:03:21 +0530 Received: from selvarajr ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id JAA01594; Tue, 12 Sep 2000 09:37:35 +0530 Received: by localhost with Microsoft MAPI; Tue, 12 Sep 2000 09:40:21 +0530 Message-Id: <01C01C9D.784058A0.selvarajr@future.futsoft.com> From: selvarajR Reply-To: "selvarajr@future.futsoft.com" To: "'ISISWG'" Date: Mon, 11 Sep 2000 20:44:56 +0530 Organization: future softw X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01C01C9D.78498060" Subject: [Isis-wg] Doubt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net ------ =_NextPart_000_01C01C9D.78498060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, My doubt is regarding , having more than one adjacency with same system Id but different SNPA. I hope this is possible when there is any backup link present I assume that, if any Hello PDU be received by an IS with system Id same as the received IS, then it can be discarded. ie Receiving own hello PDU. IS - 1 IS - 2 | | | c1 | c2 ----------------------------------------------------------- c3 | | c4 | | | | IS - 3 For the above broadcast topology let, IS-1, IS-2 & IS-3 be three L1 intermediate systems c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up link for IS-3. Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ystem Id but, different SNPA. But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 and vice versa DOUBTS: 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say c3 as the DR. So the LAN will have more than on DR at a time 2. If the IS won't have two interfaces on the same LAN as in the above topology , then why do we need to check for system ID and SNPA. for creating new adjacency over a circuit. I feel checking for System ID alone sufficient. So we can discard duplicate IIH. Pls correct me , if I'm wrong. Selva. ------ =_NextPart_000_01C01C9D.78498060 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhUEAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAUAAAAL AA8OAAAAAAIB/w8BAAAAbQAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAAO07sbk4atQRlnAAIDUf kqCEhQAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJU1dHAFNNVFAAaXNpcy13Z0BleHRlcm5h bC5qdW5pcGVyLm5ldAAAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACQAAACdJU0lT V0cnAAAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAcAAABJU0lTV0cAAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAAO07sbk4atQRlnAAIDUfkqCEhQAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAAUWVgEEgAEABgAAAERvdWJ0AP4BAQWAAwAOAAAA0AcJAAsAFAAsADgAAQBkAQEggAMA DgAAANAHCQALABMALQABAAEALQEBCYABACEAAAA3RkNENTk0N0NEODdENDExOTY3MDAwMjAzNTFG OTJBMAAABwEDkAYAaAsAACAAAAALAAIAAQAAAAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMANgAA AAAAQAA5AIDwOQsDHMABHgBwAAEAAAAGAAAARG91YnQAAAACAXEAAQAAABYAAAABwBwDCuZHWc2+ h80R1JZwACA1H5KgAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAAHQAAAHNlbHZhcmFqckBm dXR1cmUuZnV0c29mdC5jb20AAAAAAwAGEEHHhQYDAAcQ2AMAAB4ACBABAAAAZQAAAEhJLE1ZRE9V QlRJU1JFR0FSRElORyxIQVZJTkdNT1JFVEhBTk9ORUFESkFDRU5DWVdJVEhTQU1FU1lTVEVNSURC VVRESUZGRVJFTlRTTlBBSUhPUEVUSElTSVNQT1NTSUJMRVcAAAAAAgEJEAEAAABcCAAAWAgAABwT AABMWkZ1dX1fHgMACgByY3BnMTI1cjIMYGMxAzABBwtgbpEOEDAzMw8WZmUPkk8B9wKkA2MCAGNo CsBzhGV0AtFwcnEyAACSKgqhbm8SUCAwAdCFAdA2D6AwNTA0FCHzAdAUEDR9B20CgwBQA9T7Ef8T C2IT4RRQE7IY9BTQiwcTFeQ2EY4yMzgXVKIgB20gQ0UV5Dcaf6cUQBuvHLV5chXkORGOrxpQFjEe /wOCRwnRawKD3wwBIP8OUCIvA3NUCHAj1LsWMSENOBphJZ8DgkIHQP50DeAj1CVhFmwbeAcTHQb/ G3Aq/x63LJUgVQ4wFk4h6P8slCOJGmEwTiVmLJQm5x2RvzBNKJcslComApEI5jsJb+owOL9lDjA1 Oeo7ATq//zvJOdQ78jpfPi897T1vO5/zOe8QYDI4Q7pE0USPRZn/OdRFwkQvR/9HvUc/RW9JNH45 DlBMhE3hRgNN4AKCc6h0eWwHkGgJ4HQAAGED8GRjdGwKsQBgZMxqdU9QBRBnaAVCFjIdDAFjCcBQ IAMwc25lvngXMAewBbAAwAJzcwBQWHNiMhRQT0BhE/Bc+msJ4HALkFAYCGBQUAuA+mVPgHZVwAFA ULsMMFGEbxuQVGAEoAuAZ0XRUgZi+mEXEGQCIFLAUmZPsFCw+VfxIDFPEw5QU79Uz1XT/wBRVlwA oFGOWN9Z5k8ED8D/Wu9b/1XTDlBWT16vX79aE/YzAoITEGNTgGaBULBaEJMqUFXwIEQBEGF1KkAU IFAKwGEJwGFwaJwgRgIhU0QwEWktD5BeOAFAVZBrE1AYYgsgcs8JUGxyFqBscnc0QyEXAP5wAdBo UlDfZX9mhmqwaXBbBRACMC1qEANhOikQb6Fx0FN1YmoFkHRx0OBEYXRlOlNEGmFq//9sD20fbixP oFoDDiFmgVcWNw5Qb49wnlJV4RcBIEj/WfEEkFNEHZFzr3S/dc9VXy93Dw+BghAI0GIKsHQ4/2Ta D1RhsHkfeiaCoHswC1C8eS9qIHYQCxF7pXNTRP8bkXyvfb9+z24vbz+Ez4XZf3HycZRyySDQUB+L NIJTOYeLf4yPkcBEb2N1B4CfAjAF0GngN+GP8m93kDD7iTEBgG5yUABgCfBogJQgdwIBUwB3smUA 8JQgT2BwSTxgXHYIkHdrC4Bk/x7Al8IE8AdAEGEBQA4AiQL3WeKZJQIQbwVCFyES8nLgjm0LUXLg HQA6XFxxIHpvacFtahADEAeQm9BNkw3gA2BzbwGAIE8BIGsN4JcQXJ2GRQDAAxAufWZQdJTwFxCQ MFJBgBJ4ewFAliFuT7A40J8kaRRjzwMgEvMAgAWQbHZdQWJw/w5wUwChsgGQACCiQpgRlGH/AcGh sRbgD3AAAGJwDNABkPwgLjfyoagOUKJiKkBQkP+i36PvpP8PwGJwBYGmn6ev7ai/bB7AYnBspl+r H6wlPimlLDAQqf+u36wUYiD+KAKRr/+h8xpgra+yb7N//7SPoiAdkLXSoq+3P7hPpSz/G5C137tf vG+9f6IgINC6X/+/78D/wgQK+QMwkA+LP1IxEHtIaSwKhU15IK9mUHJABUAEACA40GcLEfVaIixZ 0GGXwFoxBGA40PQgdKvBIAIgE4DIQQDQ3QnwY8qwA/DM4CBh8AeATc5QeU9QmzAgSVJAYj9/8MrA BpAQUDjQlHFTTqhQQS4KhUlZ0G+XgPfM0csxyzFwE2AAkAJgE4D+d0+wA6DM4KBhyyIAcMqwQWYQ Y2t1cCCAEWt/0dA40BcQAjAKhdCHZiBz25RBzNJ0zADLIGbTQ3uw5mwJAGlwRFXPQBOAONDfncBo wc8xyrADkUkF8M4U/87HzmNmINKy19jY0MwA0sH7A6BooCCYsAOg17FaEJih+wsgCYAuyyATgHsw 2AJaIv+VQAOgT7DXNdB21MzgGNjR33FwDpDhL+H64MMy37/gEf584f/lv+RU42/kcw6B6L/35i/b 8ONWLeuP7J/tr+4ls+c/4BljM+SV6HE07z+/6d/m3/Tv84/0n+AtM9TMt4YB2mMBoG9o0YkAb8hA 35iwT1DM0NEgCPFnyrDT8H8XIMom4JOHkMwA/QEpACaf/PLxANexzOAJ0SBMDpC/cUEEkAeAWhCb cs6lc/bIrw6AzADq8ADxMwDxNP4UP9fCimBycWjC2NBDwHF1Z5pgzpHb8GlylDBooHPf3QDSccyx AZjTkiDT1paRt/3D0HbgEUwXINRBafoQ/2igyrCdQOiC17EPkADy16L/DAABMteiFBDTQVJAAZQU UP/ezXuwOND9Qp+AliFmIGoA/+ihChIMKSkAFnDXMMwSzMH+d9dQzWeX0NMwBhIMGvEA384fzyTM AM+fylNCEjIQHP9mYAMGmnAOY9bSzXgIEWigXwMI3fHdAwGRyzFummFr/xjA3gH7gPDiDQKXwJ3A GfAFe2Fh3txET1VCVNRTOt7VMd0AQZWwV8D5aPBSIIBBAoFmYOiCCMP/ChUOE2Hw+/ABkdpFHPDd AN8T0fDiHqcZgx94U9dQ2nL5/qBBTg4JzJoc4nLQzWDXzNAl8d7VMt0ASdaw2mP/2NIVDw6y/uNp IJ3AF8HSo/8RJCKC2kHHYfpI+4fbZdJw/8qyENAIgFKA2EEZYk+wBWH7BhLOtkQKA9AzBgPDcFnw 9zewWjFSgHcWSntRJIEDpf/dAOChBgA5QKFgLHNaIgYS/lMtKDhQzUHV4J2Sl9DGQP8h4yvB3ALc dcrA09CAEJiwkZuBSUlI3s1QbNMw/9vw+hDX4Zpw2hHMANahzxD7AwacUHedEHgA3s85k8YBp8Fg ciCAgHZhpRB7OlaPxtPHj8iVO5d9AAA+sAMAEBAAAAAAAwAREAEAAAADAIAQ/////0AABzAgT4Ss +hvAAUAACDAgT4Ss+hvAAQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAA AAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMA B4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUA AAEAAAAFAAAAOC4wNAAAAAALAAmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYA AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAe AAyACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAA AEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAA AAAAAAAeAD0AAQAAAAEAAAAAAAAAAwANNP03AAARAw== ------ =_NextPart_000_01C01C9D.78498060-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Sep 12 01:04:39 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14345 for ; Tue, 12 Sep 2000 01:04:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA20531; Mon, 11 Sep 2000 22:15:42 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA20195 for ; Mon, 11 Sep 2000 21:06:28 -0700 (PDT) Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id UAA03389; Mon, 11 Sep 2000 20:52:09 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id UAA13829; Mon, 11 Sep 2000 20:51:47 -0700 (PDT) Message-ID: <39BDA924.DAF0EC23@cisco.com> Date: Mon, 11 Sep 2000 20:55:16 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Radia Perlman - Boston Center for Networking CC: isis-wg@spider.juniper.net, danny@tcb.net Subject: Re: [Isis-wg] Hello Intervals References: <200009120117.VAA18769@bcn.East.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Radia, One of the reasons I know of for incresing the multiplier would be to avoid unnecessary adj. flaps when you have bursts of traffic - hence temporary congestions - and your hardware is not capable of separating discarded protocol packets from data packets on an ingress line card. (I know a few boxes which have such a characteristic :). R. > >> From: Danny McPherson > > >> Several service provider networks I'm familiar with actually increase > the > >> multiplier to 4 or 5 and lower the interval to 1-2s. > > What is the value in increasing the multiplier? I understand why you'd > want to set the hello interval to be small in order to detect failure > quickly. The only reason I could imagine for setting the multiplier > higher is if the link is very flaky and it's likely you'll miss > several hellos in a row. Are the networks you refer to > using very fast and very flaky links? > Or are the routers likely to lose a lot of packets without looking at > them first, so that most hellos do get lost? > > Just curious... > > Radia > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Sep 12 01:57:17 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20390 for ; Tue, 12 Sep 2000 01:57:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA20712; Mon, 11 Sep 2000 23:08:37 -0700 (PDT) Received: from redd248.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA20681 for ; Mon, 11 Sep 2000 23:08:35 -0700 (PDT) Received: (from tli@localhost) by redd248.procket.com (8.9.3/8.9.3) id WAA05918; Mon, 11 Sep 2000 22:53:52 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: redd248.procket.com: tli set sender to tli@redd248.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14781.50416.917970.234535@redd248.procket.com> Date: Mon, 11 Sep 2000 22:53:52 -0700 (PDT) To: raszuk@cisco.com Cc: Radia Perlman - Boston Center for Networking , isis-wg@spider.juniper.net, danny@tcb.net Subject: Re: [Isis-wg] Hello Intervals In-Reply-To: <39BDA924.DAF0EC23@cisco.com> References: <200009120117.VAA18769@bcn.East.Sun.COM> <39BDA924.DAF0EC23@cisco.com> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit | One of the reasons I know of for incresing the multiplier would be to | avoid unnecessary adj. flaps when you have bursts of traffic - hence | temporary congestions - and your hardware is not capable of separating | discarded protocol packets from data packets on an ingress line card. (I | know a few boxes which have such a characteristic :). And before this provokes a discussion, I think most folks would agree that that's not a particularly robust implementation. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Sep 12 03:38:36 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27255 for ; Tue, 12 Sep 2000 03:38:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA20866; Tue, 12 Sep 2000 00:49:12 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA20840 for ; Tue, 12 Sep 2000 00:49:11 -0700 (PDT) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by postal.redback.com (Postfix) with ESMTP id 6E06F17BC01; Tue, 12 Sep 2000 00:35:00 -0700 (PDT) To: "selvarajr@future.futsoft.com" Cc: "'ISISWG'" Subject: Re: [Isis-wg] Doubt In-reply-to: Mail from selvarajR dated Mon, 11 Sep 2000 20:44:56 +0530 <01C01C9D.784058A0.selvarajr@future.futsoft.com> Date: Tue, 12 Sep 2000 00:34:14 -0700 From: Naiming Shen Message-Id: <20000912073500.6E06F17BC01@postal.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net ] ] IS - 1 IS - 2 ] | | ] | c1 | c2 ]----------------------------------------------------------- ] c3 | | c4 ] | | ] | | ] IS - 3 ] ]For the above broadcast topology let, ] IS-1, IS-2 & IS-3 be three L1 intermediate systems ] c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up ]link for IS-3. ] Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. ] ]Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ]ystem Id but, different SNPA. ]But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 ]and vice versa ] ]DOUBTS: ]1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say ] c3 as the DR. So the LAN will have more than on DR at a time this actually will be worse, the IS-1 and IS-2 may randomly setup adjacnecies with IS-3 on either c3 or c4 depends on the timing. since they will rejects the second adjacency setup due to conflict in systemID and mac addresses. ]2. If the IS won't have two interfaces on the same LAN as in the above ]topology , then why do we need to check for system ID and SNPA. for ]creating new adjacency over a circuit. I feel checking for System ID ]alone sufficient. So we can discard duplicate IIH. i guess the idea was to prevent accident. if you want to bring a new router into the LAN and misconfigure the systemID which duplicates the one already in operation, the proper behaviour should be the new router can not join the ISIS on this LAN instead of knocking off the one already working. since the chances are the new router probably is configured wrong. so this check on both systemID and mac address is useful. ] ]Pls correct me , if I'm wrong. ] - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Sep 12 10:32:29 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05050 for ; Tue, 12 Sep 2000 10:32:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA21419; Tue, 12 Sep 2000 07:43:26 -0700 (PDT) Received: from mail.vitts.com (mail.vitts.com [216.64.31.74]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA21389 for ; Tue, 12 Sep 2000 07:43:24 -0700 (PDT) From: larmer@commsense.net Received: from mail.vitts.com ([216.64.31.74]) by mail.vitts.com (InterMail vK.4.02.00.10 201-232-116-110 license 41b9a04052e49f5915685470d4b52094) with ESMTP id <20000912142911.MJSB583.mail.vitts.com@mail.vitts.com>; Tue, 12 Sep 2000 10:29:11 -0400 To: Cc: Reply-To: larmer@commsense.net Subject: Re: [Isis-wg] Doubt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <20000912142911.MJSB583.mail.vitts.com@mail.vitts.com> Date: Tue, 12 Sep 2000 10:29:11 -0400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi Selva, >I assume that, if any Hello PDU be received by an IS with system >Id same as the received IS, then it can be discarded. ie Receiving >own hello PDU. I could not find reference to this in ISO 10589, where is this spelled out? If they were not discarded, wouldn't the DR election process work correctly? > DOUBTS: > 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 >will say c3 as the DR. So the LAN will have more than one DR at a >time ISO 10589 states the following pertinent information in section 8.4.4 LAN Designated Intermediate Systems: d)After waiting ISISHelloTimer * 2 seconds, run the Level 1 and or the Level 2 Designated Intermediate System election process depending on the Intermediate system type. This shall be run subsequently whenever an IIH PDU is received or transmitted...(For these purposes, the transmission of the system's own IIH PDU is equivalent to receiving it)... If IS-3 discards one of the IIH PDUs, I don't believe the DR election process during circuit initialization will work properly. However, subsequent DR elections should work properly because IS-3 will know about both IIH PDUs being generated. Am I off in the weeds? Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Sep 12 16:49:55 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14111 for ; Tue, 12 Sep 2000 16:49:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA21906; Tue, 12 Sep 2000 13:58:50 -0700 (PDT) Received: from mail.vitts.com (mail.vitts.com [216.64.31.74]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA21835 for ; Tue, 12 Sep 2000 13:58:42 -0700 (PDT) From: larmer@commsense.net Received: from mail.vitts.com ([216.64.31.74]) by mail.vitts.com (InterMail vK.4.02.00.10 201-232-116-110 license 41b9a04052e49f5915685470d4b52094) with ESMTP id <20000912204426.NLLC583.mail.vitts.com@mail.vitts.com>; Tue, 12 Sep 2000 16:44:26 -0400 To: "'ISISWG'" Cc: Reply-To: larmer@commsense.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="larmer.commsense.net|E07E020FC8E32FC4A15FEACA3E3B906C-15074" Message-Id: <20000912204426.NLLC583.mail.vitts.com@mail.vitts.com> Date: Tue, 12 Sep 2000 16:44:27 -0400 Subject: [Isis-wg] SRMflag & SSNflag settings Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --larmer.commsense.net|E07E020FC8E32FC4A15FEACA3E3B906C-15074 Content-Type: text/plain; charset="iso-8859-1" Hi, I hope this is the correct forum for asking these questions. I am developing an IS-IS technology course and I have some questions, which I can't seem to get the answers to. I have included a text version of my questions and also a word attachment. I apologize for the lengthy questionnaire, though I appreciate any assistance in this area! I am trying to determine the correct settings for the SRMflag and SSNflag when a CSNP or PSNP are received over a Point-to-Point or Broadcast link. ISO-10589, Section 7.3.15.2, sub-section b) details what actions to take with respect to the SRMflag and the SSNflag when a SNP (either CSNP or PSNP) are received over a circuit (either broadcast or non-broadcast). It states the following: My interpretations and questions are proceeded by #. 7.3.15.2 Action on Receipt of a Sequence Numbers PDU When a Sequence Numbers PDU (Complete or Partial...) is received on circuit C the IS shall perform the following functions: a) Perform the following PDU acceptance tests: ... ... ... ... b) For each LSP reported in the Sequence Number PDU: 1)If the reported value equals the database value and C is a non-broadcast Circuit, Clear SRMflag for C for that LSP. #Non-broadcast: #PSNP received - Acknowledged receipt of LSP. #What do we do with the SSNflag? #CSNP received - Don't update a LSP on a circuit where an adjacent IS already possesses it. #Again, what do we do with the SSNflag? #Broadcast: #PSNP received - The DR sets the SRMflag for this LSP to update the LAN IS requesting this LSP. #Is this interpretation correct? #CSNP received - Do nothing, the LSP databases are synchronized with respect to this LSP. #Is this interpretation correct? 2)If the reported value is older than the database value, Clear SSNflag, and Set SRMflag. #Non-broadcast: #PSNP received - Acknowledgement of a received LSP, however, since the LSP was propagated minimumLSPTransmissionInterval expiration (lastSent) onto this circuit, the receiving IS has received a newer version of this LSP. Consequently, it will update the adjacent IS. #Is this why the SSNflag is cleared? #CSNP received - Update the adjacent IS. Why are we clearing the SSNflag? If this is circuit initialization, because we just received a CSNP, should any SSNflags for this circuit be set? Or, could the circuit have restarted and the SSNflags may represent a left over state? #Broadcast: #PSNP received - Does this mean that the requesting IS is out of date (perhaps dropped the latest CSNP due to congestion and is just getting around to requesting an update) and DR may have had its LSP updated since it sent the last CSNP? #If not, why are we requesting an older LSP? #CSNP received - Update the DR. 3)If the reported value is newer than the database value, Set SSNflag, and if C is a non-broadcast circuit Clear SRMflag. #Non-broadcast: #PSNP received - We are acknowledging a newer LSP than the adjacent IS possesses. #Why is the adjacent IS acknowledging a LSP we have not sent them? Or could this be a previous incarnation? #CSNP received - Do not update the adjacent IS with an older LSP. #Though, why set the SSNflag? #Broadcast: #PSNP received - We are requesting a newer LSP than the DR possesses. Why is this IS requesting a newer LSP and what should the DR do in this situation? #CSNP received - Request an updated LSP from the DR. 4)If no database entry exists for the LSP, and the reported Remaining Lifetime, Checksum and Sequence Number fields of the LSP are all non-zero, create an entry with sequence number 0 and set SSNflag for that entry and circuit C. Under no circumstances shall SRMflag be set for such an LSP with zero sequence number. #Non-Broadcast: #PSNP received - This makes no sense for a PSNP. #??? #CSNP received - Create an entry, but do not propagate. #Why set the SSNflag for a LSP we have not yet received? #Broadcast: #PSNP received - This makes no sense for a PSNP. #??? #CSNP received - Create an entry, but do not propagate and request this LSP from the DR. Regards, Ken Larmer CommSense Networks --larmer.commsense.net|E07E020FC8E32FC4A15FEACA3E3B906C-15074 Content-Type: application/msword Content-Disposition: attachment; filename="SRMflag & SSNflag.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKwAAAAAAAAAA EAAALQAAAAEAAAD+////AAAAACoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAAmhMAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIh4AADd8AAA3fAAAmg8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAKgAAAAAAAAAqAAAAKgA AAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAAqAAAABQAAAAAAAAAAAAAALwAAAAAAAAAMgcA AAAAAAAyBwAAAAAAADIHAAAAAAAAMgcAAAwAAAA+BwAAHAAAALwAAAAAAAAA+Q8AALYAAABmBwAA AAAAAGYHAAAAAAAAZgcAAAAAAABmBwAAAAAAAGYHAAAAAAAAZgcAAAAAAABmBwAAAAAAAGYHAAAA AAAAeA8AAAIAAAB6DwAAAAAAAHoPAAAAAAAAeg8AAAAAAAB6DwAAAAAAAHoPAAAAAAAAeg8AACQA AACvEAAAIAIAAM8SAAD4AAAAng8AABUAAAAAAAAAAAAAAAAAAAAAAAAAqAAAAAAAAABmBwAAAAAA AAAAAAAAAAAAAAAAAAAAAABmBwAAAAAAAGYHAAAAAAAAZgcAAAAAAABmBwAAAAAAAJ4PAAAAAAAA hgcAAAAAAACoAAAAAAAAAKgAAAAAAAAAZgcAAAAAAAAAAAAAAAAAAGYHAAAAAAAAsw8AABYAAACG BwAAAAAAAIYHAAAAAAAAhgcAAAAAAABmBwAAFgAAAKgAAAAAAAAAZgcAAAAAAACoAAAAAAAAAGYH AAAAAAAAeA8AAAAAAAAAAAAAAAAAAIYHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAZgcAAAAAAAB4DwAAAAAAAIYHAAB+BQAAhgcAAAAAAAAEDQAA HgAAACwPAAAYAAAAqAAAAAAAAACoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeA8AAAAAAABmBwAAAAAAAFoHAAAMAAAAEKYAjPIc wAG8AAAAdgYAADIHAAAAAAAAfAcAAAoAAABEDwAACAAAAAAAAAAAAAAAeA8AAAAAAADJDwAAMAAA APkPAAAAAAAATA8AACwAAADHEwAAAAAAAIYHAAAAAAAAxxMAAAAAAAB4DwAAAAAAAIYHAAAAAAAA vAAAAAAAAAC8AAAAAAAAAKgAAAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAAAgDZAAAASGks DQ0gICAgSSBob3BlIHRoaXMgaXMgdGhlIGNvcnJlY3QgZm9ydW0gZm9yIGFza2luZyB0aGVzZSBx dWVzdGlvbnMuIEkgYW0gZGV2ZWxvcGluZyBhbiBJUy1JUyB0ZWNobm9sb2d5IGNvdXJzZSBhbmQg SSBoYXZlIHNvbWUgcXVlc3Rpb25zLCB3aGljaCBJIGNhbpJ0IHNlZW0gdG8gZ2V0IHRoZSBhbnN3 ZXJzIHRvLiBJIGhhdmUgaW5jbHVkZWQgYSB0ZXh0IHZlcnNpb24gb2YgbXkgcXVlc3Rpb25zIGFu ZCBhbHNvIGEgd29yZCBhdHRhY2htZW50LiBJIGFwb2xvZ2l6ZSBmb3IgdGhlIGxlbmd0aHkgcXVl c3Rpb25uYWlyZSwgdGhvdWdoIEkgYXBwcmVjaWF0ZSBhbnkgYXNzaXN0YW5jZSBpbiB0aGlzIGFy ZWEhIA0NICAgIEkgYW0gdHJ5aW5nIHRvIGRldGVybWluZSB0aGUgY29ycmVjdCBzZXR0aW5ncyBm b3IgdGhlIFNSTWZsYWcgYW5kIFNTTmZsYWcgd2hlbiBhIENTTlAgb3IgUFNOUCBhcmUgcmVjZWl2 ZWQgb3ZlciBhIFBvaW50LXRvLVBvaW50IG9yIEJyb2FkY2FzdCBsaW5rLiBJU08tMTA1ODksIFNl Y3Rpb24gNy4zLjE1LjIsIHN1Yi1zZWN0aW9uIGIpIGRldGFpbHMgd2hhdCBhY3Rpb25zIHRvIHRh a2Ugd2l0aCByZXNwZWN0IHRvIHRoZSBTUk1mbGFnIGFuZCB0aGUgU1NOZmxhZyB3aGVuIGEgU05Q IChlaXRoZXIgQ1NOUCBvciBQU05QKSBhcmUgcmVjZWl2ZWQgb3ZlciBhIGNpcmN1aXQgKGVpdGhl ciBicm9hZGNhc3Qgb3IgUG9pbnQtdG8tUG9pbnQpLiBJdCBzdGF0ZXMgdGhlIGZvbGxvd2luZzog TXkgaW50ZXJwcmV0YXRpb25zIGFuZCBxdWVzdGlvbnMgYXJlIHByb2NlZWRlZCBieSAjLg0NNy4z LjE1LjIgQWN0aW9uIG9uIFJlY2VpcHQgb2YgYSBTZXF1ZW5jZSBOdW1iZXJzIFBEVQ1XaGVuIGEg U2VxdWVuY2UgTnVtYmVycyBQRFUgKENvbXBsZXRlIG9yIFBhcnRpYWyFKSBpcyByZWNlaXZlZCBv biBjaXJjdWl0IEMgdGhlIElTIHNoYWxsIHBlcmZvcm0gdGhlIGZvbGxvd2luZyBmdW5jdGlvbnM6 DWEpIIUNhQ2FDYUNhQ1iKSBGb3IgZWFjaCBMU1AgcmVwb3J0ZWQgaW4gdGhlIFNlcXVlbmNlIE51 bWJlciBQRFU6DQ1JZiB0aGUgcmVwb3J0ZWQgdmFsdWUgZXF1YWxzIHRoZSBkYXRhYmFzZSB2YWx1 ZSBhbmQgQyBpcyBhIG5vbi1icm9hZGNhc3QgQ2lyY3VpdCwgQ2xlYXIgU1JNZmxhZyBmb3IgQyBm b3IgdGhhdCBMU1AuDQ0jTm9uLWJyb2FkY2FzdDoNI1BTTlAgcmVjZWl2ZWQgliBBY2tub3dsZWRn ZWQgcmVjZWlwdCBvZiBMU1AuIA0jV2hhdCBkbyB3ZSBkbyB3aXRoIHRoZSBTU05mbGFnPw0NI0NT TlAgcmVjZWl2ZWQgLSBEb26SdCB1cGRhdGUgYSBMU1Agb24gYSBjaXJjdWl0IHdoZXJlIGFuIGFk amFjZW5jeSBJUy4gI2FscmVhZHkgcG9zc2Vzc2VzIGl0Lg0jQWdhaW4sIHdoYXQgZG8gd2UgZG8g d2l0aCB0aGUgU1NOZmxhZz8NDSNCcm9hZGNhc3Q6DSNQU05QIHJlY2VpdmVkIJYgVGhlIERSIHNl dHMgdGhlIFNSTWZsYWcgZm9yIHRoaXMgTFNQIHRvIHVwZGF0ZSB0aGUgTEFOIElTICNyZXF1ZXN0 aW5nIHRoaXMgTFNQLg0jV2h5IGlzbpJ0IHRoaXMgc3RhdGVkPw0NI0NTTlAgcmVjZWl2ZWQgliBE byBub3RoaW5nLCB0aGUgTFNQIGRhdGFiYXNlcyBhcmUgc3luY2hyb25pemVkIHdpdGggcmVzcGVj dCAjdG8gdGhpcyBMU1AuDSNBZ2Fpbiwgd2h5IGlzbpJ0IHRoaXMgc3RhdGVkDQ1JZiB0aGUgcmVw b3J0ZWQgdmFsdWUgaXMgb2xkZXIgdGhhbiB0aGUgZGF0YWJhc2UgdmFsdWUsIENsZWFyIFNTTmZs YWcsIGFuZCBTZXQgU1JNZmxhZy4NDSNOb24tYnJvYWRjYXN0Og0jUFNOUCByZWNlaXZlZCCWIEFj a25vd2xlZGdlbWVudCBvZiBhIHJlY2VpdmVkIExTUCwgaG93ZXZlciwgc2luY2UgdGhlIExTUCAj d2FzIHByb3BhZ2F0ZWQgbWluaW11bUxTUFRyYW5zbWlzc2lvbkludGVydmFsIGV4cGlyYXRpb24g KGxhc3RTZW50KSBvbnRvICN0aGlzIGNpcmN1aXQsIHRoZSByZWNlaXZpbmcgSVMgaGFzIHJlY2Vp dmVkIGEgbmV3ZXIgdmVyc2lvbiBvZiB0aGlzIExTUC4gI0NvbnNlcXVlbnRseSBpdCB3aWxsIHVw ZGF0ZSB0aGUgYWRqYWNlbnQgSVMuIA0jSXMgdGhpcyB3aHkgdGhlIFNTTmZsYWcgaXMgY2xlYXJl ZD8gDQ0jQ1NOUCByZWNlaXZlZCAtIFVwZGF0ZSB0aGUgYWRqYWNlbnQgSVMuDSNXaHkgYXJlIHdl IGNsZWFyaW5nIHRoZSBTU05mbGFnPyBJZiB0aGlzIGlzIGNpcmN1aXQgaW5pdGlhbGl6YXRpb24s IGJlY2F1c2Ugd2UganVzdCAjcmVjZWl2ZWQgYSBDU05QLCBzaG91bGQgYW55IFNTTmZsYWdzIGZv ciB0aGlzIGNpcmN1aXQgYmUgc2V0PyBPciwgY291bGQgdGhlICNjaXJjdWl0IGhhdmUgcmVzdGFy dGVkIGFuZCB0aGUgU1NOZmxhZ3MgbWF5IHJlcHJlc2VudCBhIGxlZnQgb3ZlciBzdGF0ZT8NDSNC cm9hZGNhc3Q6DSNQU05QIHJlY2VpdmVkIJYgRG9lcyB0aGlzIG1lYW4gdGhhdCB0aGUgcmVxdWVz dGluZyBJUyBpcyBvdXQgb2YgZGF0ZSAocGVyaGFwcyBkcm9wcGVkIHRoZSBsYXRlc3QgQ1NOUCBk dWUgdG8gY29uZ2VzdGlvbiBhbmQgaXMganVzdCBnZXR0aW5nIGFyb3VuZCB0byByZXF1ZXN0aW5n IGFuIHVwZGF0ZSkgYW5kIERSIG1heSBoYXZlIGhhZCBpdHMgTFNQIHVwZGF0ZWQgc2luY2UgaXQg c2VudCB0aGUgbGFzdCBDU05QPw0jSWYgbm90LCB3aHkgYXJlIHdlIHJlcXVlc3RpbmcgYW4gb2xk ZXIgTFNQPyANDSNDU05QIHJlY2VpdmVkIJYgVXBkYXRlIHRoZSBEUi4NDUlmIHRoZSByZXBvcnRl ZCB2YWx1ZSBpcyBuZXdlciB0aGFuIHRoZSBkYXRhYmFzZSB2YWx1ZSwgU2V0IFNTTmZsYWcsIGFu ZCBpZiBDIGlzIGEgbm9uLWJyb2FkY2FzdCBjaXJjdWl0IENsZWFyIFNSTWZsYWcuDQ0jTm9uLWJy b2FkY2FzdDoNI1BTTlAgcmVjZWl2ZWQgliBXZSBhcmUgYWNrbm93bGVkZ2luZyBhIG5ld2VyIExT UCB0aGFuIHRoZSBhZGphY2VudCBJUyAjcG9zc2Vzc2VzLg0jV2h5IGlzIHRoZSBhZGphY2VudCBJ UyBhY2tub3dsZWRnaW5nIGEgTFNQIHdlIGhhdmUgbm90IHNlbnQgdGhlbT8gT3IgY291bGQgI3Ro aXMgYmUgYSBwcmV2aW91cyBpbmNhcm5hdGlvbiBvZiBzb21lIHNvcnQ/DQ0jQ1NOUCByZWNlaXZl ZCCWIERvIG5vdCB1cGRhdGUgdGhlIGFkamFjZW50IElTIHdpdGggYW4gb2xkZXIgTFNQLiANI1Ro b3VnaCwgd2h5IHNldCB0aGUgU1NOZmxhZz8gDQ0jQnJvYWRjYXN0Og0jUFNOUCByZWNlaXZlZCCW IFdlIGFyZSByZXF1ZXN0aW5nIGEgbmV3ZXIgTFNQIHRoYW4gdGhlIERSIHBvc3Nlc3Nlcy4NI1do eSBpcyB0aGlzIElTIHJlcXVlc3RpbmcgYSBuZXdlciBMU1AgYW5kIHdoYXQgc2hvdWxkIHRoZSBE UiBkbyBpbiB0aGlzICNzaXR1YXRpb24/IA0NI0NTTlAgcmVjZWl2ZWQgliBSZXF1ZXN0IGFuIHVw ZGF0ZWQgTFNQIGZyb20gdGhlIERSLiAgDQ1JZiBubyBkYXRhYmFzZSBlbnRyeSBleGlzdHMgZm9y IHRoZSBMU1AsIGFuZCB0aGUgcmVwb3J0ZWQgUmVtYWluaW5nIExpZmV0aW1lLCBDaGVja3N1bSBh bmQgU2VxdWVuY2UgTnVtYmVyIGZpZWxkcyBvZiB0aGUgTFNQIGFyZSBhbGwgbm9uLXplcm8sIGNy ZWF0ZSBhbiBlbnRyeSB3aXRoIHNlcXVlbmNlIG51bWJlciAwIGFuZCBzZXQgU1NOZmxhZyBmb3Ig dGhhdCBlbnRyeSBhbmQgY2lyY3VpdCBDLiBVbmRlciBubyBjaXJjdW1zdGFuY2VzIHNoYWxsIFNS TWZsYWcgYmUgc2V0IGZvciBzdWNoIGFuIExTUCB3aXRoIHplcm8gc2VxdWVuY2UgbnVtYmVyLg0N I05vbi1Ccm9hZGNhc3Q6DSNQU05QIHJlY2VpdmVkIJYgVGhpcyBtYWtlcyBubyBzZW5zZSBmb3Ig YSBQU05QLiANIz8/Pw0NI0NTTlAgcmVjZWl2ZWQgliBDcmVhdGUgYW4gZW50cnksIGJ1dCBkbyBu b3QgcHJvcGFnYXRlLg0jV2h5IHNldCB0aGUgU1NOZmxhZyBmb3IgYSBMU1Agd2UgaGF2ZSBub3Qg eWV0IHJlY2VpdmVkPw0NI0Jyb2FkY2FzdDoNI1BTTlAgcmVjZWl2ZWQgliBUaGlzIG1ha2VzIG5v IHNlbnNlIGZvciBhIFBTTlAuDSM/Pz8NDSNDU05QIHJlY2VpdmVkIJYgQ3JlYXRlIGFuIGVudHJ5 LCBidXQgZG8gbm90IHByb3BhZ2F0ZSBhbmQgcmVxdWVzdCB0aGlzIExTUCAjZnJvbSB0aGUgRFIu DQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAACaEwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAQAAAQEAAAFBAAA XgUAAF8FAAAdBwAAHgcAAFMHAADNBwAA0gcAANQHAADWBwAA2AcAANoHAAAPCAAAEAgAAIQIAACF CAAAlQgAAMQIAADlCAAA5ggAAEUJAABtCQAAbgkAAHoJAADbCQAA8wkAAPQJAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAA AAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAA AAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADy AAAAAAAAAAAAAAAAAAAAAAAFAAAPhNACXoTQAgUAAAomAAtGAQAAAQAAABwABAAAmhMAAP0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBAfQJAABPCgAAbQoAAG4K AADGCgAAxwoAANcKAADlCwAACwwAAAwMAAA1DAAAIQ0AACINAAAuDQAAHA4AAEoOAABLDgAAaw4A AGwOAADkDgAA5Q4AAPUOAABIDwAAwg8AAMMPAAAGEAAAJRAAACYQAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADyAAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAA AAAABQAAD4RoAV6EaAEFAAAKJgALRgEAAAEAAAAFAAAPhNACXoTQAgAbJhAAADIQAAB4EAAAzhAA AM8QAAAGEQAABxEAAEISAABDEgAAUxIAAIUSAACKEgAAixIAAMMSAAD8EgAA/RIAAAkTAAA6EwAA PxMAAEATAACaEwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAFAAAKJgALRgEAAAUAAA+EaAFehGgBAAUAAA+E0AJehNACABQgADGQaAEfsNAvILDgPSGw CAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQADwAKAAEAaQAPAAMAAAAA AAAAAAA4AABA8f8CADgADAAGAE4AbwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNI CQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAwAFgBEAGUAZgBhAHUAbAB0ACAAUABh AHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAAAAAAACaDwAACwAAHgAADAD///// AAAAAAQAAAAFAAAAXgEAAF8BAAAdAwAAHgMAAFMDAADNAwAA0gMAANQDAADWAwAA2AMAANoDAAAP BAAAEAQAAIQEAACFBAAAlQQAAMQEAADlBAAA5gQAAEUFAABtBQAAbgUAAHoFAADbBQAA8wUAAPQF AABPBgAAbQYAAG4GAADGBgAAxwYAANcGAADlBwAACwgAAAwIAAA1CAAAIQkAACIJAAAuCQAAHAoA AEoKAABLCgAAawoAAGwKAADkCgAA5QoAAPUKAABICwAAwgsAAMMLAAAGDAAAJQwAACYMAAAyDAAA eAwAAM4MAADPDAAABg0AAAcNAABCDgAAQw4AAFMOAACFDgAAig4AAIsOAADDDgAA/A4AAP0OAAAJ DwAAOg8AAD8PAABADwAAnA8AAJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAASAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAASAAMAEAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAASAAMAIA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAASAAMAMAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAA gAAEAACaEwAACgAAAAAEAAD0CQAAJhAAAJoTAAALAAAADQAAAA4AAAAABAAAmhMAAAwAAAAAAAAA ZQkAAGcJAACcDwAABwAbAAcAAAAAAJwPAAAHAP//FAAAAAoASwBlAG4AIABMAGEAcgBtAGUAcgAl AEQAOgBcAEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMA TgBmAGwAYQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByAGsAQwA6AFwARABvAGMAdQBt AGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAEwAYQByAG0AZQByAFwAQQBwAHAA bABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABc AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFMAUgBNAGYAbABhAGcA IAAmACAAUwBTAE4AZgBsAGEAZwAuAGEAcwBkAAoASwBlAG4AIABMAGEAcgBtAGUAcgAlAEQAOgBc AEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMATgBmAGwA YQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByACUARAA6AFwASQBzAC0AaQBzACAAYwBv AHUAcgBzAGUAXABTAFIATQBmAGwAYQBnACAAJgAgAFMAUwBOAGYAbABhAGcALgBkAG8AYwAKAEsA ZQBuACAATABhAHIAbQBlAHIAJQBEADoAXABJAHMALQBpAHMAIABjAG8AdQByAHMAZQBcAFMAUgBN AGYAbABhAGcAIAAmACAAUwBTAE4AZgBsAGEAZwAuAGQAbwBjAAoASwBlAG4AIABMAGEAcgBtAGUA cgAlAEQAOgBcAEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABT AFMATgBmAGwAYQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByAGsAQwA6AFwARABvAGMA dQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAEwAYQByAG0AZQByAFwAQQBw AHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIA ZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFMAUgBNAGYAbABh AGcAIAAmACAAUwBTAE4AZgBsAGEAZwAuAGEAcwBkAAoASwBlAG4AIABMAGEAcgBtAGUAcgAlAEQA OgBcAEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMATgBm AGwAYQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByACUARAA6AFwASQBzAC0AaQBzACAA YwBvAHUAcgBzAGUAXABTAFIATQBmAGwAYQBnACAAJgAgAFMAUwBOAGYAbABhAGcALgBkAG8AYwAK AEsAZQBuACAATABhAHIAbQBlAHIAawBDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAA UwBlAHQAdABpAG4AZwBzAFwATABhAHIAbQBlAHIAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABE AGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYA ZQByAHkAIABzAGEAdgBlACAAbwBmACAAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMATgBmAGwAYQBn AC4AYQBzAGQAAQC2YxwzOChgO/8P/w//D/8P/w//D/8P/w//DxAAAQAAAAAAAQAAAAAAAAAAAGgB AAAAAAAAABgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/gIAAAApAAEAAAAEgAEAAAAAAAAAAAAA AAAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAAAoIBAAAAAAAAAAAA AAAAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACAAQAAAAAAAAAA AAAAAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEgAEAAAAAAAAA AAAAAAAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAAoIBAAAAAAAA AAAAAAAAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACAAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEgAEAAAAA AAAAAAAAAAAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAAoIBAAAA AAAAAAAAAAAAAAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAALZjHDMA AAAAAAAAAAAAAAD///////8BAAAAAAD//wEAAAASABEACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8A CQQZAAkEGwAJBP9AA4ABAIwPAACMDwAArIxzAAEAMACMDwAAAAAAAIwPAAAAAAAAAhAAAAAAAAAA mg8AALAAAAgAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAA AP//AAACAP//AAAAAP//AAACAP//AAAAAAMAAABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAA AAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcG AgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIE h3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAIgAEAHEIiRgA8NACAABoAQAAAABV Y0lG8WNJRgAAAAAIAJQAAABBAgAA3QwAAAEABgAAAAQAAxAbAAAAAAAAAAAAAAABAAEAAAABAAAA AAAAACEDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgHoAW0ALQAgYFyMAAAAAAAAAAA AAAAAAAAzA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEIOAAAA AAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAACDKDUQDwEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP//EgAAAAAAUABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBl AHQAdABpAG4AZwBzAFwATABhAHIAbQBlAHIAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEA dABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABUAGUAbQBwAGwAYQB0AGUAcwBcAE4AbwByAG0AYQBs AC4AZABvAHQAAwBIAGkALAAAAAAAAAAKAEsAZQBuACAATABhAHIAbQBlAHIACgBLAGUAbgAgAEwA YQByAG0AZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAA AOCFn/L5T2gQq5EIACsns9kwAAAAcAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAKQAAAAEAAAA sAAAAAUAAADEAAAABgAAANAAAAAHAAAA3AAAAAgAAADwAAAACQAAAAQBAAASAAAAEAEAAAoAAAAs AQAADAAAADgBAAANAAAARAEAAA4AAABQAQAADwAAAFgBAAAQAAAAYAEAABMAAABoAQAAAgAAAOQE AAAeAAAABAAAAEhpLAAeAAAAAQAAAABpLAAeAAAACwAAAEtlbiBMYXJtZXIAAB4AAAABAAAAAGVu IB4AAAABAAAAAGVuIB4AAAALAAAATm9ybWFsLmRvdAAAHgAAAAsAAABLZW4gTGFybWVyAAAeAAAA AgAAADgAbiAeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDkuMAAAQAAAAAB45KwUAAAAQAAAAAAm09Hd HMABQAAAAACet37yHMABAwAAAAEAAAADAAAAQQIAAAMAAADdDAAAAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4b EJOXCAArLPmuMAAAAAABAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACQAAAABgAAAJgAAAARAAAA oAAAABcAAACoAAAACwAAALAAAAAQAAAAuAAAABMAAADAAAAAFgAAAMgAAAANAAAA0AAAAAwAAADg AAAAAgAAAOQEAAAeAAAAFgAAAENvbW1TZW5zZSBFbmdpbmVlcmluZwBlAAMAAAAbAAAAAwAAAAYA AAADAAAAzA8AAAMAAACgCgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAA AAQAAABIaSwADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAA AAwAAAANAAAADgAAAA8AAAD+////EQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA /v///xsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAD+////IwAAACQAAAAlAAAAJgAAACcAAAAo AAAAKQAAAP7////9////LAAAAP7////+/////v////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAA AAAAAAAAADBHCIzyHMABLgAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAxxMAAAAAAABXAG8AcgBkAEQAbwBjAHUA bQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUAAAD/ /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiHgAAAAAAAAUA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBh AHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAiAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBv AGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAwRwiM8hzAATBHCIzyHMABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQg RG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA --larmer.commsense.net|E07E020FC8E32FC4A15FEACA3E3B906C-15074-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Sep 12 18:11:31 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14712 for ; Tue, 12 Sep 2000 18:11:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA22038; Tue, 12 Sep 2000 15:22:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA22011 for ; Tue, 12 Sep 2000 15:22:34 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA29288; Tue, 12 Sep 2000 16:08:17 -0600 (MDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA06453; Tue, 12 Sep 2000 18:08:13 -0400 (EDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id SAA22286; Tue, 12 Sep 2000 18:08:12 -0400 (EDT) Message-Id: <200009122208.SAA22286@bcn.East.Sun.COM> Date: Tue, 12 Sep 2000 18:08:12 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] SRMflag & SSNflag settings To: isis-wg@spider.juniper.net, larmer@commsense.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: pqpKbQWWOo5ZybtdYBfL6g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net I don't have the time to answer thoroughly, but let me make a comment that will hopefully make things easier to understand. I don't remember why this was specified as two binary flags SRM and SSN. Instead I think it's clearer to think of it as a single "state" variable with 3 settings: OK (don't need to send ack or LSP) ACK (i.e., SSN, need to send ack) XMIT (i.e., SRM, need to transmit LSP) You never should have both SSN and SRM flags set. You send an ack once and then change the state to "OK". You send an LSP if SRM is set (state is "XMIT") until you get an ack or the same LSP from that neighbor. If an ack, you change state to "OK". If you receive the same LSP from a neighbor N you set the state to "ack" for that neighbor. If you receive a new LSP from N you set the state to N to "ack" and to everyone else as "XMIT". You keep transmitting to a neighbor until you get an ack from that nbr, or the same LSP from that nbr. This isn't very complete, I'm sure...but the main thing I wanted to clarify is (unless I've completely forgotten this...it's been about 85 years ... ) that you'd never want both SSN and SRM set. Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 06:13:23 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07935 for ; Thu, 14 Sep 2000 06:13:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA24100; Thu, 14 Sep 2000 03:23:31 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA24073 for ; Thu, 14 Sep 2000 03:23:27 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 14 Sep 2000 15:52:32 +0530 Received: from selvarajr ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id PAA07999; Thu, 14 Sep 2000 15:26:39 +0530 Received: by localhost with Microsoft MAPI; Thu, 14 Sep 2000 15:29:13 +0530 Message-Id: <01C01E60.89087360.selvarajr@future.futsoft.com> From: selvarajR Reply-To: "selvarajr@future.futsoft.com" To: "'Naiming Shen'" Cc: "'isiswg'" Subject: RE: [Isis-wg] Doubt Date: Thu, 14 Sep 2000 15:29:12 +0530 Organization: future softw X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit >this actually will be worse, the IS-1 and IS-2 may randomly setup >adjacnecies with IS-3 on either c3 or c4 depends on the timing. since >they will rejects the second adjacency setup due to conflict in systemID >and mac addresses. Yes that is possible if c1 and c2 already exist on the network before c3 or c4. For instance if another IS , IS-4, be commimg up then there is no gaurentee that IS-4 also will form the same adjacency with IS-3 as IS-1 & IS-2. Selva -----Original Message----- From: Naiming Shen [SMTP:naiming@redback.com] Sent: Tuesday, September 12, 2000 1:04 PM To: selvarajr@future.futsoft.com Cc: 'ISISWG' Subject: Re: [Isis-wg] Doubt ] ] IS - 1 IS - 2 ] | | ] | c1 | c2 ]----------------------------------------------------------- ] c3 | | c4 ] | | ] | | ] IS - 3 ] ]For the above broadcast topology let, ] IS-1, IS-2 & IS-3 be three L1 intermediate systems ] c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up ]link for IS-3. ] Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. ] ]Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ]ystem Id but, different SNPA. ]But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 ]and vice versa ] ]DOUBTS: ]1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say ] c3 as the DR. So the LAN will have more than on DR at a time this actually will be worse, the IS-1 and IS-2 may randomly setup adjacnecies with IS-3 on either c3 or c4 depends on the timing. since they will rejects the second adjacency setup due to conflict in systemID and mac addresses. ]2. If the IS won't have two interfaces on the same LAN as in the above ]topology , then why do we need to check for system ID and SNPA. for ]creating new adjacency over a circuit. I feel checking for System ID ]alone sufficient. So we can discard duplicate IIH. i guess the idea was to prevent accident. if you want to bring a new router into the LAN and misconfigure the systemID which duplicates the one already in operation, the proper behaviour should be the new router can not join the ISIS on this LAN instead of knocking off the one already working. since the chances are the new router probably is configured wrong. so this check on both systemID and mac address is useful. ] ]Pls correct me , if I'm wrong. ] - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 06:14:34 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07954 for ; Thu, 14 Sep 2000 06:14:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA24152; Thu, 14 Sep 2000 03:26:07 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA24120 for ; Thu, 14 Sep 2000 03:26:02 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 14 Sep 2000 15:55:02 +0530 Received: from selvarajr ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id PAA08068; Thu, 14 Sep 2000 15:29:15 +0530 Received: by localhost with Microsoft MAPI; Thu, 14 Sep 2000 15:31:47 +0530 Message-Id: <01C01E60.E551A240.selvarajr@future.futsoft.com> From: selvarajR Reply-To: "selvarajr@future.futsoft.com" To: "'larmer@commsense.net'" Cc: "'isiswg'" Subject: FW: [Isis-wg] Doubt Date: Thu, 14 Sep 2000 15:31:46 +0530 Organization: future softw X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hi, I was out of station for the past two days. So I couldn't reply imedietly Sorry. If adjacency with neighbours having same system Id as the local system be established then those neighbours won't get in the SPF tree construction. Because local systems cost will be zero and hence the neighbour gets overridden. So no way the adjacency is usefull. If there is no such validation then there will be a possibility that all IS on the LAN ( even whole domain) having same system ID. Won't it be ? So neighbours with conflicting SNPA and System ID be detected it can better be ignored. In any way it is NOT useful. Having useless things is better not having it. Selva. -----Original Message----- From: larmer@commsense.net [SMTP:larmer@commsense.net] Sent: Tuesday, September 12, 2000 7:59 PM To: selvarajr@kailash.future.futsoft.com Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Doubt Hi Selva, >I assume that, if any Hello PDU be received by an IS with system >Id same as the received IS, then it can be discarded. ie Receiving >own hello PDU. I could not find reference to this in ISO 10589, where is this spelled out? If they were not discarded, wouldn't the DR election process work correctly? > DOUBTS: > 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 >will say c3 as the DR. So the LAN will have more than one DR at a >time ISO 10589 states the following pertinent information in section 8.4.4 LAN Designated Intermediate Systems: d)After waiting ISISHelloTimer * 2 seconds, run the Level 1 and or the Level 2 Designated Intermediate System election process depending on the Intermediate system type. This shall be run subsequently whenever an IIH PDU is received or transmitted...(For these purposes, the transmission of the system's own IIH PDU is equivalent to receiving it)... If IS-3 discards one of the IIH PDUs, I don't believe the DR election process during circuit initialization will work properly. However, subsequent DR elections should work properly because IS-3 will know about both IIH PDUs being generated. Am I off in the weeds? Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 10:57:01 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13510 for ; Thu, 14 Sep 2000 10:57:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA24472; Thu, 14 Sep 2000 08:03:12 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA24440 for ; Thu, 14 Sep 2000 08:03:09 -0700 (PDT) Received: from [204.242.142.104] (helo=bena) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) for isis-wg@external.juniper.net id 13ZaJb-0003lz-00; Thu, 14 Sep 2000 10:48:39 -0400 Message-ID: <004a01c01e5b$79d2f6e0$8b01020a@ipoptical.com> Reply-To: "ben abarbanel" From: "ben abarbanel" To: Date: Thu, 14 Sep 2000 10:52:59 -0400 Organization: IPOptical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C01E39.F2750BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Isis-wg] IS-IS TE Question Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C01E39.F2750BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a = question came to mind regarding=20 unreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth = states "for stability reasons, rapid changes in the values in this = sub-TLV should not cause rapid generation of LSPs".=20 =20 I was wondering what if 2 ingress (head end RSVP) LSR routers are = provisioning LSPs (each wanting 100 Mbytes) through the same core = convergent LSR interface and each one of the routers at the time they = privision their LSP think there is 100 Mbyte of bandwidth free to = complete the job. In reality there is a total of 100 MBYTE for the whole = interface, the first RSVP reservation succeeds while the second fails.=20 =20 The second LSP Ingress router would ask TE Source routing for another = next bandwidth constraint best path to setup the LSP. How efficient is = that if many LSPs coverge in the core of the network this way and there = is no precise way to say what is available at the time RSVP is trigered = on? Also, since the IS-IS and its TE source routing engine take snap shots = of the bandwidth resources in the network it has a tunnel view of what = other IS-IS(LSR) routers are doing to this information at that moment in = time, and are making inaccurate determination of what is reserved and = what is free. The IS-IS route convergent time could be much slower than = the RSVP signalling time. The following is my assumption, please clarify if I am wrong, thanks if a series of LSP requests are hitting a given IS-IS router (TE source = routing engine) at the same processing window/cycle, it makes = assignments based on a frozen snap shot of the bandwidth in the network. = Assignments are made without consideration for their RSVP signalling = success/failure and eventually the signalling components would fail = their reservation requests causing turbulance with LSP attempts. Assuming most of what i said is true, do we need another more precise = mechanism to solve this? =20 Regards, Ben=20 =20 Ben Abarbanel, Software Engineering, =20 Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ------=_NextPart_000_0047_01C01E39.F2750BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
I was reading the latest draft=20 "draft-ietf-isis-traffic-02.txt" and a question came to mind regarding=20
unreserved bandwidth. In section 5.4 = SUB-TLV 11:=20 Unreserved bandwidth states "for stability reasons, rapid changes in the values in this sub-TLV should not cause = rapid=20 generation of LSPs".
 
I was wondering what=20 if  2 ingress (head end RSVP) LSR routers are provisioning LSPs = (each=20 wanting 100 Mbytes) through the same = core=20 convergent LSR interface and each one = of the routers at the time they = privision their LSP think there is 100 Mbyte of bandwidth free to complete = the job. In reality there is a total of 100 MBYTE = for the=20 whole interface, the first RSVP reservation succeeds while the second = fails.=20
 
The second LSP Ingress router = would ask TE=20 Source routing for another next bandwidth constraint best path to setup = the=20 LSP.  How efficient is that if many LSPs coverge in the core of the network this = way and=20 there is no precise way to say what is available=20 at the time RSVP is trigered on?
 
Also, since the IS-IS and its TE = source=20 routing engine take snap shots of the bandwidth resources in the = network it=20 has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are = making=20 inaccurate determination of what is reserved and what is free. The IS-IS = route=20 convergent time could be much slower than the RSVP signalling = time.
 
The following is my assumption, please clarify if I am wrong, = thanks
 
if a series of LSP=20 requests are hitting a given IS-IS router (TE source routing = engine) at the=20 same processing window/cycle, it makes=20 assignments based on a frozen snap shot of the bandwidth in the network. = Assignments are made without consideration for=20 their RSVP signalling success/failure and eventually the signalling = components=20 would fail their reservation requests causing turbulance with LSP attempts.
 
 
Assuming most of what i said is true, = do we need=20 another more precise mechanism to solve this? 
 
Regards,
Ben 
 
 
Ben Abarbanel,  Software = Engineering, =20
 
Phone:  703 456=20 2982
FAX:     703 456 2952
 
IPOptical, Inc.
11480 Sunset Hills = Road
Suite=20 #200E
Reston, VA 20190
------=_NextPart_000_0047_01C01E39.F2750BA0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 11:17:01 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16833 for ; Thu, 14 Sep 2000 11:17:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA24556; Thu, 14 Sep 2000 08:28:04 -0700 (PDT) Received: from server.nayna.com (069-035.dsl.popsite.net [64.24.69.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA24527 for ; Thu, 14 Sep 2000 08:28:01 -0700 (PDT) Received: from nayna.com (069-034.dsl.popsite.net [64.24.69.34]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id IAA30534; Thu, 14 Sep 2000 08:04:52 -0700 X-Authentication-Warning: server.nayna.com: Host 069-034.dsl.popsite.net [64.24.69.34] claimed to be nayna.com Message-ID: <39C0E928.21831FC7@nayna.com> Date: Thu, 14 Sep 2000 08:05:12 -0700 From: Sudheer Dharnikota X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ben abarbanel , isiswg Subject: Re: [Isis-wg] IS-IS TE Question References: <004a01c01e5b$79d2f6e0$8b01020a@ipoptical.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Bena: This is a famous problem with the receiver-oriented reservation mechanims. Where on the downstream side you do the CAC and on the upstream side you do the actual reservaion. I am not sure if we have a straight-forward answer for this. I would also assume that the geneic consensus is pray god that it will not happen (which is the generic approach taken till now) or use different criteria for the second LSP after it failed - as proposed in draft-dharanikota-interarea-mpls-te-ext-00.txt Cheers, sudheer > ben abarbanel wrote: > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a > question came to mind regarding > unreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth > states "for stability reasons, rapid changes in the values in this > sub-TLV should not cause rapid generation of LSPs". > > I was wondering what if 2 ingress (head end RSVP) LSR routers are > provisioning LSPs (each wanting 100 Mbytes) through the same core > convergent LSR interface and each one of the routers at the time they > privision their LSP think there is 100 Mbyte of bandwidth free to > complete the job. In reality there is a total of 100 MBYTE for the > whole interface, the first RSVP reservation succeeds while the second > fails. > > The second LSP Ingress router would ask TE Source routing for another > next bandwidth constraint best path to setup the LSP. How efficient > is that if many LSPs coverge in the core of the network this way and > there is no precise way to say what is available at the time RSVP is > trigered on? > > Also, since the IS-IS and its TE source routing engine take snap shots > of the bandwidth resources in the network it has a tunnel view of what > other IS-IS(LSR) routers are doing to this information at that moment > in time, and are making inaccurate determination of what is reserved > and what is free. The IS-IS route convergent time could be much slower > than the RSVP signalling time. > > The following is my assumption, please clarify if I am wrong, thanks > > if a series of LSP requests are hitting a given IS-IS router (TE > source routing engine) at the same processing window/cycle, it makes > assignments based on a frozen snap shot of the bandwidth in the > network. Assignments are made without consideration for their RSVP > signalling success/failure and eventually the signalling components > would fail their reservation requests causing turbulance with LSP > attempts. > > > Assuming most of what i said is true, do we need another more precise > mechanism to solve this? > > Regards, > Ben > > > Ben Abarbanel, Software Engineering, > > Phone: 703 456 2982 > FAX: 703 456 2952 > > IPOptical, Inc. > 11480 Sunset Hills Road > Suite #200E > Reston, VA 20190 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 12:33:46 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18467 for ; Thu, 14 Sep 2000 12:33:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA24713; Thu, 14 Sep 2000 09:44:15 -0700 (PDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA24637 for ; Thu, 14 Sep 2000 09:44:11 -0700 (PDT) Received: from zrchh190 by smtprch2.nortel.com; Thu, 14 Sep 2000 11:22:06 -0500 Received: from zcard00p.ca.nortel.com by zrchh190; Thu, 14 Sep 2000 11:26:55 -0500 Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id SY0DTKD0; Thu, 14 Sep 2000 12:25:29 -0400 Message-ID: <39C0FBF9.210F4C54@americasm01.nt.com> Date: Thu, 14 Sep 2000 12:25:29 -0400 From: "Darek Skalecki" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ben abarbanel CC: isis-wg Subject: Re: [Isis-wg] IS-IS TE Question References: <004a01c01e5b$79d2f6e0$8b01020a@ipoptical.com> Content-Type: multipart/mixed; boundary="------------7D3D0D0254DA76A03206253F" X-Orig: X-Orig: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This is a multi-part message in MIME format. --------------7D3D0D0254DA76A03206253F Content-Type: multipart/alternative; boundary="------------5FA9CB3C8BB65B95B52F29AF" --------------5FA9CB3C8BB65B95B52F29AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote: > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a > question came to mind regardingunreserved bandwidth. In section 5.4 > SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid > changes in the values in this sub-TLV should not cause rapid > generation of LSPs". > I was wondering what if 2 ingress (head end RSVP) LSR routers are > provisioning LSPs (each wanting 100 Mbytes) through the same core > convergent LSR interface and each one of the routers at the time they > privision their LSP think there is 100 Mbyte of bandwidth free to > complete the job. In reality there is a total of 100 MBYTE for the > whole interface, the first RSVP reservation succeeds while the second > fails. > The second LSP Ingress router would ask TE Source routing for another > next bandwidth constraint best path to setup the LSP. How efficient > is that if many LSPs coverge in the core of the network this way and > there is no precise way to say what is available at the time RSVP is > trigered on? > Also, since the IS-IS and its TE source routing engine take snap shots > of the bandwidth resources in the network it has a tunnel view of what > other IS-IS(LSR) routers are doing to this information at that moment > in time, and are making inaccurate determination of what is reserved > and what is free. The IS-IS route convergent time could be much slower > than the RSVP signalling time. For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is carried towards the source. The feedback information is then input into TE database at source and a new route computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is described in: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > The following is my assumption, please clarify if I am wrong, thanks > if a series of LSP requests are hitting a given IS-IS router (TE > source routing engine) at the same processing window/cycle, it makes > assignments based on a frozen snap shot of the bandwidth in the > network. Assignments are made without consideration for their RSVP > signalling success/failure and eventually the signalling components > would fail their reservation requests causing turbulance with LSP > attempts. > Assuming most of what i said is true, do we need another more precise > mechanism to solve this? Regards, The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route was found). > Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 > FAX: 703 456 2952 IPOptical, Inc. > 11480 Sunset Hills Road > Suite #200E > Reston, VA 20190 -- Darek Skalecki Nortel (613) 765-2252 --------------5FA9CB3C8BB65B95B52F29AF Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote:
I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the values in this sub-TLV should not cause rapid generation of LSPs".
I was wondering what if  2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) through the same core convergent LSR interface and each one of the routers at the time they privision their LSP think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the whole interface, the first RSVP reservation succeeds while the second fails.
The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup the LSP.  How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way to say what is available at the time RSVP is trigered on?
Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much slower than the RSVP signalling time.
For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is carried towards the source. The feedback information is then input into TE database at source and a new route computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is described in:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt
The following is my assumption, please clarify if I am wrong, thanks
if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made without consideration for their RSVP signalling success/failure and eventually the signalling components would fail their reservation requests causing turbulance with LSP attempts.
Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards,
The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route was found).
 
Ben  Ben Abarbanel,  Software Engineering, Phone:  703 456 2982
FAX:     703 456 2952 IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190
-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------5FA9CB3C8BB65B95B52F29AF-- --------------7D3D0D0254DA76A03206253F Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-mpls-te-feed-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="draft-ietf-mpls-te-feed-01.txt" Content-Transfer-Encoding: quoted-printable MPLS Working Group Peter Ashwood-Smit= h Internet Draft Bilel Jamoussi Expiration Date: December 2000 Don Fedyk Darek Skalecki Nortel Networks July 2000 Improving Topology Data Base Accuracy with LSP Feedback draft-ietf-mpls-te-feed-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a set of constraints which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. We propose a new mechanism whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy Ashwood-Smith, et. al. [Page 1] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 of the overall routing solution by significantly reducing the database discrepancies. 1. Introduction Because the network is a distributed system, it is necessary to have a mechanism to advertise information about links to all nodes in the network [IS-IS], [OSPF]. A node can then build a topology map of the network. This information is required to be as up-to-date as possible for accurate traffic engineered paths. Information about link or node failures must be rapidly propagated through the network so that recovery can be initiated. Other information about links that may be useful for reasons of quality of service include parameters such as available bandwidth, and delay. The information in this topology database is often out of date with respect to the real network. Available bandwidth is the most critical of these attributes and it can drift substantially with respect to reality due to the low frequency of link state updates that can be sustained in a very large topology. We refer to the deviation in the topology database available bandwidth as being optimistic if the database shows more available bandwidth than there really is, or pessimistic if the topology database shows less bandwidth than there really is. This distinction is important because we shall propose an efficient algorithm to deal with optimistic databases without resorting to shorter flooding intervals. One of the major problems for a constraint based routing system is dealing with changing constraints. Obviously, since bandwidth is one of the essential constraints, dealing with the rapid changes in reserved bandwidth poses some interesting challenges. In smaller networks, one can resort to higher frequency flooding but this obviously does not scale. The basic proposal is to add to the signaling protocol the ability to piggyback actual link bandwidth availability information at every link that the signaling traverses. This is done as part of the reverse messaging on success or failure (mapping, release, withdraw or notification). What this means is that every time signaling messages flow backwards toward a source to tell it of the success, failure or termination of a request, that message contains a detailed slice of bandwidth availability information for the exact path that the message has followed. This slice of reservation information, which is very up to date, is received by the source node and attached to the source node's topology database prior to making any further source route computations. The result is that the source node's topology database will tend to stay synchronized with the slices of the network through which it is establishing paths. This is nothing more than learning from successes and failures and represents an intelligent alternative to either waiting for floods or introducing non-determinism (guessing) into the source algorithms. It is important to note that the fed-back data is never Ashwood-Smith, et. al. July 2000 [Page 2] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 re-flooded. It simply overrides flooded information for the purpose of route computation until a superceding flood or fed-back value arrives. As such, it is not actually inserted into a topology database, most likely it simply is linked to that database as an override used only by source route computations. Operating a constraint based routing system without such feedback is inefficient at best since a source node will continue to give out incorrect route over and over again until it gets an IGP update. This could be minutes away and as a result the worst case blocking time for a new route is the minimum repeatable flooding interval (often several minutes in big networks). Alternatives to feedback mechanisms involve adding some non-determinism (randomness) to the routing algorithm in the hopes that it will stumble onto a path that works. These sorts of approaches are seen in ATM dynamic routing systems, which do not have these forms of feedback. In order to get a good understanding of how the feedback works, imagine a network with precisely one path (with sufficient unreserved bandwidth) available from the source to the destination. Further, imagine that the topology database at the source is significantly out of date with respect to the real network in that the source topology database sees sufficient bandwidth available on many different routes to the destination. We call this being optimistic with respect to the network since the source thinks that more bandwidth is available than there really is. When such an optimistic source selects its first path it will likely contain links that do not in reality have sufficient unreserved bandwidth. Therefore, the path is only established up to the link that does not have sufficient bandwidth. A notification message is formatted that contains the actual unreserved bandwidth for this blocking link which flows back toward the source, collapsing the partially created path as it goes. In addition, at every link that this notification traverses, the current unreserved bandwidth information for each corresponding link is appended to the vector of unreserved bandwidth along the path. In this manner, an accurate view of the slice through the network we are traversing is constructed. Eventually this message arrives back at the source node, where the vector is taken and used to temporarily override the topology database for route computations. This node has just learned from its mistake and is now slightly less optimistic with respect to the real network conditions. Path selection can be attempted again but this time the node will not make the same mistake it made the previous time. The link in question, at which rejection occurred the first time, will not even be eligible this time around, so a source route computation is guaranteed to produce a different path (or none). The same procedure may be repeated as many times as is necessary, each time learning from its mistakes, until eventually no paths remain in the source topology to the destination, or we actually find a path that works. Ashwood-Smith, et. al. July 2000 [Page 3] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 This tendency to converge either to a solution or determine that there is no solution is an important property of a routing system (it actually behaves a lot like a depth first search). This property is not present with flooding mechanisms alone since the source node must randomly hunt, or continually make the same mistakes, or abort until the next flood arrives. In addition to feeding back bandwidth on failure, we also recommend feedback on success. This has important consequences on our ability to spread load or to spill over to new links as existing links fill. It is true that spilling over to new links does not require feedback on success since we could simply wait for a feedback on failure, but we can achieve better load spreading earlier. Finally, when a path is torn down the release/withdraw messages also contain bandwidth information that can be fed back to override the source topology database. This is very important during failure scenarios where the links we need to use to reroute the path share common sub-segments with the failed path. Without the feedback, the common sub-segments may not indicate sufficient available bandwidth until we get a flood that may mean many seconds without a connection. With feedback at least we will be up to date with respect to available bandwidth up to the point of failure in the path. Also since failure involves many paths tearing down and re- establishing this is the time that it is most critical to have an accurate view. When preemption is being employed it is also extremely important that the topology database inconsistencies be small. If not, high setup priority LSPs may unnecessarily preempt lower holding priority LSPs to obtain bandwidth that, had they had a more up to date view of unreserved bandwidth, they would have been able to find elsewhere. Since preempted LSPs may in turn preempt other LSPs in a domino like effect, the results of such database inconsistencies can have wide reaching ripple like impacts. These feedback mechanisms help reduce these occurrences significantly. There are a number of network conditions where feedback shows its value. One can think of a constraint-based network as being in one of three conditions. The first is called ramp-up, this is when the rate of arriving reservations exceeds the rate of departing reservations. The second is called steady-state, this is when the rate of arriving reservations is about the same as the rate of departing reservations. Finally, the ramp-down condition is that which has a greater rate of departing reservations than arriving reservations. These three network conditions show distinctly different types of error in the topology databases. In particular an optimistic view of available bandwidth by a source node is characteristic of the ramp- up condition of a network. A pessimistic view of available bandwidth by a source node is characteristic of the ramp-down condition of a Ashwood-Smith, et. al. July 2000 [Page 4] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 network. If one plots the average error in the topology databases with respect to the real network for the three different network conditions, one will see the error slowly go positive during ramp up, slowly go negative during ramp down, and drift slowly around 0 for the steady condition. The effect of flooding on this plot is to periodically snap the error back to 0 at flooding intervals. The effect of the feedback algorithm is to bring an optimistic error back to zero without having to wait for the flood interval. On average then, the feedback algorithm tends to halve the absolute error, keeping it mostly negative or pessimistic. This makes sense since a routing system will never give paths to links that it thinks do not have resources and as a result its pessimistic view of the world stays that way until it gets a flood. This relieves the IGP updates of the most urgent requirement of flooding when bandwidth is consumed. Availability of new bandwidth occurs when paths are released or new links become available. New links are accompanied by floods. Significant releases of bandwidth can be broadcast at relatively low frequencies in the order of several minutes with little operational impact. Extensive operational experience with this feedback protocol in proprietary Nortel Networks (pre-standard CR-LDP) products has shown it to work very well for networks up to 1000 nodes with significant flooding intervals damped to several minutes. Without this protocol, these networks would block setups for up to several minutes. With this protocol, the blocking in most cases is reduced to a small number of retry attempts which is usually sub-second depending mostly on the propagation delays in the network. These feedback algorithms have been particularly beneficial in cases of failure recovery during which the network is in a sudden condition of ramp-up. Since a large number of reservations must be remade, it is highly likely that we will exceed the limits of certain key links in the network. Without feedback, the rerouting must block until a flood arrives telling us of the situation at those key links at which time rerouting can continue. With feedback, the rerouting simply continues until a feedback indicates that a link is full. In addition since reservation-balancing algorithms are also often used, feedback allows the balancing algorithms to make better distribution decisions based on immediate feedback. We have also explored through simulation and implementation a variety of mechanisms to deal with the pessimistic error in the database. One simple proposal is to use selective forgetting. In this algorithm, a reserved bandwidth value slowly drops back to zero over a relatively short time interval. The theory being that you shift the network back to an optimistic state (by forgetting your pessimism) where the feedback algorithm will again correctly operate. These algorithms have not shown any great advantage and are actually non-optimal when the error is purely optimistic. Ashwood-Smith, et. al. July 2000 [Page 5] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 Other algorithmic permutations we have explored include such variations as: Feeding-back to all intermediate nodes, information learned from control messages upstream of that intermediate node. Feeding back in both directions so that both the source and destination node's databases stay synchronized. Allowing a request to continue to its destination despite there being insufficient bandwidth at some intermediate hop. Then, rejecting the request with a full bandwidth vector slice all the way to the destination instead of just to the point of rejection. Our simulations have not show significant benefits relative to the simpler algorithm proposed here. However, it is an interesting research topic to explore and quantify the different feedback algorithms and their impacts on blocking times so we do not want to discourage the interested reader from exploring these concepts more fully. 2. Adding feedback TLVs to CR-LDP Two new TLVs are optionally added to the CR-LDP mapping, notification, and withdraw messages. There may be an arbitrary number of these TLV in any order or position in the message. It is recommended that they be placed such that they can be read and applied to override the topology database by scanning the message forwards and walking the topology database from the point where the last link feedback TLV left off. Each TLV consists of the 8 unreserved bandwidth values for each holding priority 0 through 7 as IEEE floating point numbers (the units are unidirectional bytes per second). Following this are the IP addresses of the two ends of the interface. Two TLVs are possible, one for IPV4 and one for IPV6 addressing of the link. Note: the feedback TLVs may also optionally be included in query or query-reply messages in response to bandwidth update queries from an LER. Details of this mechanism are provided in [QUERY]. 2.1 Bandwidth directionality considerations The order of the two addresses in the feedback TLV implies the direction in which the bandwidth is available. For example if the first address is A and the second address is B the bandwidth is unreserved in the A to B direction. It is possible for an implementation to provide both the A to B direction and the B to A direction as part of the same feedback message. This is done by simply including a TLV with A,B as the addresses of the link and a different TLV with B,A as the addresses Ashwood-Smith, et. al. July 2000 [Page 6] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 of the link. Should CR-LDP evolve to be able to support bi- directional traffic flow and reservations it is expected that bi- directional feedback would also be implemented via this mechanism. Ashwood-Smith, et. al. July 2000 [Page 7] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 3. IPV4 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x830 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (near end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (far end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. IPV6 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x831 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (near end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (far end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Detailed Procedures On receipt of a withdraw, notification, query-reply, or mapping message pertaining to a request made by CR-LDP (as opposed to LDP), a feedback TLV of the appropriate format for the interface over which the message was received is inserted into the message before forwarding it back to the source of the request. The 8 bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally the interface's address and far end address are placed in the TLV. Ashwood-Smith, et. al. July 2000 [Page 8] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 On receipt of a CR-LDP request message which cannot be satisfied. A notification message is formatted normally. The 8-bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally, the interface's address and far end address are placed in the TLV. On receipt of a CR-LDP request message which has been satisfied and which results in a mapping being generated. No feedback TLV is added since the previous node will insert the proper TLV when it receives the reverse flowing mapping. When an LDP session goes down either because of a link failure, TCP/IP timeout, keepalive timeout, adjacency timeout etc. Other LDP sessions in the module must generate either notification, withdraw or release messages for LSPs that traversed the LDP in question. In the case that the LSP was created by CR-LDP and that a withdraw or notification is about to be generated, LDP will insert a feedback TLV for the interface which just went down that contains 0's for all the bandwidth values and attach to it the proper interface addresses. When the LDP session that originated a CR-LDP label request receives a mapping that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that was just established. When the LDP session that originated a CR-LDP label request receives a notification that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that just failed to establish. The source node may then re-compute a path knowing that the computation will take into account the failure if it was caused by the topology database being in error with respect to the real network state. 6. IGP considerations Implementations MUST NOT permit bandwidth information learned by this feedback mechanism to be re-flooded via IS-IS, OSPF or any other IGP. The bandwidth information learned via these feedback mechanisms is to be used ONLY for source route computations on the nodes that are directly on the path that fed back the bandwidth. Normally only the source node of the LSP, or perhaps intermediate gateway nodes will use this information. It is however permitted for intermediate nodes that are forwarding this feedback information to store it for their own local source route computations. Ashwood-Smith, et. al. July 2000 [Page 9] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 There is a possibility of a race condition between the bandwidth information that is received via feedback and that which is received via a normal IGP flood. While there may be a discrepancy between the two, both are within a few 100 milliseconds of being correct. Solutions to allow us to determine which information is most up to date (say by adding a sequence number) do not add any significant benefit. Constraint based, source routed systems will always have errors in the local topology database with respect to the real network. We can reduce these errors through reduced flooding intervals, path following feedback and selective flooding but we cannot realistically reduce the errors below the second or so range. As a result propagation delay order race conditions are noise with respect to the average expected errors. An implementation SHOULD therefore consider the most recently received update (IGP or feedback) as being the most up to date. 7. Future considerations Constraint based routing systems such as CR-LDP will in the future offer other forms of constraint than simply reserved bandwidth. Actual utilization levels, current congestion levels, number of discrete channels/wavelengths available etc. are all possible constraints that change rapidly and which must be taken into consideration when computing a route. It is expected that this mechanism will be used to feedback these and other new forms of link constraining data. 8. RSVP consideration Nothing precludes the use of such feedback mechanisms with a similar TLV structure in the RSVP Resv and other reverse flowing messages although repeatedly applying a fed-back should be avoided since it increases the race condition window with flooded LSPs. This could be accomplished by a simple rule that only permits fed-back information on the original RESV, not on subsequent refreshes. 9. Intellectual Property Consideration The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 10. Security Considerations This document raises no new security considerations for CR-LDP, RSVP or MPLS in general. 11. Acknowledgments Ashwood-Smith, et. al. July 2000 [Page 10] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 The authors would like to thank Keith Dysart for his guidance, and Jerzy Miernik for helping implement these concepts and bringing them to life. 12. References [CR-LDP] Constraint-Based LSP Setup using LDP, draft-ietf-mpls-cr- ldp-04.txt [LDP] LDP Specification, draft-ietf-mpls-ldp-05.txt [IS-IS] Extensions to IS-IS for traffic engineering, draft-ietf- isis-traffic-01.txt [QUERY] MPLS LDP Query Message Description, draft-paraschiv-mpls- lsp-query-00.txt. 13. Author's Addresses Peter Ashwood-Smith Bilel Jamoussi Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, ON K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-763-4534 phone: +1 978-288-4506 petera@nortelnetworks.com jamoussi@nortelnetworks.com Darek Skalecki Don Fedyk Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, On K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-765-2252 Phone: +1 978-228-3041 dareks@nortelnetworks.com dwfedyk@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Ashwood-Smith, et. al. July 2000 [Page 11] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Ashwood-Smith, et. al. July 2000 [Page 12] --------------7D3D0D0254DA76A03206253F-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 14:48:17 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20451 for ; Thu, 14 Sep 2000 14:48:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA24902; Thu, 14 Sep 2000 11:59:42 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA24874 for ; Thu, 14 Sep 2000 11:59:40 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id LAA25818 for ; Thu, 14 Sep 2000 11:45:08 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id LAA20256 for ; Thu, 14 Sep 2000 11:45:07 -0700 (PDT) Received: from cyndi (lan-isdn-cmj3.nsd.3com.com [129.213.207.235]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id LAA12175 for ; Thu, 14 Sep 2000 11:45:07 -0700 (PDT) Message-Id: <3.0.6.32.20000914115036.00b15b30@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 14 Sep 2000 11:50:36 -0700 To: isis-wg@spider.juniper.net From: Cyndi Jung In-Reply-To: <3.0.1.32.20000519153209.013056c0@mail.one.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Isis-wg] Simple question about IS-IS mixed domains Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net If you can't mix dual and non-dual routers in the same area and have routing work for the non-OSI protocols supported (IP and IPv6), then how can it work at Level 2 if all the Level 2 routers do not support all the same non-OSI protocols? It seems to have the same problem - routes will be computed through routers that do not support the protocol of the data, just because the link costs are lowest. Am I missing something? Cyndi _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 16:16:51 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23449 for ; Thu, 14 Sep 2000 16:16:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA25035; Thu, 14 Sep 2000 13:27:01 -0700 (PDT) Received: from mailhost.avici.com ([208.246.215.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA25006 for ; Thu, 14 Sep 2000 13:26:59 -0700 (PDT) Received: from Kontoff.com (mkontoff-pc.avici.com [10.1.2.117]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e8EKBB409552; Thu, 14 Sep 2000 16:11:11 -0400 (EDT) Message-ID: <39C1304C.82CCF6E3@Kontoff.com> Date: Thu, 14 Sep 2000 16:08:44 -0400 From: Matthew Kontoff X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Darek Skalecki CC: ben abarbanel , isis-wg Subject: Re: [Isis-wg] IS-IS TE Question References: <004a01c01e5b$79d2f6e0$8b01020a@ipoptical.com> <39C0FBF9.210F4C54@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Darek Skalecki wrote: > > ben abarbanel wrote: > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the > > values in this sub-TLV should not cause rapid generation of LSPs". You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth) changes. How you do this is up to you. For example, you could reflood LSPs at an interval that could be tied to the amount of bandwidth being used. The more frequently LSPs are reflooded the closer an approximation of actual unreserved bandwidth in the network you will have. > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) > > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP > > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the > > whole interface, the first RSVP reservation succeeds while the second fails. > > > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup > > the LSP. How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way > > to say what is available at the time RSVP is trigered on? > > > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it > > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are > > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much > > slower than the RSVP signalling time. > > For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at > interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, > if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is > carried towards the source. The feedback information is then input into TE database at source and a new route > computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is > described in: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs that contain up to the moment (second, millisecond, whatever) bandwidth info? > > The following is my assumption, please clarify if I am wrong, thanks > > > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing > > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made > > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail > > their reservation requests causing turbulance with LSP attempts. > > > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards, > > The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling > protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route > was found). I agree with the 'try fail and learn again' approach but I don't think you need a separate feedback mechanism other than recent IS-IS LSPs from other LSRs. Matt Kontoff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 16:39:42 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23665 for ; Thu, 14 Sep 2000 16:39:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA25102; Thu, 14 Sep 2000 13:51:31 -0700 (PDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA25075 for ; Thu, 14 Sep 2000 13:51:29 -0700 (PDT) Received: from zrchh190 by smtprch2.nortel.com; Thu, 14 Sep 2000 15:25:50 -0500 Received: from zcard00p.ca.nortel.com by zrchh190; Thu, 14 Sep 2000 15:30:38 -0500 Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id SY0DTLF3; Thu, 14 Sep 2000 16:29:13 -0400 Message-ID: <39C13512.65308D69@americasm01.nt.com> Date: Thu, 14 Sep 2000 16:29:06 -0400 From: "Darek Skalecki" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Kontoff CC: ben abarbanel , isis-wg Subject: Re: [Isis-wg] IS-IS TE Question References: <004a01c01e5b$79d2f6e0$8b01020a@ipoptical.com> <39C0FBF9.210F4C54@americasm01.nt.com> <39C1304C.82CCF6E3@Kontoff.com> Content-Type: multipart/alternative; boundary="------------B64AA65EFD07897516D25EF7" X-Orig: X-Orig: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --------------B64AA65EFD07897516D25EF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew Kontoff wrote: > Darek Skalecki wrote: > > > > ben abarbanel wrote: > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the > > > values in this sub-TLV should not cause rapid generation of LSPs". > > You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth) > changes. How you do this is up to you. For example, you could reflood LSPs at an interval > that could be tied to the amount of bandwidth being used. The more frequently LSPs > are reflooded the closer an approximation of actual unreserved bandwidth in the > network you will have. > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) > > > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP > > > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the > > > whole interface, the first RSVP reservation succeeds while the second fails. > > > > > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup > > > the LSP. How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way > > > to say what is available at the time RSVP is trigered on? > > > > > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it > > > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are > > > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much > > > slower than the RSVP signalling time. > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at > > interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, > > if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is > > carried towards the source. The feedback information is then input into TE database at source and a new route > > computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is > > described in: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs > that contain up to the moment (second, millisecond, whatever) bandwidth info? If your flooding interval is very short then there is no need for feedback but you don't want to flood too frequently or else only control traffic is running in the network and the network doesn't scale too well. We employed feedback in a system where regular floods were every 30 minutes, feedback updates were at path establishment rates, i.e. feedback information was piggy-backed on top of appropriate signaling messages. > > > > > The following is my assumption, please clarify if I am wrong, thanks > > > > > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing > > > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made > > > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail > > > their reservation requests causing turbulance with LSP attempts. > > > > > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards, > > > > The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling > > protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route > > was found). > > I agree with the 'try fail and learn again' approach but I don't think you need > a separate feedback mechanism other than recent IS-IS LSPs from other LSRs. > > Matt Kontoff -- Darek Skalecki Nortel (613) 765-2252 --------------B64AA65EFD07897516D25EF7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew Kontoff wrote:
Darek Skalecki wrote:
>
> ben abarbanel wrote:
>
> > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved
> > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the
> > values in this sub-TLV should not cause rapid generation of LSPs".

You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth)
changes. How you do this is up to you. For example, you could reflood LSPs at an interval
that could be tied to the amount of bandwidth being used. The more frequently LSPs
are reflooded the closer an approximation of actual unreserved bandwidth in the
network you will have.

 

>
> > I was wondering what if  2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes)
> > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP
> > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the
> > whole interface, the first RSVP reservation succeeds while the second fails.
>
> > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup
> > the LSP.  How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way
> > to say what is available at the time RSVP is trigered on?
>
> > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it
> > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are
> > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much
> > slower than the RSVP signalling time.
>
> For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at
> interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback,
> if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is
> carried towards the source. The feedback information is then input into TE database at source and a new route
> computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is
> described in:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt

Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs
that contain up to the moment (second, millisecond, whatever) bandwidth info?

If your flooding interval is very short then there is no need for feedback but you don't want to flood too frequently or else only control traffic is running in the network and the network doesn't scale too well. We employed feedback in a system where regular floods were every 30 minutes, feedback updates were at path establishment rates, i.e. feedback information was piggy-backed on top of appropriate signaling messages.
 

> > The following is my assumption, please clarify if I am wrong, thanks
>
> > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing
> > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made
> > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail
> > their reservation requests causing turbulance with LSP attempts.
>
> > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards,
>
> The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling
> protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route
> was found).

I agree with the 'try fail and learn again' approach but I don't think you need
a separate feedback mechanism other than recent IS-IS LSPs from other LSRs.

Matt Kontoff

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------B64AA65EFD07897516D25EF7-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 16:43:11 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23712 for ; Thu, 14 Sep 2000 16:43:10 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA25161; Thu, 14 Sep 2000 13:54:49 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA25134 for ; Thu, 14 Sep 2000 13:54:46 -0700 (PDT) Received: from [204.242.142.104] (helo=bena) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 13Zfnh-0004R8-00; Thu, 14 Sep 2000 16:40:05 -0400 Message-ID: <00bf01c01e8c$91fe7100$8b01020a@ipoptical.com> Reply-To: "ben abarbanel" From: "ben abarbanel" To: "Matthew Kontoff" , "Darek Skalecki" Cc: "isis-wg" References: <004a01c01e5b$79d2f6e0$8b01020a@ipoptical.com> <39C0FBF9.210F4C54@americasm01.nt.com> <39C1304C.82CCF6E3@Kontoff.com> Subject: Re: [Isis-wg] IS-IS TE Question Date: Thu, 14 Sep 2000 16:44:25 -0400 Organization: IPOptical MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Matthew and Darek: I kind of like the feedback mechanism defined in "draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or Darek can add it to their spec is that a timestamp be added to both the flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the reservation denial and bandwidth sample was taken from the rejecting LSR. As the message is returned to the ingress LSR its bandwidth will be overwritten into the linkstate database, since its the most up to date information. I can see a race condition where IGP converging link state information might have older data then Reservation Release/Withdrawl messages containing the same (feedback) data. Thus its possible for the ingress LSR IGP to momentarily over-write newer bandwidth with bad/older bandwidth into the ingress LSR linkstate database. Ingress LSR IGP should check the timestamp in the database with its current LSA/LSP packet and only update the bandwidth value if it has the newer timestamp in the LSA/LSP packet. regards, Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message ----- From: "Matthew Kontoff" To: "Darek Skalecki" Cc: "ben abarbanel" ; "isis-wg" Sent: Thursday, September 14, 2000 4:08 PM Subject: Re: [Isis-wg] IS-IS TE Question > > > Darek Skalecki wrote: > > > > ben abarbanel wrote: > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the > > > values in this sub-TLV should not cause rapid generation of LSPs". > > You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth) > changes. How you do this is up to you. For example, you could reflood LSPs at an interval > that could be tied to the amount of bandwidth being used. The more frequently LSPs > are reflooded the closer an approximation of actual unreserved bandwidth in the > network you will have. > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) > > > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP > > > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the > > > whole interface, the first RSVP reservation succeeds while the second fails. > > > > > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup > > > the LSP. How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way > > > to say what is available at the time RSVP is trigered on? > > > > > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it > > > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are > > > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much > > > slower than the RSVP signalling time. > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at > > interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, > > if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is > > carried towards the source. The feedback information is then input into TE database at source and a new route > > computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is > > described in: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs > that contain up to the moment (second, millisecond, whatever) bandwidth info? > > > > The following is my assumption, please clarify if I am wrong, thanks > > > > > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing > > > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made > > > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail > > > their reservation requests causing turbulance with LSP attempts. > > > > > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards, > > > > The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling > > protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route > > was found). > > I agree with the 'try fail and learn again' approach but I don't think you need > a separate feedback mechanism other than recent IS-IS LSPs from other LSRs. > > > Matt Kontoff > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 17:19:13 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24747 for ; Thu, 14 Sep 2000 17:19:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA25315; Thu, 14 Sep 2000 14:29:11 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA24806 for ; Thu, 14 Sep 2000 11:12:16 -0700 (PDT) Received: from [204.242.142.104] (helo=bena) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 13ZdGZ-0001Hn-00; Thu, 14 Sep 2000 13:57:43 -0400 Message-ID: <009501c01e75$e3430100$8b01020a@ipoptical.com> Reply-To: "ben abarbanel" From: "ben abarbanel" To: "Darek Skalecki" Cc: "isis-wg" References: <004a01c01e5b$79d2f6e0$8b01020a@ipoptical.com> <39C0FBF9.210F4C54@americasm01.nt.com> Subject: Re: [Isis-wg] IS-IS TE Question Date: Thu, 14 Sep 2000 14:02:03 -0400 Organization: IPOptical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01C01E54.5BE69C60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C01E54.5BE69C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Darek: Thanks for the kind response. I was thinking about your answer. What = happens if you have multiple LSP attempts with multiple retries does the = originating LSR take into account potential attempts that have not = initiated yet, but could collide in the core LSR interface and thus = forces other potential LSP to go to different paths (although less = optimal), or does it simply assume that all colliding LSPs have plenty = of bandwidth even before they are actually assigned or signalled through = the domain? Second question, how do you keep the feedback information carried back = in CR/LDP from being overwritten by the IGP flooding of the same = bandwidth data? Could this propose a synchronization issue or is the = assumption that the IGP data will be as good as the feedback data? Regards, Ben Ben Abarbanel, Software Engineering, =20 Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message -----=20 From: Darek Skalecki=20 To: ben abarbanel=20 Cc: isis-wg=20 Sent: Thursday, September 14, 2000 12:25 PM Subject: Re: [Isis-wg] IS-IS TE Question ben abarbanel wrote:=20 I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and = a question came to mind regardingunreserved bandwidth. In section 5.4 = SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid = changes in the values in this sub-TLV should not cause rapid generation = of LSPs". I was wondering what if 2 ingress (head end RSVP) LSR routers are = provisioning LSPs (each wanting 100 Mbytes) through the same core = convergent LSR interface and each one of the routers at the time they = privision their LSP think there is 100 Mbyte of bandwidth free to = complete the job. In reality there is a total of 100 MBYTE for the whole = interface, the first RSVP reservation succeeds while the second fails. The second LSP Ingress router would ask TE Source routing for = another next bandwidth constraint best path to setup the LSP. How = efficient is that if many LSPs coverge in the core of the network this = way and there is no precise way to say what is available at the time = RSVP is trigered on? Also, since the IS-IS and its TE source routing engine take snap = shots of the bandwidth resources in the network it has a tunnel view of = what other IS-IS(LSR) routers are doing to this information at that = moment in time, and are making inaccurate determination of what is = reserved and what is free. The IS-IS route convergent time could be much = slower than the RSVP signalling time. For CR-LDP a feedback mechanism was proposed to learn at signaling = intervals/speed whether or not there was b/w at interfaces. A snapshot = of that b/w is fed into TE database based on which source routes are = computed. With feedback, if there is insufficient b/w at an interface to = accomodate an LSP, a notification message with a feedback TLV is carried = towards the source. The feedback information is then input into TE = database at source and a new route computed. That route should now not = contain the interface where there was insufficient b/w. The feedback = mechanism is described in:=20 http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt=20 The following is my assumption, please clarify if I am wrong, thanks if a series of LSP requests are hitting a given IS-IS router (TE = source routing engine) at the same processing window/cycle, it makes = assignments based on a frozen snap shot of the bandwidth in the network. = Assignments are made without consideration for their RSVP signalling = success/failure and eventually the signalling components would fail = their reservation requests causing turbulance with LSP attempts. Assuming most of what i said is true, do we need another more = precise mechanism to solve this? Regards, The feedback provides you ability to try, fail, learn and try again. = From our experience, a proprietary signaling protocol with feedback = worked just fine, i.e. convergence was fast (one or two tries/failures = and a satisfactory route was found).=20 =20 Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982=20 FAX: 703 456 2952 IPOptical, Inc.=20 11480 Sunset Hills Road=20 Suite #200E=20 Reston, VA 20190 --=20 Darek Skalecki Nortel=20 (613) 765-2252 =20 -------------------------------------------------------------------------= ----- MPLS Working Group Peter = Ashwood-Smith Internet Draft Bilel Jamoussi Expiration Date: December 2000 Don Fedyk Darek Skalecki Nortel Networks July 2000 Improving Topology Data Base Accuracy with LSP Feedback draft-ietf-mpls-te-feed-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other = documents at any time. It is inappropriate to use Internet-Drafts as = reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a = set of constraints which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It = is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. We propose a new mechanism whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy Ashwood-Smith, et. al. [Page 1] Internet Draft LSP Feedback with CR-LDP July, 2000 of the overall routing solution by significantly reducing the database discrepancies. 1. Introduction Because the network is a distributed system, it is necessary to = have a mechanism to advertise information about links to all nodes in = the network [IS-IS], [OSPF]. A node can then build a topology map of the network. This information is required to be as up-to-date as possible for accurate traffic engineered paths. Information about link or node failures must be rapidly propagated through the = network so that recovery can be initiated. Other information about links that may be useful for reasons of quality of service include parameters such as available bandwidth, and delay. The information in this topology database is often out of date with respect to the real network. Available bandwidth is the most critical of these attributes and it can drift substantially with respect to reality due to the low frequency of link state updates that can be = sustained in a very large topology. We refer to the deviation in the topology database available bandwidth as being optimistic if the database shows more available bandwidth than there really is, or pessimistic if the topology database shows less bandwidth than there really is. This distinction is important because we shall propose an efficient algorithm to deal with optimistic databases without resorting to shorter flooding intervals. One of the major problems for a constraint based routing system is dealing with changing constraints. Obviously, since bandwidth is = one of the essential constraints, dealing with the rapid changes in reserved bandwidth poses some interesting challenges. In smaller networks, one can resort to higher frequency flooding but this obviously does not scale. The basic proposal is to add to the signaling protocol the ability to piggyback actual link bandwidth availability information at = every link that the signaling traverses. This is done as part of the reverse messaging on success or failure (mapping, release, withdraw or notification). What this means is that every time signaling messages flow backwards toward a source to tell it of the success, failure or termination of a request, that message contains a detailed slice of bandwidth availability information for the exact path that the message has followed. This slice of reservation information, which is very up to date, is received by the source node and attached to the source node's topology database prior to making any further source route computations. The result is that = the source node's topology database will tend to stay synchronized with the slices of the network through which it is establishing paths. This is nothing more than learning from successes and failures and represents an intelligent alternative to either waiting for floods or introducing non-determinism (guessing) into the source algorithms. It is important to note that the fed-back data is never Ashwood-Smith, et. al. July 2000 [Page 2] Internet Draft LSP Feedback with CR-LDP July, 2000 re-flooded. It simply overrides flooded information for the purpose of route computation until a superceding flood or fed-back value arrives. As such, it is not actually inserted into a topology database, most likely it simply is linked to that database as an override used only by source route computations. Operating a constraint based routing system without such feedback = is inefficient at best since a source node will continue to give out incorrect route over and over again until it gets an IGP update. This could be minutes away and as a result the worst case blocking time for a new route is the minimum repeatable flooding interval (often several minutes in big networks). Alternatives to feedback mechanisms involve adding some non-determinism (randomness) to the routing algorithm in the hopes that it will stumble onto a path = that works. These sorts of approaches are seen in ATM dynamic routing systems, which do not have these forms of feedback. In order to get a good understanding of how the feedback works, imagine a network with precisely one path (with sufficient unreserved bandwidth) available from the source to the destination. Further, imagine that the topology database at the source is significantly out of date with respect to the real network in that the source topology database sees sufficient bandwidth available on many different routes to the destination. We call this being optimistic with respect to the network since the source thinks that more bandwidth is available than there really is. When such an optimistic source selects its first path it will = likely contain links that do not in reality have sufficient unreserved bandwidth. Therefore, the path is only established up to the link that does not have sufficient bandwidth. A notification message is formatted that contains the actual unreserved bandwidth for this blocking link which flows back toward the source, collapsing the partially created path as it goes. In addition, at every link that this notification traverses, the current unreserved bandwidth information for each corresponding link is appended to the vector = of unreserved bandwidth along the path. In this manner, an accurate view of the slice through the network we are traversing is constructed. Eventually this message arrives back at the source node, where the vector is taken and used to temporarily override = the topology database for route computations. This node has just = learned from its mistake and is now slightly less optimistic with respect = to the real network conditions. Path selection can be attempted again but this time the node will not make the same mistake it made the previous time. The link in question, at which rejection occurred the first time, will not even be eligible this time around, so a source route computation is guaranteed to produce a different path (or none). The same = procedure may be repeated as many times as is necessary, each time learning from its mistakes, until eventually no paths remain in the source topology to the destination, or we actually find a path that works. Ashwood-Smith, et. al. July 2000 [Page 3] Internet Draft LSP Feedback with CR-LDP July, 2000 This tendency to converge either to a solution or determine that there is no solution is an important property of a routing system (it actually behaves a lot like a depth first search). This = property is not present with flooding mechanisms alone since the source node must randomly hunt, or continually make the same mistakes, or abort until the next flood arrives. In addition to feeding back bandwidth on failure, we also recommend feedback on success. This has important consequences on our ability to spread load or to spill over to new links as existing links = fill. It is true that spilling over to new links does not require = feedback on success since we could simply wait for a feedback on failure, = but we can achieve better load spreading earlier. Finally, when a path is torn down the release/withdraw messages = also contain bandwidth information that can be fed back to override the source topology database. This is very important during failure scenarios where the links we need to use to reroute the path share common sub-segments with the failed path. Without the feedback, the common sub-segments may not indicate sufficient available bandwidth until we get a flood that may mean many seconds without a connection. With feedback at least we will be up to date with respect to available bandwidth up to the point of failure in the path. Also since failure involves many paths tearing down and re- establishing this is the time that it is most critical to have an accurate view. When preemption is being employed it is also extremely important that the topology database inconsistencies be small. If not, high setup priority LSPs may unnecessarily preempt lower holding = priority LSPs to obtain bandwidth that, had they had a more up to date view of unreserved bandwidth, they would have been able to find elsewhere. Since preempted LSPs may in turn preempt other LSPs in a domino like effect, the results of such database inconsistencies = can have wide reaching ripple like impacts. These feedback mechanisms help reduce these occurrences significantly. There are a number of network conditions where feedback shows its value. One can think of a constraint-based network as being in one of three conditions. The first is called ramp-up, this is when the rate of arriving reservations exceeds the rate of departing reservations. The second is called steady-state, this is when the rate of arriving reservations is about the same as the rate of departing reservations. Finally, the ramp-down condition is that which has a greater rate of departing reservations than arriving reservations. These three network conditions show distinctly different types of error in the topology databases. In particular an optimistic view = of available bandwidth by a source node is characteristic of the ramp- up condition of a network. A pessimistic view of available = bandwidth by a source node is characteristic of the ramp-down condition of a Ashwood-Smith, et. al. July 2000 [Page 4] Internet Draft LSP Feedback with CR-LDP July, 2000 network. If one plots the average error in the topology databases with respect to the real network for the three different network conditions, one will see the error slowly go positive during ramp up, slowly go negative during ramp down, and drift slowly around 0 for the steady condition. The effect of flooding on this plot is to periodically snap the error back to 0 at flooding intervals. The effect of the feedback algorithm is to bring an optimistic error back to zero without having to wait for the flood interval. On average then, the feedback algorithm tends to halve the absolute error, keeping it mostly negative or pessimistic. This makes sense since a routing system will never give paths to links that it = thinks do not have resources and as a result its pessimistic view of the world stays that way until it gets a flood. This relieves the IGP updates of the most urgent requirement of flooding when bandwidth = is consumed. Availability of new bandwidth occurs when paths are released or new links become available. New links are accompanied by floods. Significant releases of bandwidth can be broadcast at relatively low frequencies in the order of several minutes with little operational impact. Extensive operational experience with this feedback protocol in proprietary Nortel Networks (pre-standard CR-LDP) products has = shown it to work very well for networks up to 1000 nodes with significant flooding intervals damped to several minutes. Without this = protocol, these networks would block setups for up to several minutes. With this protocol, the blocking in most cases is reduced to a small number of retry attempts which is usually sub-second depending mostly on the propagation delays in the network. These feedback algorithms have been particularly beneficial in = cases of failure recovery during which the network is in a sudden condition of ramp-up. Since a large number of reservations must be remade, it is highly likely that we will exceed the limits of certain key links in the network. Without feedback, the rerouting must block until a flood arrives telling us of the situation at those key links at which time rerouting can continue. With = feedback, the rerouting simply continues until a feedback indicates that a link is full. In addition since reservation-balancing algorithms = are also often used, feedback allows the balancing algorithms to make better distribution decisions based on immediate feedback. We have also explored through simulation and implementation a variety of mechanisms to deal with the pessimistic error in the database. One simple proposal is to use selective forgetting. In this algorithm, a reserved bandwidth value slowly drops back to = zero over a relatively short time interval. The theory being that you shift the network back to an optimistic state (by forgetting your pessimism) where the feedback algorithm will again correctly operate. These algorithms have not shown any great advantage and = are actually non-optimal when the error is purely optimistic. Ashwood-Smith, et. al. July 2000 [Page 5] Internet Draft LSP Feedback with CR-LDP July, 2000 Other algorithmic permutations we have explored include such variations as: Feeding-back to all intermediate nodes, information learned from control messages upstream of that intermediate node. Feeding back in both directions so that both the source and destination node's databases stay synchronized. Allowing a request to continue to its destination despite there being insufficient bandwidth at some intermediate hop. Then, rejecting the request with a full bandwidth vector slice all the = way to the destination instead of just to the point of rejection. Our simulations have not show significant benefits relative to the simpler algorithm proposed here. However, it is an interesting research topic to explore and quantify the different feedback algorithms and their impacts on blocking times so we do not want to discourage the interested reader from exploring these concepts more fully. 2. Adding feedback TLVs to CR-LDP Two new TLVs are optionally added to the CR-LDP mapping, notification, and withdraw messages. There may be an arbitrary number of these TLV in any order or position in the message. It is recommended that they be placed such that they can be read and applied to override the topology database by scanning the message forwards and walking the topology database from the point where the last link feedback TLV left off. Each TLV consists of the 8 unreserved bandwidth values for each holding priority 0 through 7 as IEEE floating point numbers (the units are unidirectional bytes per second). Following this are the IP addresses of the two ends of the interface. Two TLVs are possible, one for IPV4 and one for IPV6 addressing of the link. Note: the feedback TLVs may also optionally be included in query or query-reply messages in response to bandwidth update queries from = an LER. Details of this mechanism are provided in [QUERY]. 2.1 Bandwidth directionality considerations The order of the two addresses in the feedback TLV implies the direction in which the bandwidth is available. For example if the first address is A and the second address is B the bandwidth is unreserved in the A to B direction. It is possible for an implementation to provide both the A to B direction and the B to A direction as part of the same feedback message. This is done by simply including a TLV with A,B as the addresses of the link and a different TLV with B,A as the addresses Ashwood-Smith, et. al. July 2000 [Page 6] Internet Draft LSP Feedback with CR-LDP July, 2000 of the link. Should CR-LDP evolve to be able to support bi- directional traffic flow and reservations it is expected that bi- directional feedback would also be implemented via this mechanism. Ashwood-Smith, et. al. July 2000 [Page 7] Internet Draft LSP Feedback with CR-LDP July, 2000 3. IPV4 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x830 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (near end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (far end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. IPV6 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x831 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (near end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (far end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Detailed Procedures On receipt of a withdraw, notification, query-reply, or mapping message pertaining to a request made by CR-LDP (as opposed to LDP), a feedback TLV of the appropriate format for the interface over which the message was received is inserted into the message before forwarding it back to the source of the request. The 8 bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally the interface's address and far end address are placed in the TLV. Ashwood-Smith, et. al. July 2000 [Page 8] Internet Draft LSP Feedback with CR-LDP July, 2000 On receipt of a CR-LDP request message which cannot be satisfied. A notification message is formatted normally. The 8-bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally, the interface's address and far end address are placed in the TLV. On receipt of a CR-LDP request message which has been satisfied and which results in a mapping being generated. No feedback TLV is = added since the previous node will insert the proper TLV when it receives the reverse flowing mapping. When an LDP session goes down either because of a link failure, TCP/IP timeout, keepalive timeout, adjacency timeout etc. Other LDP sessions in the module must generate either notification, withdraw or release messages for LSPs that traversed the LDP in question. In the case that the LSP was created by CR-LDP and that a withdraw or notification is about to be generated, LDP will insert a feedback TLV for the interface which just went down that contains 0's for = all the bandwidth values and attach to it the proper interface addresses. When the LDP session that originated a CR-LDP label request = receives a mapping that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that was just established. When the LDP session that originated a CR-LDP label request = receives a notification that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that just failed to establish. The source node may then re-compute a path knowing that the computation will take into account the failure if it was caused by the topology database being in error with respect to the real network state. 6. IGP considerations Implementations MUST NOT permit bandwidth information learned by this feedback mechanism to be re-flooded via IS-IS, OSPF or any other IGP. The bandwidth information learned via these feedback mechanisms is to be used ONLY for source route computations on the nodes that are directly on the path that fed back the bandwidth. Normally only the source node of the LSP, or perhaps intermediate gateway nodes will use this information. It is however permitted = for intermediate nodes that are forwarding this feedback information to store it for their own local source route computations. Ashwood-Smith, et. al. July 2000 [Page 9] Internet Draft LSP Feedback with CR-LDP July, 2000 There is a possibility of a race condition between the bandwidth information that is received via feedback and that which is = received via a normal IGP flood. While there may be a discrepancy between = the two, both are within a few 100 milliseconds of being correct. Solutions to allow us to determine which information is most up to date (say by adding a sequence number) do not add any significant benefit. Constraint based, source routed systems will always have errors in the local topology database with respect to the real network. We can reduce these errors through reduced flooding intervals, path following feedback and selective flooding but we cannot realistically reduce the errors below the second or so = range. As a result propagation delay order race conditions are noise with respect to the average expected errors. An implementation SHOULD therefore consider the most recently received update (IGP or feedback) as being the most up to date. 7. Future considerations Constraint based routing systems such as CR-LDP will in the future offer other forms of constraint than simply reserved bandwidth. Actual utilization levels, current congestion levels, number of discrete channels/wavelengths available etc. are all possible constraints that change rapidly and which must be taken into consideration when computing a route. It is expected that this mechanism will be used to feedback these and other new forms of = link constraining data. 8. RSVP consideration Nothing precludes the use of such feedback mechanisms with a = similar TLV structure in the RSVP Resv and other reverse flowing messages although repeatedly applying a fed-back should be avoided since it increases the race condition window with flooded LSPs. This could = be accomplished by a simple rule that only permits fed-back = information on the original RESV, not on subsequent refreshes. 9. Intellectual Property Consideration The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 10. Security Considerations This document raises no new security considerations for CR-LDP, = RSVP or MPLS in general. 11. Acknowledgments Ashwood-Smith, et. al. July 2000 [Page 10] Internet Draft LSP Feedback with CR-LDP July, 2000 The authors would like to thank Keith Dysart for his guidance, and Jerzy Miernik for helping implement these concepts and bringing = them to life. 12. References [CR-LDP] Constraint-Based LSP Setup using LDP, draft-ietf-mpls-cr- ldp-04.txt [LDP] LDP Specification, draft-ietf-mpls-ldp-05.txt [IS-IS] Extensions to IS-IS for traffic engineering, draft-ietf- isis-traffic-01.txt [QUERY] MPLS LDP Query Message Description, draft-paraschiv-mpls- lsp-query-00.txt. 13. Author's Addresses Peter Ashwood-Smith Bilel Jamoussi Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, ON K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-763-4534 phone: +1 978-288-4506 petera@nortelnetworks.com jamoussi@nortelnetworks.com Darek Skalecki Don Fedyk Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, On K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-765-2252 Phone: +1 978-228-3041 dareks@nortelnetworks.com dwfedyk@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. = This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain = it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Ashwood-Smith, et. al. July 2000 [Page 11] Internet Draft LSP Feedback with CR-LDP July, 2000 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Ashwood-Smith, et. al. July 2000 [Page 12] ------=_NextPart_000_0092_01C01E54.5BE69C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Darek:
  Thanks for the kind response. I = was thinking=20 about your answer. What happens if you have multiple LSP attempts with = multiple=20 retries does the originating LSR take into account potential attempts = that have=20 not initiated yet, but could collide in the core LSR interface and thus = forces=20 other potential LSP to go to different paths (although less = optimal),=20 or does it simply assume that all colliding LSPs have plenty of = bandwidth even=20 before they are actually assigned or signalled through the=20 domain?
 
Second question, how do you keep the = feedback=20 information carried back in CR/LDP from being overwritten by the IGP = flooding of=20 the same bandwidth data?   Could this propose a = synchronization issue=20 or is the assumption that the IGP data will be as good as the feedback=20 data?
 
Regards,
Ben
 
 
Ben Abarbanel,  Software Engineering, 
 
Phone:  703 456 2982
FAX:      703 = 456=20 2952
 
IPOptical, Inc.
11480 Sunset Hills Road
Suite = #200E
Reston, VA=20 20190
----- Original Message -----
From:=20 Darek Skalecki
To: ben abarbanel
Cc: isis-wg
Sent: Thursday, September 14, = 2000 12:25=20 PM
Subject: Re: [Isis-wg] IS-IS TE = Question

ben abarbanel wrote:=20
I was reading the latest draft=20 "draft-ietf-isis-traffic-02.txt" and a question came to mind=20 regardingunreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved = bandwidth states "for stability reasons, rapid changes in the values = in this=20 sub-TLV should not cause rapid generation of = LSPs".
I was = wondering what=20 if  2 ingress (head end RSVP) LSR routers are provisioning LSPs = (each=20 wanting 100 Mbytes) through the same core convergent LSR interface = and each=20 one of the routers at the time they privision their LSP think there = is 100=20 Mbyte of bandwidth free to complete the job. In reality there is a = total of=20 100 MBYTE for the whole interface, the first RSVP reservation = succeeds while=20 the second fails.
The = second LSP=20 Ingress router would ask TE Source routing for another next = bandwidth=20 constraint best path to setup the LSP.  How efficient is that = if many=20 LSPs coverge in the core of the network this way and there is no = precise way=20 to say what is available at the time RSVP is trigered=20 on?
Also, = since the IS-IS=20 and its TE source routing engine take snap shots of the bandwidth = resources=20 in the network it has a tunnel view of what other IS-IS(LSR) routers = are=20 doing to this information at that moment in time, and are making = inaccurate=20 determination of what is reserved and what is free. The IS-IS route=20 convergent time could be much slower than the RSVP signalling=20 time.
For CR-LDP a feedback mechanism was = proposed=20 to learn at signaling intervals/speed whether or not there was b/w at=20 interfaces. A snapshot of that b/w is fed into TE database = based on=20 which source routes are computed. With feedback, if there is = insufficient b/w=20 at an interface to accomodate an LSP, a notification message with a = feedback=20 TLV is carried towards the source. The feedback information is = then input=20 into TE database at source and a new route computed. That route = should=20 now not contain the interface where there was insufficient b/w. The = feedback=20 mechanism is described in:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt= =20
The = following is my=20 assumption, please clarify if I am wrong, = thanks
if a = series of LSP=20 requests are hitting a given IS-IS router (TE source routing engine) = at the=20 same processing window/cycle, it makes assignments based on a frozen = snap=20 shot of the bandwidth in the network. Assignments are made without=20 consideration for their RSVP signalling success/failure and = eventually the=20 signalling components would fail their reservation requests causing=20 turbulance with LSP attempts.
Assuming = most of what=20 i said is true, do we need another more precise mechanism to solve=20 this? Regards,
The feedback provides you = ability=20 to try, fail, learn and try again. From our experience, a proprietary=20 signaling protocol with feedback worked just fine, i.e. convergence = was fast=20 (one or two tries/failures and a satisfactory route was found). =
 =20
Ben  Ben=20 Abarbanel,  Software Engineering, Phone:  703 456 2982
FAX:     703 456 2952 = IPOptical, Inc.
11480 Sunset Hills Road =
Suite #200E
Reston, VA = 20190
-- 
Darek Skalecki
Nortel 
(613) 765-2252
 =20



   MPLS Working=20 = Group           &n= bsp;           &nb= sp;         =20 Peter Ashwood-Smith
   Internet=20 = Draft           &n= bsp;           &nb= sp;           &nbs= p; =20 Bilel Jamoussi
   Expiration Date: December=20 = 2000           &nb= sp;         =20 Don=20 = Fedyk
          &nbs= p;            = ;            =             &= nbsp;      =20 Darek=20 = Skalecki
          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       =20 Nortel=20 = Networks

         &nb= sp;           &nbs= p;            = ;            =         =20 July 2000

         = Improving=20 Topology Data Base Accuracy with LSP=20 = Feedback

         &nb= sp;          =20 draft-ietf-mpls-te-feed-01.txt



Status of this=20 Memo

   This document is an Internet-Draft and is in = full=20 conformance with
   all provisions of Section 10 of=20 RFC2026.

   Internet-Drafts are working documents of = the=20 Internet Engineering
   Task Force (IETF), its areas, and = its=20 working groups. Note that
   other groups may also = distribute=20 working documents as Internet-
   = Drafts.

  =20 Internet-Drafts are draft documents valid for a maximum of = six
  =20 months and may be updated, replaced, or obsoleted by other=20 documents
   at any time. It is inappropriate to use=20 Internet-Drafts as reference
   material or to cite them = other=20 than as "work in progress."

   The list of current=20 Internet-Drafts can be accessed at
  =20 http://www.ietf.org/ietf/1id-abstracts.txt

   The = list of=20 Internet-Draft Shadow Directories can be accessed at
  =20 http://www.ietf.org/shadow.html.

Abstract

   = One key=20 component of traffic engineering is a concept known as
   = constraint based routing. In constraint based routing a=20 topology
   database is maintained on all participating = nodes.=20 This database
   contains a complete list of all the = links in the=20 network that
   participate in traffic engineering and = for each=20 of these links a set
   of constraints which those links = can=20 meet. Bandwidth, for example,
   is one essential = constraint.=20 Since the bandwidth available changes
   as new LSPs are=20 established and terminated the topology database
   will = develop=20 inconsistencies with respect to the real network. It = is
   not=20 possible to increase the flooding rates arbitrarily to keep=20 the
   database discrepancies from growing. We propose a = new=20 mechanism
   whereby a source node can learn about the = successes=20 or failures of
   its path selections by receiving = feedback from=20 the paths it is
   attempting. This fed-back information = can be=20 incorporated into
   subsequent route computations, which = greatly=20 improves the accuracy


Ashwood-Smith, et.=20 = al.           &nbs= p;            = ;            =    =20 [Page 1]
Internet Draft      LSP Feedback = with=20 CR-LDP    July, 2000


   of the = overall=20 routing solution by significantly reducing the
   = database=20 discrepancies.

1. Introduction

   Because the = network=20 is a distributed system, it is necessary to have
   a = mechanism=20 to advertise information about links to all nodes in = the
  =20 network [IS-IS], [OSPF].  A node can then build a topology map=20 of
   the network.  This information is required to = be as=20 up-to-date as
   possible for accurate traffic engineered = paths.  Information about
   link or node failures = must be=20 rapidly propagated through the network
   so that = recovery can be=20 initiated. Other information about links
   that may be = useful=20 for reasons of quality of service include
   parameters = such as=20 available bandwidth, and delay. The information
   in = this=20 topology database is often out of date with respect to = the
  =20 real network. Available bandwidth is the most critical of=20 these
   attributes and it can drift substantially with = respect=20 to reality
   due to the low frequency of link state = updates that=20 can be sustained
   in a very large topology. We refer to = the=20 deviation in the topology
   database available bandwidth = as=20 being optimistic if the database
   shows more available=20 bandwidth than there really is, or pessimistic
   if the = topology=20 database shows less bandwidth than there really is.
   = This=20 distinction is important because we shall propose an = efficient
  =20 algorithm to deal with optimistic databases without resorting=20 to
   shorter flooding intervals.

   One = of the=20 major problems for a constraint based routing system = is
  =20 dealing with changing constraints. Obviously, since bandwidth is=20 one
   of the essential constraints, dealing with the = rapid=20 changes in
   reserved bandwidth poses some interesting=20 challenges. In smaller
   networks, one can resort to = higher=20 frequency flooding but this
   obviously does not=20 scale.

   The basic proposal is to add to the = signaling=20 protocol the ability
   to piggyback actual link = bandwidth=20 availability information at every
   link that the = signaling=20 traverses. This is done as part of the
   reverse = messaging on=20 success or failure (mapping, release, withdraw
   or=20 notification). What this means is that every time = signaling
  =20 messages flow backwards toward a source to tell it of the=20 success,
   failure or termination of a request, that = message=20 contains a
   detailed slice of bandwidth availability=20 information for the exact
   path that the message has = followed.=20 This slice of reservation
   information, which is very = up to=20 date, is received by the source
   node and attached to = the=20 source node's topology database prior to
   making any = further=20 source route computations. The result is that the
   = source=20 node's topology database will tend to stay synchronized = with
  =20 the slices of the network through which it is establishing=20 paths.
   This is nothing more than learning from = successes and=20 failures and
   represents an intelligent alternative to = either=20 waiting for floods
   or introducing non-determinism = (guessing)=20 into the source
   algorithms. It is important to note = that the=20 fed-back data is never


Ashwood-Smith, et.=20 al.       July =20 2000        [Page 2]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   re-flooded. It simply overrides = flooded=20 information for the purpose
   of route computation until = a=20 superceding flood or fed-back value
   arrives. As such, = it is=20 not actually inserted into a topology
   database, most = likely it=20 simply is linked to that database as an
   override used = only by=20 source route computations.

   Operating a constraint = based=20 routing system without such feedback is
   inefficient at = best=20 since a source node will continue to give out
   = incorrect route=20 over and over again until it gets an IGP update.
   This = could be=20 minutes away and as a result the worst case blocking
   = time for=20 a new route is the minimum repeatable flooding = interval
   (often=20 several minutes in big networks). Alternatives to = feedback
  =20 mechanisms involve adding some non-determinism (randomness) to=20 the
   routing algorithm in the hopes that it will = stumble onto a=20 path that
   works. These sorts of approaches are seen in = ATM=20 dynamic routing
   systems, which do not have these forms = of=20 feedback.

   In order to get a good understanding of = how the=20 feedback works,
   imagine a network with precisely one = path=20 (with sufficient
   unreserved bandwidth) available from = the=20 source to the destination.
   Further, imagine that the = topology=20 database at the source is
   significantly out of date = with=20 respect to the real network in that
   the source = topology=20 database sees sufficient bandwidth available on
   many = different=20 routes to the destination. We call this being
   = optimistic with=20 respect to the network since the source thinks that
   = more=20 bandwidth is available than there really is.

   When = such an=20 optimistic source selects its first path it will = likely
  =20 contain links that do not in reality have sufficient=20 unreserved
   bandwidth. Therefore, the path is only = established=20 up to the link
   that does not have sufficient = bandwidth. A=20 notification message is
   formatted that contains the = actual=20 unreserved bandwidth for this
   blocking link which = flows back=20 toward the source, collapsing the
   partially created = path as it=20 goes. In addition, at every link that
   this = notification=20 traverses, the current unreserved bandwidth
   = information for=20 each corresponding link is appended to the vector of
  =20 unreserved bandwidth along the path. In this manner, an=20 accurate
   view of the slice through the network we are=20 traversing is
   constructed. Eventually this message = arrives=20 back at the source
   node, where the vector is taken and = used to=20 temporarily override the
   topology database for route=20 computations. This node has just learned
   from its = mistake and=20 is now slightly less optimistic with respect to
   the = real=20 network conditions.

   Path selection can be = attempted again=20 but this time the node will
   not make the same mistake = it made=20 the previous time. The link in
   question, at which = rejection=20 occurred the first time, will not even
   be eligible = this time=20 around, so a source route computation is
   guaranteed to = produce=20 a different path (or none). The same procedure
   may be = repeated=20 as many times as is necessary, each time learning
   from = its=20 mistakes, until eventually no paths remain in the = source
  =20 topology to the destination, or we actually find a path that=20 works.

Ashwood-Smith, et. = al.      =20 July  2000        [Page = 3]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   This tendency to converge either to = a=20 solution or determine that
   there is no solution is an=20 important property of a routing system
   (it actually = behaves a=20 lot like a depth first search). This property
   is not = present=20 with flooding mechanisms alone since the source node
   = must=20 randomly hunt, or continually make the same mistakes, or = abort
  =20 until the next flood arrives.

   In addition to = feeding back=20 bandwidth on failure, we also recommend
   feedback on = success.=20 This has important consequences on our ability
   to = spread load=20 or to spill over to new links as existing links fill.
   = It is=20 true that spilling over to new links does not require = feedback
  =20 on success since we could simply wait for a feedback on failure,=20 but
   we can achieve better load spreading=20 earlier.

   Finally, when a path is torn down the=20 release/withdraw messages also
   contain bandwidth = information=20 that can be fed back to override the
   source topology = database.=20 This is very important during failure
   scenarios where = the=20 links we need to use to reroute the path share
   common=20 sub-segments with the failed path. Without the feedback, = the
  =20 common sub-segments may not indicate sufficient available=20 bandwidth
   until we get a flood that may mean many = seconds=20 without a
   connection. With feedback at least we will = be up to=20 date with
   respect to available bandwidth up to the = point of=20 failure in the
   path. Also since failure involves many = paths=20 tearing down and re-
   establishing this is the time = that it is=20 most critical to have an
   accurate = view.

  =20 When preemption is being employed it is also extremely=20 important
   that the topology database inconsistencies = be small.=20 If not, high
   setup priority LSPs may unnecessarily = preempt=20 lower holding priority
   LSPs to obtain bandwidth that, = had they=20 had a more up to date view
   of unreserved bandwidth, = they would=20 have been able to find
   elsewhere. Since preempted LSPs = may in=20 turn preempt other LSPs in a
   domino like effect, the = results=20 of such database inconsistencies can
   have wide = reaching ripple=20 like impacts. These feedback mechanisms
   help reduce = these=20 occurrences significantly.

   There are a number of = network=20 conditions where feedback shows its
   value. One can = think of a=20 constraint-based network as being in one
   of three = conditions.=20 The first is called ramp-up, this is when the
   rate of = arriving=20 reservations exceeds the rate of departing
   = reservations. The=20 second is called steady-state, this is when the
   rate = of=20 arriving reservations is about the same as the rate of
   = departing reservations. Finally, the ramp-down condition is=20 that
   which has a greater rate of departing = reservations than=20 arriving
   reservations.

   These three = network=20 conditions show distinctly different types of
   error in = the=20 topology databases. In particular an optimistic view = of
  =20 available bandwidth by a source node is characteristic of the=20 ramp-
   up condition of a network. A pessimistic view of = available bandwidth
   by a source node is characteristic = of the=20 ramp-down condition of a

Ashwood-Smith, et.=20 al.       July =20 2000        [Page 4]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   network. If one plots the average = error in=20 the topology databases
   with respect to the real = network for=20 the three different network
   conditions, one will see = the error=20 slowly go positive during ramp
   up, slowly go negative = during=20 ramp down, and drift slowly around 0
   for the steady = condition.=20 The effect of flooding on this plot is to
   periodically = snap=20 the error back to 0 at flooding intervals. The
   effect = of the=20 feedback algorithm is to bring an optimistic error
   = back to=20 zero without having to wait for the flood interval. On
   = average=20 then, the feedback algorithm tends to halve the = absolute
  =20 error, keeping it mostly negative or pessimistic. This makes=20 sense
   since a routing system will never give paths to = links=20 that it thinks
   do not have resources and as a result = its=20 pessimistic view of the
   world stays that way until it = gets a=20 flood.  This relieves the IGP
   updates of the most = urgent=20 requirement of flooding when bandwidth is
   consumed.=20 Availability of new bandwidth occurs when paths are
   = released=20 or new links become available.  New links are = accompanied
  =20 by floods. Significant releases of bandwidth can be broadcast=20 at
   relatively low frequencies in the order of several = minutes=20 with
   little operational impact.

   = Extensive=20 operational experience with this feedback protocol in
  =20 proprietary Nortel Networks (pre-standard CR-LDP) products has=20 shown
   it to work very well for networks up to 1000 = nodes with=20 significant
   flooding intervals damped to several = minutes.=20 Without this protocol,
   these networks would block = setups for=20 up to several minutes. With
   this protocol, the = blocking in=20 most cases is reduced to a small
   number of retry = attempts=20 which is usually sub-second depending
   mostly on the=20 propagation delays in the network.

   These feedback=20 algorithms have been particularly beneficial in cases
   = of=20 failure recovery during which the network is in a = sudden
  =20 condition of ramp-up. Since a large number of reservations must=20 be
   remade, it is highly likely that we will exceed the = limits=20 of
   certain key links in the network. Without feedback, = the=20 rerouting
   must block until a flood arrives telling us = of the=20 situation at
   those key links at which time rerouting = can=20 continue. With feedback,
   the rerouting simply = continues until=20 a feedback indicates that a
   link is full. In addition = since=20 reservation-balancing algorithms are
   also often used, = feedback=20 allows the balancing algorithms to make
   better = distribution=20 decisions based on immediate feedback.

   We have = also=20 explored through simulation and implementation a
   = variety of=20 mechanisms to deal with the pessimistic error in the
   = database.=20 One simple proposal is to use selective forgetting. In
   = this=20 algorithm, a reserved bandwidth value slowly drops back to=20 zero
   over a relatively short time interval. The theory = being=20 that you
   shift the network back to an optimistic state = (by=20 forgetting your
   pessimism) where the feedback = algorithm will=20 again correctly
   operate. These algorithms have not = shown any=20 great advantage and are
   actually non-optimal when the = error is=20 purely optimistic.



Ashwood-Smith, et.=20 al.       July =20 2000        [Page 5]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   Other algorithmic permutations we = have=20 explored include such
   variations = as:

  =20 Feeding-back to all intermediate nodes, information learned=20 from
   control messages upstream of that intermediate=20 node.

   Feeding back in both directions so that both = the=20 source and
   destination node's databases stay=20 synchronized.

   Allowing a request to continue to = its=20 destination despite there
   being insufficient bandwidth = at some=20 intermediate hop. Then,
   rejecting the request with a = full=20 bandwidth vector slice all the way
   to the destination = instead=20 of just to the point of rejection.

   Our simulations = have=20 not show significant benefits relative to the
   simpler=20 algorithm proposed here. However, it is an interesting
   = research topic to explore and quantify the different = feedback
  =20 algorithms and their impacts on blocking times so we do not want=20 to
   discourage the interested reader from exploring = these=20 concepts more
   fully.

2. Adding feedback TLVs to = CR-LDP

   Two new TLVs are optionally added to the = CR-LDP=20 mapping,
   notification, and withdraw messages. There = may be an=20 arbitrary
   number of these TLV in any order or position = in the=20 message. It is
   recommended that they be placed such = that they=20 can be read and
   applied to override the topology = database by=20 scanning the message
   forwards and walking the topology = database from the point where the
   last link feedback = TLV left=20 off.

   Each TLV consists of the 8 unreserved = bandwidth=20 values for each
   holding priority 0 through 7 as IEEE = floating=20 point numbers (the
   units are unidirectional bytes per = second).=20 Following this are the
   IP addresses of the two ends of = the=20 interface. Two TLVs are
   possible, one for IPV4 and one = for=20 IPV6 addressing of the link.

   Note: the feedback = TLVs may=20 also optionally be included in query or
   query-reply = messages=20 in response to bandwidth update queries from an
   LER. = Details=20 of this mechanism are provided in [QUERY].

2.1 Bandwidth = directionality=20 considerations

   The order of the two addresses in = the=20 feedback TLV implies the
   direction in which the = bandwidth is=20 available. For example if the
   first address is A and = the=20 second address is B the bandwidth is
   unreserved in the = A to B=20 direction.

   It is possible for an implementation to = provide=20 both the A to B
   direction and the B to A direction as = part of=20 the same feedback
   message. This is done by simply = including a=20 TLV with A,B as the
   addresses of the link and a = different TLV=20 with B,A as the addresses

Ashwood-Smith, et.=20 al.       July =20 2000        [Page 6]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   of the link. Should CR-LDP evolve = to be=20 able to support bi-
   directional traffic flow and = reservations=20 it is expected that bi-
   directional feedback would = also be=20 implemented via this=20 = mechanism.
































=
















Ashwo= od-Smith,=20 et. al.       July =20 2000        [Page 7]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000



3. IPV4 specified link feedback=20 TLV

  =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9=20 0 1
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |U|F|         =20 = 0x830           =20 |     =20 = Length           &= nbsp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    =20 . . . . . . . .
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV4 address of interface (near=20 end)         |
   = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV4 address of interface (far=20 end)          = |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= 4.=20 IPV6 specified link feedback TLV

  =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9=20 0 1
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |U|F|         =20 = 0x831           =20 |     =20 = Length           &= nbsp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    =20 . . . . . . . .
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV6 address of interface (near=20 end)         |
   = = |            =             &= nbsp; =20 = _____           &n= bsp;           &nb= sp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV6 address of interface (far=20 end)          = |
  =20 = |            =             &= nbsp; =20 = _____           &n= bsp;           &nb= sp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= 5.=20 Detailed Procedures

   On receipt of a withdraw,=20 notification, query-reply, or mapping
   message = pertaining to a=20 request made by CR-LDP (as opposed to LDP),
   a feedback = TLV of=20 the appropriate format for the interface over
   which = the=20 message was received is inserted into the message = before
  =20 forwarding it back to the source of the request. The 8=20 bandwidth
   values are filled in with the outgoing = bandwidth=20 available on this
   interface for each of the 8 holding=20 priorities in bytes per second.
   Finally the = interface's=20 address and far end address are placed in
   the=20 TLV.



Ashwood-Smith, et. = al.      =20 July  2000        [Page = 8]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   On receipt of a CR-LDP request = message=20 which cannot be satisfied. A
   notification message is = formatted=20 normally. The 8-bandwidth values
   are filled in with = the=20 outgoing bandwidth available on this
   interface for = each of the=20 8 holding priorities in bytes per second.
   Finally, the = interface's address and far end address are placed in
   = the=20 TLV.

   On receipt of a CR-LDP request message which = has been=20 satisfied and
   which results in a mapping being = generated. No=20 feedback TLV is added
   since the previous node will = insert the=20 proper TLV when it receives
   the reverse flowing=20 mapping.

   When an LDP session goes down either = because of a=20 link failure,
   TCP/IP timeout, keepalive timeout, = adjacency=20 timeout etc. Other LDP
   sessions in the module must = generate=20 either notification, withdraw
   or release messages for = LSPs=20 that traversed the LDP in question. In
   the case that = the LSP=20 was created by CR-LDP and that a withdraw or
   = notification is=20 about to be generated, LDP will insert a feedback
   TLV = for the=20 interface which just went down that contains 0's for = all
   the=20 bandwidth values and attach to it the proper interface
   = addresses.

   When the LDP session that originated a = CR-LDP=20 label request receives
   a mapping that contains = feedback TLV's=20 it is recommended that these
   bandwidth values = supersede the=20 corresponding values in the node's
   topology database = for=20 source route computations. Doing so permits
   this node = to=20 immediately synchronize its topology with respect to
   = the real=20 bandwidth reservations along the path that was just
  =20 established.

   When the LDP session that originated = a CR-LDP=20 label request receives
   a notification that contains = feedback=20 TLV's it is recommended that
   these bandwidth values = supersede=20 the corresponding values in the
   node's topology = database for=20 source route computations. Doing so
   permits this node = to=20 immediately synchronize its topology with
   respect to = the real=20 bandwidth reservations along the path that just
   failed = to=20 establish. The source node may then re-compute a path
   = knowing=20 that the computation will take into account the failure = if
   it=20 was caused by the topology database being in error with=20 respect
   to the real network state.

   = 6. IGP=20 considerations

   Implementations MUST NOT permit = bandwidth=20 information learned by
   this feedback mechanism to be=20 re-flooded via IS-IS, OSPF or any
   other IGP. The = bandwidth=20 information learned via these feedback
   mechanisms is = to be=20 used ONLY for source route computations on the
   nodes = that are=20 directly on the path that fed back the bandwidth.
   = Normally=20 only the source node of the LSP, or perhaps = intermediate
  =20 gateway nodes will use this information. It is however permitted=20 for
   intermediate nodes that are forwarding this = feedback=20 information to
   store it for their own local source = route=20 computations.

Ashwood-Smith, et.=20 al.       July =20 2000        [Page 9]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   There is a possibility of a race = condition=20 between the bandwidth
   information that is received via = feedback and that which is received
   via a normal IGP = flood.=20 While there may be a discrepancy between the
   two, both = are=20 within a few 100 milliseconds of being correct.
   = Solutions to=20 allow us to determine which information is most up to
   = date=20 (say by adding a sequence number) do not add any = significant
  =20 benefit. Constraint based, source routed systems will always=20 have
   errors in the local topology database with = respect to the=20 real
   network. We can reduce these errors through = reduced=20 flooding
   intervals, path following feedback and = selective=20 flooding but we
   cannot realistically reduce the errors = below=20 the second or so range.
   As a result propagation delay = order=20 race conditions are noise with
   respect to the average = expected=20 errors. An implementation SHOULD
   therefore consider = the most=20 recently received update (IGP or
   feedback) as being = the most=20 up to date.

7. Future considerations

   = Constraint=20 based routing systems such as CR-LDP will in the = future
   offer=20 other forms of constraint than simply reserved = bandwidth.
  =20 Actual utilization levels, current congestion levels, number=20 of
   discrete channels/wavelengths available etc. are = all=20 possible
   constraints that change rapidly and which = must be=20 taken into
   consideration when computing a route. It is = expected that this
   mechanism will be used to feedback = these=20 and other new forms of link
   constraining = data.

8. RSVP=20 consideration

   Nothing precludes the use of such = feedback=20 mechanisms with a similar
   TLV structure in the RSVP = Resv and=20 other reverse flowing messages
   although repeatedly = applying a=20 fed-back should be avoided since it
   increases the race = condition window with flooded LSPs. This could be
   = accomplished=20 by a simple rule that only permits fed-back = information
   on the=20 original RESV, not on subsequent refreshes.

9. Intellectual = Property=20 Consideration

   The IETF has been notified of = intellectual=20 property rights claimed
   in regard to some or all of = the=20 specification contained in this
   document.  For = more=20 information consult the online list of claimed
  =20 rights.

10. Security Considerations

   This = document=20 raises no new security considerations for CR-LDP, RSVP
   = or MPLS=20 in general.

11. = Acknowledgments




Ashwood-Smith, et.=20 al.       July =20 2000        [Page 10]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   The authors would like to thank = Keith=20 Dysart for his guidance, and
   Jerzy Miernik for helping = implement these concepts and bringing them
   to = life.

12.=20 References

   [CR-LDP] Constraint-Based LSP Setup = using LDP,=20 draft-ietf-mpls-cr-
   ldp-04.txt

   = [LDP] LDP=20 Specification, draft-ietf-mpls-ldp-05.txt

   [IS-IS]=20 Extensions to IS-IS for traffic engineering, = draft-ietf-
  =20 isis-traffic-01.txt

   [QUERY] MPLS LDP Query Message = Description, draft-paraschiv-mpls-
  =20 lsp-query-00.txt.

13. Author's Addresses

   = Peter=20 = Ashwood-Smith          =     =20 Bilel Jamoussi
   Nortel Networks=20 = Corp.           &n= bsp;=20 Nortel Networks Corp.
   P.O. Box 3511 Station=20 C,          600 = Technology Park=20 Drive
   Ottawa, ON K1Y=20 = 4H7           &nbs= p;   =20 Billerica, MA 01821
  =20 = Canada           &= nbsp;           &n= bsp;   =20 USA
   Phone: +1=20 = 613-763-4534          &= nbsp;=20 phone: +1 978-288-4506
  =20 = petera@nortelnetworks.com        = =20 jamoussi@nortelnetworks.com

   Darek=20 = Skalecki           = ;        =20 Don Fedyk
   Nortel Networks=20 = Corp.           &n= bsp;=20 Nortel Networks Corp.
   P.O. Box 3511 Station=20 C,          600 = Technology Park=20 Drive
   Ottawa, On K1Y=20 = 4H7           &nbs= p;   =20 Billerica, MA 01821
  =20 = Canada           &= nbsp;           &n= bsp;   =20 USA
   Phone: +1=20 = 613-765-2252          &= nbsp;=20 Phone: +1 978-228-3041
  =20 = dareks@nortelnetworks.com        = =20 dwfedyk@nortelnetworks.com


Full Copyright=20 Statement

   Copyright (C) The Internet Society = (date). All=20 Rights Reserved. This
   document and translations of it = may be=20 copied and furnished to
   others, and derivative works = that=20 comment on or otherwise explain it
   or assist in its=20 implementation may be prepared, copied, published
   and=20 distributed, in whole or in part, without restriction of = any
  =20 kind, provided that the above copyright notice and this=20 paragraph
   are included on all such copies and = derivative=20 works. However, this
   document itself may not be = modified in=20 any way, such as by removing
   the copyright notice or=20 references to the Internet Society or other
   Internet=20 organizations, except as needed for the purpose of
   = developing=20 Internet standards in which case the procedures for
   = copyrights=20 defined in the Internet Standards process must be
   = followed, or=20 as required to translate it into languages other than
  =20 English.

Ashwood-Smith, et. = al.      =20 July  2000        [Page=20 11]
Internet Draft      LSP Feedback with=20 CR-LDP    July, 2000



   The = limited=20 permissions granted above are perpetual and will not = be
  =20 revoked by the Internet Society or its successors or=20 = assigns.















<= BR>
































Ashwood= -Smith,=20 et. al.       July =20 2000        [Page=20 12]
------=_NextPart_000_0092_01C01E54.5BE69C60-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 18:23:37 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26902 for ; Thu, 14 Sep 2000 18:23:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA25435; Thu, 14 Sep 2000 15:35:06 -0700 (PDT) Received: from server.nayna.com (069-035.dsl.popsite.net [64.24.69.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA25400 for ; Thu, 14 Sep 2000 15:34:55 -0700 (PDT) Received: from nayna.com (069-034.dsl.popsite.net [64.24.69.34]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA17474; Thu, 14 Sep 2000 15:12:06 -0700 X-Authentication-Warning: server.nayna.com: Host 069-034.dsl.popsite.net [64.24.69.34] claimed to be nayna.com Message-ID: <39C14D48.15A16FA9@nayna.com> Date: Thu, 14 Sep 2000 15:12:24 -0700 From: Sudheer Dharnikota X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Darek Skalecki CC: Matthew Kontoff , ben abarbanel , isis-wg Subject: Re: [Isis-wg] IS-IS TE Question References: <004a01c01e5b$79d2f6e0$8b01020a@ipoptical.com> <39C0FBF9.210F4C54@americasm01.nt.com> <39C1304C.82CCF6E3@Kontoff.com> <39C13512.65308D69@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hi Guys: According to our draft.. our approach to this problem is: 1. use a primary criteria to find a path 2. if it fails due to any reasons (unavailability of the resources is being one of them) then use the crankback from the previous ABR by removing the links that are failed. Note that we donot have to consider the convergence problem in this case. 3. If there are no other paths with the same characteistic then use the secondary criteria to identify the best path. No links attached to the convergence and playing with the timers. Although i agree that changes in the ABW need to be propagated sooner. Cheers, sudheer Darek Skalecki wrote: > > Matthew Kontoff wrote: > > > Darek Skalecki wrote: > > > > > > ben abarbanel wrote: > > > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" > > and a question came to mind regardingunreserved > > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth > > states "for stability reasons, rapid changes in the > > > > values in this sub-TLV should not cause rapid generation of > > LSPs". > > > > You still need to regenerate and flood LSPs when an interface state > > (i.e. bandwidth) > > changes. How you do this is up to you. For example, you could > > reflood LSPs at an interval > > that could be tied to the amount of bandwidth being used. The more > > frequently LSPs > > are reflooded the closer an approximation of actual unreserved > > bandwidth in the > > network you will have. > > > > > > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers > > are provisioning LSPs (each wanting 100 Mbytes) > > > > through the same core convergent LSR interface and each one of > > the routers at the time they privision their LSP > > > > think there is 100 Mbyte of bandwidth free to complete the job. > > In reality there is a total of 100 MBYTE for the > > > > whole interface, the first RSVP reservation succeeds while the > > second fails. > > > > > > > The second LSP Ingress router would ask TE Source routing for > > another next bandwidth constraint best path to setup > > > > the LSP. How efficient is that if many LSPs coverge in the core > > of the network this way and there is no precise way > > > > to say what is available at the time RSVP is trigered on? > > > > > > > Also, since the IS-IS and its TE source routing engine take snap > > shots of the bandwidth resources in the network it > > > > has a tunnel view of what other IS-IS(LSR) routers are doing to > > this information at that moment in time, and are > > > > making inaccurate determination of what is reserved and what is > > free. The IS-IS route convergent time could be much > > > > slower than the RSVP signalling time. > > > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling > > intervals/speed whether or not there was b/w at > > > interfaces. A snapshot of that b/w is fed into TE database based > > on which source routes are computed. With feedback, > > > if there is insufficient b/w at an interface to accomodate an LSP, > > a notification message with a feedback TLV is > > > carried towards the source. The feedback information is then input > > into TE database at source and a new route > > > computed. That route should now not contain the interface where > > there was insufficient b/w. The feedback mechanism is > > > described in: > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > > > Why would you need a feedback mechanism if you regenerate and flood > > IS-IS LSPs with updated TE TLVs > > that contain up to the moment (second, millisecond, whatever) > > bandwidth info? > > If your flooding interval is very short then there is no need for > feedback but you don't want to flood too frequently or else only > control traffic is running in the network and the network doesn't > scale too well. We employed feedback in a system where regular floods > were every 30 minutes, feedback updates were at path establishment > rates, i.e. feedback information was piggy-backed on top of > appropriate signaling messages. > > > > > > > > > The following is my assumption, please clarify if I am wrong, > > thanks > > > > > > > if a series of LSP requests are hitting a given IS-IS router (TE > > source routing engine) at the same processing > > > > window/cycle, it makes assignments based on a frozen snap shot > > of the bandwidth in the network. Assignments are made > > > > without consideration for their RSVP signalling success/failure > > and eventually the signalling components would fail > > > > their reservation requests causing turbulance with LSP attempts. > > > > > > > > > Assuming most of what i said is true, do we need another more > > precise mechanism to solve this? Regards, > > > > > > The feedback provides you ability to try, fail, learn and try > > again. >From our experience, a proprietary signaling > > > protocol with feedback worked just fine, i.e. convergence was fast > > (one or two tries/failures and a satisfactory route > > > was found). > > > > I agree with the 'try fail and learn again' approach but I don't > > think you need > > a separate feedback mechanism other than recent IS-IS LSPs from > > other LSRs. > > > > Matt Kontoff > > -- > Darek Skalecki > Nortel > (613) 765-2252 > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Sep 14 20:17:17 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27728 for ; Thu, 14 Sep 2000 20:17:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA25579; Thu, 14 Sep 2000 17:28:54 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA25551 for ; Thu, 14 Sep 2000 17:28:51 -0700 (PDT) Received: from [204.242.142.104] (helo=bena) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 13Zj8s-0006SO-00; Thu, 14 Sep 2000 20:14:10 -0400 Message-ID: <00ff01c01eaa$7a1a6e40$8b01020a@ipoptical.com> Reply-To: "ben abarbanel" From: "ben abarbanel" To: "Sudheer Dharnikota" , "Darek Skalecki" Cc: "Matthew Kontoff" , "isis-wg" References: <004a01c01e5b$79d2f6e0$8b01020a@ipoptical.com> <39C0FBF9.210F4C54@americasm01.nt.com> <39C1304C.82CCF6E3@Kontoff.com> <39C13512.65308D69@americasm01.nt.com> <39C14D48.15A16FA9@nayna.com> Subject: Re: [Isis-wg] IS-IS TE Question Date: Thu, 14 Sep 2000 20:18:30 -0400 Organization: IPOptical MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hi Sudheer: Your draft/idea sounds like a good alternative. But if I understand darek's spec. They are trying to adapt the topology to bandwidth changes as quickly as possible so that the source routing engines can give the best possible answer. I agree most solutions still have that level of inaccuracy, cause the data gathering mechanism (link state flooding) is much slower than the execution (signalling) mechanism. Regards, Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message ----- From: "Sudheer Dharnikota" To: "Darek Skalecki" Cc: "Matthew Kontoff" ; "ben abarbanel" ; "isis-wg" Sent: Thursday, September 14, 2000 6:12 PM Subject: Re: [Isis-wg] IS-IS TE Question > Hi Guys: > > According to our draft.. our approach to this problem is: > > 1. use a primary criteria to find a path > 2. if it fails due to any reasons (unavailability of the > resources is being one of them) then use the crankback > from the previous ABR by removing the links that are > failed. Note that we donot have to consider the > convergence problem in this case. > 3. If there are no other paths with the same characteistic > then use the secondary criteria to identify the > best path. > > No links attached to the convergence and playing with the > timers. Although i agree that changes in the ABW need to > be propagated sooner. > > Cheers, > > sudheer > > Darek Skalecki wrote: > > > > Matthew Kontoff wrote: > > > > > Darek Skalecki wrote: > > > > > > > > ben abarbanel wrote: > > > > > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" > > > and a question came to mind regardingunreserved > > > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth > > > states "for stability reasons, rapid changes in the > > > > > values in this sub-TLV should not cause rapid generation of > > > LSPs". > > > > > > You still need to regenerate and flood LSPs when an interface state > > > (i.e. bandwidth) > > > changes. How you do this is up to you. For example, you could > > > reflood LSPs at an interval > > > that could be tied to the amount of bandwidth being used. The more > > > frequently LSPs > > > are reflooded the closer an approximation of actual unreserved > > > bandwidth in the > > > network you will have. > > > > > > > > > > > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers > > > are provisioning LSPs (each wanting 100 Mbytes) > > > > > through the same core convergent LSR interface and each one of > > > the routers at the time they privision their LSP > > > > > think there is 100 Mbyte of bandwidth free to complete the job. > > > In reality there is a total of 100 MBYTE for the > > > > > whole interface, the first RSVP reservation succeeds while the > > > second fails. > > > > > > > > > The second LSP Ingress router would ask TE Source routing for > > > another next bandwidth constraint best path to setup > > > > > the LSP. How efficient is that if many LSPs coverge in the core > > > of the network this way and there is no precise way > > > > > to say what is available at the time RSVP is trigered on? > > > > > > > > > Also, since the IS-IS and its TE source routing engine take snap > > > shots of the bandwidth resources in the network it > > > > > has a tunnel view of what other IS-IS(LSR) routers are doing to > > > this information at that moment in time, and are > > > > > making inaccurate determination of what is reserved and what is > > > free. The IS-IS route convergent time could be much > > > > > slower than the RSVP signalling time. > > > > > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling > > > intervals/speed whether or not there was b/w at > > > > interfaces. A snapshot of that b/w is fed into TE database based > > > on which source routes are computed. With feedback, > > > > if there is insufficient b/w at an interface to accomodate an LSP, > > > a notification message with a feedback TLV is > > > > carried towards the source. The feedback information is then input > > > into TE database at source and a new route > > > > computed. That route should now not contain the interface where > > > there was insufficient b/w. The feedback mechanism is > > > > described in: > > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > > > > > Why would you need a feedback mechanism if you regenerate and flood > > > IS-IS LSPs with updated TE TLVs > > > that contain up to the moment (second, millisecond, whatever) > > > bandwidth info? > > > > If your flooding interval is very short then there is no need for > > feedback but you don't want to flood too frequently or else only > > control traffic is running in the network and the network doesn't > > scale too well. We employed feedback in a system where regular floods > > were every 30 minutes, feedback updates were at path establishment > > rates, i.e. feedback information was piggy-backed on top of > > appropriate signaling messages. > > > > > > > > > > > > > The following is my assumption, please clarify if I am wrong, > > > thanks > > > > > > > > > if a series of LSP requests are hitting a given IS-IS router (TE > > > source routing engine) at the same processing > > > > > window/cycle, it makes assignments based on a frozen snap shot > > > of the bandwidth in the network. Assignments are made > > > > > without consideration for their RSVP signalling success/failure > > > and eventually the signalling components would fail > > > > > their reservation requests causing turbulance with LSP attempts. > > > > > > > > > > > > Assuming most of what i said is true, do we need another more > > > precise mechanism to solve this? Regards, > > > > > > > > The feedback provides you ability to try, fail, learn and try > > > again. >From our experience, a proprietary signaling > > > > protocol with feedback worked just fine, i.e. convergence was fast > > > (one or two tries/failures and a satisfactory route > > > > was found). > > > > > > I agree with the 'try fail and learn again' approach but I don't > > > think you need > > > a separate feedback mechanism other than recent IS-IS LSPs from > > > other LSRs. > > > > > > Matt Kontoff > > > > -- > > Darek Skalecki > > Nortel > > (613) 765-2252 > > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Sep 15 02:19:04 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15307 for ; Fri, 15 Sep 2000 02:19:04 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA25979; Thu, 14 Sep 2000 23:30:08 -0700 (PDT) Received: from redd248.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA25947 for ; Thu, 14 Sep 2000 23:30:06 -0700 (PDT) Received: (from tli@localhost) by redd248.procket.com (8.9.3/8.9.3) id XAA09220; Thu, 14 Sep 2000 23:15:33 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: redd248.procket.com: tli set sender to tli@redd248.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14785.48773.736706.195530@redd248.procket.com> Date: Thu, 14 Sep 2000 23:15:33 -0700 (PDT) To: Cyndi Jung Cc: isis-wg@spider.juniper.net Subject: [Isis-wg] Simple question about IS-IS mixed domains In-Reply-To: <3.0.6.32.20000914115036.00b15b30@mailhost.ewd.3com.com> References: <3.0.1.32.20000519153209.013056c0@mail.one.com> <3.0.6.32.20000914115036.00b15b30@mailhost.ewd.3com.com> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit | If you can't mix dual and non-dual routers in the same area and | have routing work for the non-OSI protocols supported (IP and IPv6), | then how can it work at Level 2 if all the Level 2 routers do not | support all the same non-OSI protocols? It seems to have the same | problem - routes will be computed through routers that do not support | the protocol of the data, just because the link costs are lowest. | | Am I missing something? If one Really Wanted to do this, then one would have to SPF independently for each protocol. Plus, because adjacency information is not carried on a per-protocol basis, you would still have the restriction that any link between two routers supporting a protocol would have to have the protocol working on that link. So for example, the link between two IPv6 routers had better be configured for IPv6. This seems like more complexity than it's worth. After all, there's only one important network layer. ;-) Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Sep 15 07:03:51 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17408 for ; Fri, 15 Sep 2000 07:03:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA26414; Fri, 15 Sep 2000 04:14:41 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA26385 for ; Fri, 15 Sep 2000 04:14:39 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id EAA18836 for ; Fri, 15 Sep 2000 04:00:06 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17296; Fri, 15 Sep 2000 07:00:05 -0400 (EDT) Message-Id: <200009151100.HAA17296@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 15 Sep 2000 07:00:05 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter, A. Banerjee, J. Drake, G. Bernstein, D. Fedyk, E. Mannie, D. Saha, V. Sharma Filename : draft-ietf-isis-gmpls-extensions-00.txt Pages : 11 Date : 14-Sep-00 This document specifies extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (previously known as Multi-Protocol Lambda Switching). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-gmpls-extensions-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000914115817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000914115817.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Sep 15 08:56:50 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19005 for ; Fri, 15 Sep 2000 08:56:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA26604; Fri, 15 Sep 2000 06:08:28 -0700 (PDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA26529 for ; Fri, 15 Sep 2000 06:08:24 -0700 (PDT) Received: from zrchh190 by smtprch2.nortel.com; Fri, 15 Sep 2000 07:45:49 -0500 Received: from zcard00p.ca.nortel.com by zrchh190; Fri, 15 Sep 2000 07:50:42 -0500 Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id SY0DTLYG; Fri, 15 Sep 2000 08:49:14 -0400 Message-ID: <39C21ACA.94F7BCF8@americasm01.nt.com> Date: Fri, 15 Sep 2000 08:49:14 -0400 From: "Darek Skalecki" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ben abarbanel CC: Matthew Kontoff , isis-wg , "Peter Ashwood-Smith" , "Don Fedyk" , "Bilel Jamoussi" Subject: Re: [Isis-wg] IS-IS TE Question References: <004a01c01e5b$79d2f6e0$8b01020a@ipoptical.com> <39C0FBF9.210F4C54@americasm01.nt.com> <39C1304C.82CCF6E3@Kontoff.com> <00bf01c01e8c$91fe7100$8b01020a@ipoptical.com> Content-Type: multipart/alternative; boundary="------------BC2DCA0DA047B7565F1C5115" X-Orig: X-Orig: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --------------BC2DCA0DA047B7565F1C5115 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote: > Matthew and Darek: > I kind of like the feedback mechanism defined in > "draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or > Darek can add it to their spec is that a timestamp be added to both the > flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also > the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the > reservation denial and bandwidth sample was taken from the rejecting LSR. As > the message is returned to the ingress LSR its bandwidth will be overwritten > into the linkstate database, since its the most up to date information. > > I can see a race condition where IGP converging link state information might > have older data then Reservation Release/Withdrawl messages containing the > same (feedback) data. Thus its possible for the ingress LSR IGP to > momentarily over-write newer bandwidth with bad/older bandwidth into the > ingress LSR linkstate database. Ingress LSR IGP should check the timestamp > in the database with its current LSA/LSP packet and only update the > bandwidth value if it has the newer timestamp in the LSA/LSP packet. > > regards, > Ben > > Ben Abarbanel, Software Engineering, > > Phone: 703 456 2982 > FAX: 703 456 2952 > > IPOptical, Inc. > 11480 Sunset Hills Road > Suite #200E > Reston, VA 20190 Timestamping is a fine idea but in our proprietary system we simply wrote any learned information into a database, whether the information was from feedback or flooding. You are right that more-up-to-date feedback information may be then overwritten by older flooding information but in that case we may simply re-learn newer information via feedback when needed so we never implemented timestamping. Darek > > > > ----- Original Message ----- > From: "Matthew Kontoff" > To: "Darek Skalecki" > Cc: "ben abarbanel" ; "isis-wg" > > Sent: Thursday, September 14, 2000 4:08 PM > Subject: Re: [Isis-wg] IS-IS TE Question > > > > > > > Darek Skalecki wrote: > > > > > > ben abarbanel wrote: > > > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a > question came to mind regardingunreserved > > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for > stability reasons, rapid changes in the > > > > values in this sub-TLV should not cause rapid generation of LSPs". > > > > You still need to regenerate and flood LSPs when an interface state (i.e. > bandwidth) > > changes. How you do this is up to you. For example, you could reflood LSPs > at an interval > > that could be tied to the amount of bandwidth being used. The more > frequently LSPs > > are reflooded the closer an approximation of actual unreserved bandwidth > in the > > network you will have. > > > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are > provisioning LSPs (each wanting 100 Mbytes) > > > > through the same core convergent LSR interface and each one of the > routers at the time they privision their LSP > > > > think there is 100 Mbyte of bandwidth free to complete the job. In > reality there is a total of 100 MBYTE for the > > > > whole interface, the first RSVP reservation succeeds while the second > fails. > > > > > > > The second LSP Ingress router would ask TE Source routing for another > next bandwidth constraint best path to setup > > > > the LSP. How efficient is that if many LSPs coverge in the core of > the network this way and there is no precise way > > > > to say what is available at the time RSVP is trigered on? > > > > > > > Also, since the IS-IS and its TE source routing engine take snap shots > of the bandwidth resources in the network it > > > > has a tunnel view of what other IS-IS(LSR) routers are doing to this > information at that moment in time, and are > > > > making inaccurate determination of what is reserved and what is free. > The IS-IS route convergent time could be much > > > > slower than the RSVP signalling time. > > > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling > intervals/speed whether or not there was b/w at > > > interfaces. A snapshot of that b/w is fed into TE database based on > which source routes are computed. With feedback, > > > if there is insufficient b/w at an interface to accomodate an LSP, a > notification message with a feedback TLV is > > > carried towards the source. The feedback information is then input into > TE database at source and a new route > > > computed. That route should now not contain the interface where there > was insufficient b/w. The feedback mechanism is > > > described in: > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > > > Why would you need a feedback mechanism if you regenerate and flood IS-IS > LSPs with updated TE TLVs > > that contain up to the moment (second, millisecond, whatever) bandwidth > info? > > > > > > The following is my assumption, please clarify if I am wrong, thanks > > > > > > > if a series of LSP requests are hitting a given IS-IS router (TE > source routing engine) at the same processing > > > > window/cycle, it makes assignments based on a frozen snap shot of the > bandwidth in the network. Assignments are made > > > > without consideration for their RSVP signalling success/failure and > eventually the signalling components would fail > > > > their reservation requests causing turbulance with LSP attempts. > > > > > > > Assuming most of what i said is true, do we need another more precise > mechanism to solve this? Regards, > > > > > > The feedback provides you ability to try, fail, learn and try again. > >From our experience, a proprietary signaling > > > protocol with feedback worked just fine, i.e. convergence was fast (one > or two tries/failures and a satisfactory route > > > was found). > > > > I agree with the 'try fail and learn again' approach but I don't think you > need > > a separate feedback mechanism other than recent IS-IS LSPs from other > LSRs. > > > > > > Matt Kontoff > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg -- Darek Skalecki Nortel (613) 765-2252 --------------BC2DCA0DA047B7565F1C5115 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote:
Matthew and Darek:
  I kind of like the feedback mechanism defined in
"draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or
Darek can add it to their spec is that a timestamp be added to both the
flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also
the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the
reservation denial and bandwidth sample was taken from the rejecting LSR. As
the message is returned to the ingress LSR its bandwidth will be overwritten
into the linkstate database, since its the most up to date information.

I can see a race condition where IGP converging link state information might
have older data then Reservation Release/Withdrawl messages containing the
same (feedback) data. Thus its possible for the ingress LSR IGP to
momentarily over-write newer bandwidth with bad/older bandwidth into the
ingress LSR linkstate database. Ingress LSR IGP should check the timestamp
in the database with its current LSA/LSP packet and only update the
bandwidth value if it has the newer timestamp in the LSA/LSP packet.

regards,
Ben

Ben Abarbanel,  Software Engineering,

Phone:  703 456 2982
FAX:      703 456 2952

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190

Timestamping is a fine idea but in our proprietary system we simply wrote any learned  information into a database,
whether the information was from feedback or flooding. You are right that more-up-to-date feedback information
may be then overwritten by older flooding information but in that case we may  simply re-learn newer information via feedback when needed so we never implemented timestamping.

Darek

 
 

----- Original Message -----
From: "Matthew Kontoff" <Mkontoff@Kontoff.com>
To: "Darek Skalecki" <dareks@nortelnetworks.com>
Cc: "ben abarbanel" <ben.abarbanel@ipoptical.com>; "isis-wg"
<isis-wg@spider.juniper.net>
Sent: Thursday, September 14, 2000 4:08 PM
Subject: Re: [Isis-wg] IS-IS TE Question

>
>
> Darek Skalecki wrote:
> >
> > ben abarbanel wrote:
> >
> > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a
question came to mind regardingunreserved
> > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for
stability reasons, rapid changes in the
> > > values in this sub-TLV should not cause rapid generation of LSPs".
>
> You still need to regenerate and flood LSPs when an interface state (i.e.
bandwidth)
> changes. How you do this is up to you. For example, you could reflood LSPs
at an interval
> that could be tied to the amount of bandwidth being used. The more
frequently LSPs
> are reflooded the closer an approximation of actual unreserved bandwidth
in the
> network you will have.
>
> >
> > > I was wondering what if  2 ingress (head end RSVP) LSR routers are
provisioning LSPs (each wanting 100 Mbytes)
> > > through the same core convergent LSR interface and each one of the
routers at the time they privision their LSP
> > > think there is 100 Mbyte of bandwidth free to complete the job. In
reality there is a total of 100 MBYTE for the
> > > whole interface, the first RSVP reservation succeeds while the second
fails.
> >
> > > The second LSP Ingress router would ask TE Source routing for another
next bandwidth constraint best path to setup
> > > the LSP.  How efficient is that if many LSPs coverge in the core of
the network this way and there is no precise way
> > > to say what is available at the time RSVP is trigered on?
> >
> > > Also, since the IS-IS and its TE source routing engine take snap shots
of the bandwidth resources in the network it
> > > has a tunnel view of what other IS-IS(LSR) routers are doing to this
information at that moment in time, and are
> > > making inaccurate determination of what is reserved and what is free.
The IS-IS route convergent time could be much
> > > slower than the RSVP signalling time.
> >
> > For CR-LDP a feedback mechanism was proposed to learn at signaling
intervals/speed whether or not there was b/w at
> > interfaces. A snapshot of that b/w is fed into TE database based on
which source routes are computed. With feedback,
> > if there is insufficient b/w at an interface to accomodate an LSP, a
notification message with a feedback TLV is
> > carried towards the source. The feedback information is then input into
TE database at source and a new route
> > computed. That route should now not contain the interface where there
was insufficient b/w. The feedback mechanism is
> > described in:
> > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt
>
> Why would you need a feedback mechanism if you regenerate and flood IS-IS
LSPs with updated TE TLVs
> that contain up to the moment (second, millisecond, whatever) bandwidth
info?
>
> > > The following is my assumption, please clarify if I am wrong, thanks
> >
> > > if a series of LSP requests are hitting a given IS-IS router (TE
source routing engine) at the same processing
> > > window/cycle, it makes assignments based on a frozen snap shot of the
bandwidth in the network. Assignments are made
> > > without consideration for their RSVP signalling success/failure and
eventually the signalling components would fail
> > > their reservation requests causing turbulance with LSP attempts.
> >
> > > Assuming most of what i said is true, do we need another more precise
mechanism to solve this? Regards,
> >
> > The feedback provides you ability to try, fail, learn and try again.
>From our experience, a proprietary signaling
> > protocol with feedback worked just fine, i.e. convergence was fast (one
or two tries/failures and a satisfactory route
> > was found).
>
> I agree with the 'try fail and learn again' approach but I don't think you
need
> a separate feedback mechanism other than recent IS-IS LSPs from other
LSRs.
>
>
> Matt Kontoff
>
> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------BC2DCA0DA047B7565F1C5115-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Sep 15 10:38:56 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20242 for ; Fri, 15 Sep 2000 10:38:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA26738; Fri, 15 Sep 2000 07:48:03 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA26710 for ; Fri, 15 Sep 2000 07:48:01 -0700 (PDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 15 Sep 2000 10:30:26 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 15 Sep 2000 10:30:21 -0400 Message-ID: From: "Don Fedyk" To: "Darek Skalecki" , ben abarbanel Cc: Matthew Kontoff , isis-wg , "Peter Ashwood-Smith" , "Bilel Jamoussi" Subject: RE: [Isis-wg] IS-IS TE Question Date: Fri, 15 Sep 2000 10:30:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01F21.77860EB0" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C01F21.77860EB0 Content-Type: text/plain; charset="iso-8859-1" All Just to add one thing to the time stamping idea. We do not consider it necessary since the database is still really maintained by the IGP flood. (Which does not use timestamps but sequence numbers). The feedback is more targeted information that is used in the interim. Although there are small windows of opportunities for the feedback to be miss ordered this is still leagues ahead of not having feedback. By the way, the most likely misordering is an old LSP (LSA) announcing more bandwidth than actually exists and overwriting a feedback message that has reported less bandwidth. This could result in a LSP signaling that has to learn from feedback again. (We prefer to deal with the timing issues not pray they will not happen!). Relying on timestamps or sequence numbers for feedback requires synchronization between peers and designers of IGPs have way more years of experience and code to deal with this. Don -----Original Message----- From: Skalecki, Darek [CAR:CS56:EXCH] Sent: Friday, September 15, 2000 8:49 AM To: ben abarbanel Cc: Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; Fedyk, Don [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH] Subject: Re: [Isis-wg] IS-IS TE Question ben abarbanel wrote: Matthew and Darek: I kind of like the feedback mechanism defined in "draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or Darek can add it to their spec is that a timestamp be added to both the flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the reservation denial and bandwidth sample was taken from the rejecting LSR. As the message is returned to the ingress LSR its bandwidth will be overwritten into the linkstate database, since its the most up to date information. I can see a race condition where IGP converging link state information might have older data then Reservation Release/Withdrawl messages containing the same (feedback) data. Thus its possible for the ingress LSR IGP to momentarily over-write newer bandwidth with bad/older bandwidth into the ingress LSR linkstate database. Ingress LSR IGP should check the timestamp in the database with its current LSA/LSP packet and only update the bandwidth value if it has the newer timestamp in the LSA/LSP packet. regards, Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 Timestamping is a fine idea but in our proprietary system we simply wrote any learned information into a database, whether the information was from feedback or flooding. You are right that more-up-to-date feedback information may be then overwritten by older flooding information but in that case we may simply re-learn newer information via feedback when needed so we never implemented timestamping. Darek -- Darek Skalecki Nortel (613) 765-2252 ------_=_NextPart_001_01C01F21.77860EB0 Content-Type: text/html; charset="iso-8859-1"
All
 
Just to add one thing to the time stamping idea. We do not consider it necessary since
the database is still really maintained by the IGP flood. (Which does not use timestamps
but sequence numbers). The feedback is more targeted information that is used in the
interim. Although there are small windows of opportunities for the feedback to be miss ordered
this is still leagues ahead of not having feedback. By the way, the most likely misordering is an
old LSP (LSA) announcing more bandwidth than actually exists and overwriting a feedback message
that has reported less bandwidth. This could result in a LSP signaling that has to learn from feedback
again. (We prefer to deal with the timing issues not pray they will not happen!).
Relying on timestamps or sequence numbers for feedback requires synchronization between peers
and designers of IGPs have way more years of experience and code to deal with this.
 
Don
 
 
 -----Original Message-----
From: Skalecki, Darek [CAR:CS56:EXCH]
Sent: Friday, September 15, 2000 8:49 AM
To: ben abarbanel
Cc: Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; Fedyk, Don [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH]
Subject: Re: [Isis-wg] IS-IS TE Question

ben abarbanel wrote:
Matthew and Darek:
  I kind of like the feedback mechanism defined in
"draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or
Darek can add it to their spec is that a timestamp be added to both the
flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also
the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the
reservation denial and bandwidth sample was taken from the rejecting LSR. As
the message is returned to the ingress LSR its bandwidth will be overwritten
into the linkstate database, since its the most up to date information.

I can see a race condition where IGP converging link state information might
have older data then Reservation Release/Withdrawl messages containing the
same (feedback) data. Thus its possible for the ingress LSR IGP to
momentarily over-write newer bandwidth with bad/older bandwidth into the
ingress LSR linkstate database. Ingress LSR IGP should check the timestamp
in the database with its current LSA/LSP packet and only update the
bandwidth value if it has the newer timestamp in the LSA/LSP packet.

regards,
Ben

Ben Abarbanel,  Software Engineering,

Phone:  703 456 2982
FAX:      703 456 2952

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190

Timestamping is a fine idea but in our proprietary system we simply wrote any learned  information into a database,
whether the information was from feedback or flooding. You are right that more-up-to-date feedback information
may be then overwritten by older flooding information but in that case we may  simply re-learn newer information via feedback when needed so we never implemented timestamping.

Darek

 

-- 
Darek Skalecki
Nortel 
(613) 765-2252
 
------_=_NextPart_001_01C01F21.77860EB0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Sep 15 13:50:09 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23073 for ; Fri, 15 Sep 2000 13:50:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA26970; Fri, 15 Sep 2000 10:56:43 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA26943 for ; Fri, 15 Sep 2000 10:56:41 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id KAA00533; Fri, 15 Sep 2000 10:41:31 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id KAA03778; Fri, 15 Sep 2000 10:41:31 -0700 (PDT) Received: from cyndi ([139.87.12.246]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id KAA26554; Fri, 15 Sep 2000 10:41:30 -0700 (PDT) Message-Id: <3.0.6.32.20000915104707.01e30860@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 15 Sep 2000 10:47:07 -0700 To: Tony Li From: Cyndi Jung Subject: Re: [Isis-wg] Simple question about IS-IS mixed domains Cc: isis-wg@spider.juniper.net In-Reply-To: <14785.48773.736706.195530@redd248.procket.com> References: <3.0.6.32.20000914115036.00b15b30@mailhost.ewd.3com.com> <3.0.1.32.20000519153209.013056c0@mail.one.com> <3.0.6.32.20000914115036.00b15b30@mailhost.ewd.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Of course, there is really only one important network layer, IP, but it has taken over the only routing protocol that CLNP ever had :-) So, it's most prevalent use is in IP-only networks, or purely dual domains. In fact, without the SPF per-protocol (assuming there were some information in the LSPs that they could use to imply the missing Supported Protocol field), a "mixed" domain is a misconfiguration, just as a mixed area is. Cyndi At 11:15 PM 9/14/00 -0700, Tony Li wrote: > > | If you can't mix dual and non-dual routers in the same area and > | have routing work for the non-OSI protocols supported (IP and IPv6), > | then how can it work at Level 2 if all the Level 2 routers do not > | support all the same non-OSI protocols? It seems to have the same > | problem - routes will be computed through routers that do not support > | the protocol of the data, just because the link costs are lowest. > | > | Am I missing something? > > >If one Really Wanted to do this, then one would have to SPF independently >for each protocol. > >Plus, because adjacency information is not carried on a per-protocol basis, >you would still have the restriction that any link between two routers >supporting a protocol would have to have the protocol working on that >link. So for example, the link between two IPv6 routers had better be >configured for IPv6. > >This seems like more complexity than it's worth. After all, there's only >one important network layer. ;-) > >Tony > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Sep 15 14:34:03 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23722 for ; Fri, 15 Sep 2000 14:34:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA27058; Fri, 15 Sep 2000 11:41:15 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA27030 for ; Fri, 15 Sep 2000 11:41:11 -0700 (PDT) Received: from [204.242.142.104] (helo=bena) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 13a0C0-0006b9-00; Fri, 15 Sep 2000 14:26:32 -0400 Message-ID: <002c01c01f43$1563b620$8b01020a@ipoptical.com> Reply-To: "ben abarbanel" From: "ben abarbanel" To: "Don Fedyk" , "Darek Skalecki" Cc: "Matthew Kontoff" , "isis-wg" , "Peter Ashwood-Smith" , "Bilel Jamoussi" References: Subject: Re: [Isis-wg] IS-IS TE Question Date: Fri, 15 Sep 2000 14:30:50 -0400 Organization: IPOptical MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C01F21.8C0FC740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C01F21.8C0FC740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Don: Comments below Ben Ben Abarbanel, Software Engineering, =20 Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message -----=20 From: Don Fedyk=20 To: Darek Skalecki ; ben abarbanel=20 Cc: Matthew Kontoff ; isis-wg ; Peter Ashwood-Smith ; Bilel Jamoussi=20 Sent: Friday, September 15, 2000 10:30 AM Subject: RE: [Isis-wg] IS-IS TE Question All =20 Just to add one thing to the time stamping idea. We do not consider it = necessary since=20 the database is still really maintained by the IGP flood. (Which does = not use timestamps but sequence numbers). The feedback is more targeted information that = is used in the=20 interim. Although there are small windows of opportunities for the = feedback to be miss ordered=20 this is still leagues ahead of not having feedback. By the way, the = most likely misordering is an old LSP (LSA) announcing more bandwidth than actually exists and = overwriting a feedback message that has reported less bandwidth. This could result in a LSP signaling = that has to learn from feedback=20 again. (We prefer to deal with the timing issues not pray they will = not happen!). Relying on timestamps or sequence numbers for feedback requires = synchronization between peers=20 and designers of IGPs have way more years of experience and code to = deal with this. =20 I only mentioned timestamp cause I did not think we can use the IGP = sequence number as it is picked for IGP flooding for LSP signalling. The timestamp is only relevent to the = router that is originating the LSA/LSP=20 so there is no synchronization requirements between peers/neighbors. = I think eventually the IGP flooding mechanism=20 will adjust to the correct value, but in the interim the routers in = the domain could drift of actual capacities and thus create more LSP reservation failures. It would be nice to cover this = hole no matter how small with a solution in the specification and leave it up to the implementor to choose. I = guess since you guys went this far in trying to close down the inaccuracies between the routers in the domain. Regards, Ben =20 -----Original Message----- From: Skalecki, Darek [CAR:CS56:EXCH]=20 Sent: Friday, September 15, 2000 8:49 AM To: ben abarbanel Cc: Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; = Fedyk, Don [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH] Subject: Re: [Isis-wg] IS-IS TE Question ben abarbanel wrote:=20 Matthew and Darek:=20 I kind of like the feedback mechanism defined in=20 "draft-ietf-mpls-te-feed-01.txt". I think what is missing and = maybe Bilel or=20 Darek can add it to their spec is that a timestamp be added to = both the=20 flooded LSA/LSP TE TLV to identify when the bandwidth sample was = taken. Also=20 the CR/LDP or RSVP-TE new TLV have a time stamp identifying when = the=20 reservation denial and bandwidth sample was taken from the = rejecting LSR. As=20 the message is returned to the ingress LSR its bandwidth will be = overwritten=20 into the linkstate database, since its the most up to date = information.=20 I can see a race condition where IGP converging link state = information might=20 have older data then Reservation Release/Withdrawl messages = containing the=20 same (feedback) data. Thus its possible for the ingress LSR IGP to = momentarily over-write newer bandwidth with bad/older bandwidth = into the=20 ingress LSR linkstate database. Ingress LSR IGP should check the = timestamp=20 in the database with its current LSA/LSP packet and only update = the=20 bandwidth value if it has the newer timestamp in the LSA/LSP = packet.=20 regards,=20 Ben=20 Ben Abarbanel, Software Engineering,=20 Phone: 703 456 2982=20 FAX: 703 456 2952=20 IPOptical, Inc.=20 11480 Sunset Hills Road=20 Suite #200E=20 Reston, VA 20190 Timestamping is a fine idea but in our proprietary system we simply = wrote any learned information into a database,=20 whether the information was from feedback or flooding. You are right = that more-up-to-date feedback information=20 may be then overwritten by older flooding information but in that = case we may simply re-learn newer information via feedback when needed = so we never implemented timestamping.=20 Darek=20 --=20 Darek Skalecki Nortel=20 (613) 765-2252 =20 ------=_NextPart_000_0029_01C01F21.8C0FC740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Don:
 Comments below
 
Ben
 
 
Ben Abarbanel,  Software Engineering, 
 
Phone:  703 456 2982
FAX:      703 = 456=20 2952
 
IPOptical, Inc.
11480 Sunset Hills Road
Suite = #200E
Reston, VA=20 20190
----- Original Message -----
From:=20 Don Fedyk
To: Darek=20 Skalecki ; ben abarbanel
Cc: Matthew Kontoff ; isis-wg ; Peter=20 Ashwood-Smith ; Bilel Jamoussi
Sent: Friday, September 15, = 2000 10:30=20 AM
Subject: RE: [Isis-wg] IS-IS TE = Question

All
 
Just=20 to add one thing to the time stamping idea. We do not consider it = necessary=20 since
the database is still really maintained by the = IGP flood.=20 (Which does not use timestamps
but=20 sequence numbers). The feedback is more targeted information that is = used in=20 the
interim. Although there are small windows of = opportunities=20 for the feedback to be miss ordered
this=20 is still leagues ahead of not having feedback. By the way, the most = likely=20 misordering is an
old LSP (LSA) announcing more bandwidth than = actually exists=20 and overwriting a feedback message
that has reported less bandwidth. This could = result in a LSP=20 signaling that has to learn from feedback
again. (We prefer to deal with the timing issues = not pray=20 they will not happen!).
Relying on timestamps or sequence numbers=20 for feedback requires synchronization between = peers=20
and=20 designers of IGPs have way more years of experience and code to deal = with=20 this.
 
I only mentioned timestamp cause I = did not think=20 we can use the IGP sequence number as it is picked for
IGP flooding for LSP signalling. The = timestamp is=20 only relevent to the router that is originating the LSA/LSP =
so there is no synchronization = requirements=20 between peers/neighbors.  I think eventually the IGP flooding = mechanism=20
will adjust to the correct value, but = in the=20 interim the routers in the domain could drift of actual capacities and = thus
create more LSP reservation failures. = It would be=20 nice to cover this hole no matter how small with a solution = in
the specification and leave it up to = the=20 implementor to choose. I guess since you guys went this far in trying = to=20 close
down the inaccuracies between = the routers in=20 the domain.
 
Regards,
Ben
 
 
 
 
 
 -----Original=20 Message-----
From: Skalecki, Darek [CAR:CS56:EXCH] =
Sent:=20 Friday, September 15, 2000 8:49 AM
To: ben = abarbanel
Cc:=20 Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; Fedyk, = Don=20 [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH]
Subject: = Re:=20 [Isis-wg] IS-IS TE Question

ben=20 abarbanel wrote:=20
Matthew and Darek:
  I kind of = like the=20 feedback mechanism defined in =
"draft-ietf-mpls-te-feed-01.txt". I=20 think what is missing and maybe Bilel or
Darek can add it to = their=20 spec is that a timestamp be added to both the
flooded LSA/LSP = TE TLV=20 to identify when the bandwidth sample was taken. Also
the = CR/LDP or=20 RSVP-TE new TLV have a time stamp identifying when the =
reservation=20 denial and bandwidth sample was taken from the rejecting LSR. As =
the=20 message is returned to the ingress LSR its bandwidth will be = overwritten=20
into the linkstate database, since its the most up to date=20 information.=20

I can see a race condition where IGP converging link state = information=20 might
have older data then Reservation Release/Withdrawl = messages=20 containing the
same (feedback) data. Thus its possible for the = ingress=20 LSR IGP to
momentarily over-write newer bandwidth with = bad/older=20 bandwidth into the
ingress LSR linkstate database. Ingress LSR = IGP=20 should check the timestamp
in the database with its current = LSA/LSP=20 packet and only update the
bandwidth value if it has the newer = timestamp in the LSA/LSP packet.=20

regards,
Ben=20

Ben Abarbanel,  Software Engineering,=20

Phone:  703 456 2982 =
FAX:      703=20 456 2952=20

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E =
Reston,=20 VA 20190

Timestamping is a fine idea but in our = proprietary=20 system we simply wrote any learned  information into a = database,=20
whether the information was from feedback or flooding. You are = right=20 that more-up-to-date feedback information
may be then = overwritten by=20 older flooding information but in that case we may  simply = re-learn=20 newer information via feedback when needed so we never implemented=20 timestamping.=20

Darek=20

 

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  ------=_NextPart_000_0029_01C01F21.8C0FC740-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Sep 15 18:12:58 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25487 for ; Fri, 15 Sep 2000 18:12:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA27279; Fri, 15 Sep 2000 15:22:42 -0700 (PDT) Received: from redd248.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA27251 for ; Fri, 15 Sep 2000 15:22:41 -0700 (PDT) Received: (from tli@localhost) by redd248.procket.com (8.9.3/8.9.3) id PAA09813; Fri, 15 Sep 2000 15:07:56 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: redd248.procket.com: tli set sender to tli@redd248.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14786.40380.348588.294365@redd248.procket.com> Date: Fri, 15 Sep 2000 15:07:56 -0700 (PDT) To: "ben abarbanel" Cc: "Don Fedyk" , "Darek Skalecki" , "Matthew Kontoff" , "isis-wg" , "Peter Ashwood-Smith" , "Bilel Jamoussi" Subject: Re: [Isis-wg] IS-IS TE Question In-Reply-To: <002c01c01f43$1563b620$8b01020a@ipoptical.com> References: <002c01c01f43$1563b620$8b01020a@ipoptical.com> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Folks, About 99% of this conversation is about signaling and crankback and not about IS-IS. Could we take it to a more appropriate mailing list, please? Thanks, Tony co-chair _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Sep 15 18:35:50 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25613 for ; Fri, 15 Sep 2000 18:35:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA27397; Fri, 15 Sep 2000 15:45:58 -0700 (PDT) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA27322 for ; Fri, 15 Sep 2000 15:45:51 -0700 (PDT) Received: from [204.242.142.104] (helo=bena) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 13a40h-0003rW-00; Fri, 15 Sep 2000 18:31:08 -0400 Message-ID: <003701c01f65$4160e140$8b01020a@ipoptical.com> Reply-To: "ben abarbanel" From: "ben abarbanel" To: "Tony Li" Cc: "Don Fedyk" , "Darek Skalecki" , "Matthew Kontoff" , "isis-wg" , "Peter Ashwood-Smith" , "Bilel Jamoussi" References: <002c01c01f43$1563b620$8b01020a@ipoptical.com> <14786.40380.348588.294365@redd248.procket.com> Subject: Re: [Isis-wg] IS-IS TE Question Date: Fri, 15 Sep 2000 18:35:31 -0400 Organization: IPOptical MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Sure, I think I am done. Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message ----- From: "Tony Li" To: "ben abarbanel" Cc: "Don Fedyk" ; "Darek Skalecki" ; "Matthew Kontoff" ; "isis-wg" ; "Peter Ashwood-Smith" ; "Bilel Jamoussi" Sent: Friday, September 15, 2000 6:07 PM Subject: Re: [Isis-wg] IS-IS TE Question > > > Folks, > > About 99% of this conversation is about signaling and crankback and not > about IS-IS. Could we take it to a more appropriate mailing list, please? > > Thanks, > Tony > co-chair > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Sep 15 19:01:07 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25772 for ; Fri, 15 Sep 2000 19:01:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA27477; Fri, 15 Sep 2000 16:11:06 -0700 (PDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA27445 for ; Fri, 15 Sep 2000 16:11:03 -0700 (PDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Fri, 15 Sep 2000 17:50:35 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 15 Sep 2000 17:54:21 -0500 Message-ID: From: "Don Fedyk" To: Tony Li , ben abarbanel Cc: "Darek Skalecki" , Matthew Kontoff , isis-wg , "Peter Ashwood-Smith" , "Bilel Jamoussi" Subject: RE: [Isis-wg] IS-IS TE Question Date: Fri, 15 Sep 2000 17:54:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01F67.E03C88D0" X-Orig: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C01F67.E03C88D0 Content-Type: text/plain; charset="iso-8859-1" Tony I am perplexed by your statement. This spreads across several groups and we get disjoint consensus. From an IS-IS standpoint you should be concerned what scales and what does not. Feedback is in IS-IS's best interest. Are you suggesting anything that is accepted in MPLS just be rubber stamped in IS-IS? Don > -----Original Message----- > From: Tony Li [mailto:tli@Procket.com] > Sent: Friday, September 15, 2000 6:08 PM > To: ben abarbanel > Cc: Fedyk, Don [BL60:9553:EXCH]; Skalecki, Darek [CAR:CS56:EXCH]; > Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; > Jamoussi, Bilel [BL3:T823-M:EXCH] > Subject: Re: [Isis-wg] IS-IS TE Question > > > > > Folks, > > About 99% of this conversation is about signaling and > crankback and not > about IS-IS. Could we take it to a more appropriate mailing > list, please? > > Thanks, > Tony > co-chair > > ------_=_NextPart_001_01C01F67.E03C88D0 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] IS-IS TE Question

Tony

I am perplexed by your statement. This spreads across
several groups and we get disjoint consensus.

From an IS-IS standpoint you should be concerned what scales
and what does not. Feedback is in IS-IS's best interest.
Are you suggesting anything that is accepted in MPLS just
be rubber stamped in IS-IS?

Don


> -----Original Message-----
> From: Tony Li [mailto:tli@Procket.com]
> Sent: Friday, September 15, 2000 6:08 PM
> To: ben abarbanel
> Cc: Fedyk, Don [BL60:9553:EXCH]; Skalecki, Darek [CAR:CS56:EXCH];
> Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH];
> Jamoussi, Bilel [BL3:T823-M:EXCH]
> Subject: Re: [Isis-wg] IS-IS TE Question
>
>
>
>
> Folks,
>
> About 99% of this conversation is about signaling and
> crankback and not
> about IS-IS.  Could we take it to a more appropriate mailing
> list, please?
>
> Thanks,
> Tony
> co-chair
>
>

------_=_NextPart_001_01C01F67.E03C88D0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Sep 15 19:13:26 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25873 for ; Fri, 15 Sep 2000 19:13:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA27537; Fri, 15 Sep 2000 16:24:45 -0700 (PDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA27506 for ; Fri, 15 Sep 2000 16:24:43 -0700 (PDT) Received: from mosquito.extremenetworks.com ([10.0.8.106]) by sol.extremenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id S02632HS; Fri, 15 Sep 2000 16:09:07 -0700 Message-Id: <4.3.2.7.2.20000915190221.00b48230@sol.extremenetworks.com> X-Sender: rja@sol.extremenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Sep 2000 19:04:39 -0400 To: "Don Fedyk" From: RJ Atkinson Subject: RE: [Isis-wg] IS-IS TE Question Cc: Tony Li , ben abarbanel , "Darek Skalecki" , Matthew Kontoff , isis-wg , "Peter Ashwood-Smith" , "Bilel Jamoussi" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net At 18:54 15/09/00, Don Fedyk wrote: Don, Going forward,could you kindly send mail to IETF lists using plain-text ASCII rather than some fancy format as you just did ? A lot of us are NOT using MS-Outlook and at least some folks are on low-bandwidth connectivity, so using IETF standard US-ASCII (or ISO-8859-N) in text/plain format is customary on all IETF mailing lists. Thanks very much, Ran rja@inet.org _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Sep 18 21:47:56 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23699 for ; Mon, 18 Sep 2000 21:47:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA33376; Mon, 18 Sep 2000 18:54:14 -0700 (PDT) Received: from hotmail.com (f230.pav1.hotmail.com [64.4.31.230]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA33344 for ; Mon, 18 Sep 2000 18:54:08 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Sep 2000 18:39:06 -0700 Received: from 209.58.11.227 by pv1fd.pav1.hotmail.msn.com with HTTP; Tue, 19 Sep 2000 01:39:06 GMT X-Originating-IP: [209.58.11.227] From: "vikram isis" To: isis-wg@spider.juniper.net Date: Tue, 19 Sep 2000 01:39:06 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Sep 2000 01:39:06.0616 (UTC) FILETIME=[661D5780:01C021DA] Subject: [Isis-wg] DIS election question??? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi, I just have question on DIS election. Assuming, an unintended DIS(less capacity or something) is elected, due to misconfiguration of priority or by virtue of its mac address. And that, it is unable to bear the load and submits to another DIS (less priority or low MAC address) in the next DRHold Interval. When its less loaded, is elected again as the DIS and the ping pong between DISs continue. Is there a mechanism by which the DIS which is stable can stick around by distributed/centralised mechanism for a certain period? Any insight would be helpful. Thanks Vikram _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Sep 18 21:49:11 2000 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23727 for ; Mon, 18 Sep 2000 21:49:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA33448; Mon, 18 Sep 2000 19:01:47 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA33421 for ; Mon, 18 Sep 2000 19:01:45 -0700 (PDT) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id SAA00697; Mon, 18 Sep 2000 18:46:46 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id SAA09714; Mon, 18 Sep 2000 18:46:49 -0700 (PDT) Date: Mon, 18 Sep 2000 18:46:49 -0700 (PDT) Message-Id: <200009190146.SAA09714@cirrus.juniper.net> From: Dave Katz To: vikram_isis@hotmail.com CC: isis-wg@spider.juniper.net In-reply-to: (vikram_isis@hotmail.com) Subject: Re: [Isis-wg] DIS election question??? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Use the priority mechanism. X-Originating-IP: [209.58.11.227] From: "vikram isis" Date: Tue, 19 Sep 2000 01:39:06 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 19 Sep 2000 01:39:06.0616 (UTC) FILETIME=[661D5780:01C021DA] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi, I just have question on DIS election. Assuming, an unintended DIS(less capacity or something) is elected, due to misconfiguration of priority or by virtue of its mac address. And that, it is unable to bear the load and submits to another DIS (less priority or low MAC address) in the next DRHold Interval. When its less loaded, is elected again as the DIS and the ping pong between DISs continue. Is there a mechanism by which the DIS which is stable can stick around by distributed/centralised mechanism for a certain period? Any insight would be helpful. Thanks Vikram _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg